Consciously design how you collaborate as a team
Most organisations run 100+ projects a year. Many run 1000+.
Only a handful deliberately design how they will collaborate on projects.
"Designing collaboration" is not really a Thing, so let's define it first and then we can get to work:
When we work together, we have a load of stuff to coordinate on and some different modalities for doing this.
Here's some of the stuff we need to coordinate on:
- agree what we're aiming for
- understand what I'm doing vs what you're doing
- share information
- make decisions
- measure progress
etc etc
And here are some of the modalities we use:
- meetings (with different formats and different combinations of people)
- group typed chat
- DMs (on official channels like Teams and also unofficial like whatsapp)
- phone calls and 1:1 meetings
- shared documents
- processes, reporting and SOPs (standard operating procedures)
- notifications, notes and comments on systems
- talking in the office (and overhearing other people talking) <---- clearly not so much any more....
etc etc
Designing collaboration is simply developing and refining a logical set of norms to do the things in the first list in the right order and the right way, making best use of the modalities in the second list - and having everyone feel clear about how this works.
It's an ecosystem your team can lean on to get stuff done well, with least effort.
Why do we do this?
Most people are in collaboration overload
And it's not just the sheer volume.
It's the ambiguity and non-standardisation of collaboration comms... which means our brains are working too hard all the time.
"Where should I raise this point?" "Is that my responsibility or yours?" "Where's that piece of information I need?" "
It's exhausting and it's not efficient. There is nothing less collaborative than feeling unclear about and overwhelmed by how you're working together.
Redesigning 'how we meet and collaborate' is potentially vast.
So here's how I've handled this for the last 15 years with my teams - you can see my method and create your own.
My method - borrow it or create your own
I use 'I' through this explanation of my method. By I, I mean "I am ACCOUNTABLE for doing this with the team" not "I decide and do this TO the team"
First I make sure we have a goal hierarchy:
1. What's the big organisational goal we're serving?
2. What are the specific goals for this group or project?
3. What matters about HOW we do it?
I get all that written down and agreed and it goes at the top of all our comms, presentations etc.
So far, so easy - my riff on what you are probably doing already.
I would also get completely clear on the roles in the team or project.
I start with roles not people. What are the 6-12 'roles' that need playing to do this work? Who is responsible for that role?
Most people will be responsible for multiple roles at once. Responsibility might be passed to a different person during the project.
Each role has a name and a series of task or sub responsibilities that come under it. In my world, they go in columns, left to right.
We manage the roles not the people. So in a check in meeting, we can scan the roles, left to right and each responsible person can provide an update. The subtle shift in focus from person ("what's your update, Marcus?") to role ("what's the testing update?") helps us shift from relationship conflict to task conflict. We're looking at what's ok/not ok about the role or task, delivered via the person responsible for it. We're not interrogating the person and whether they 'did ok' or not.
Then I figure out our cadence
What is the 'cycle' for our work or service? I use cycles because it gives us a rhythm and breaks the work into managable chunks. It's usually weekly, bi-weekly or monthly.
Within this, I would design:
- a way / time to plan for the next cycle
- a way to check in and stay up to date
- a way to reflect on the cycles.
- a way to connect as a team beyond the tasks
I design a streamlined flow of meetings (3d, 2d or async) to handle the above. See my next step for how to strip out unnecessary meeting time.
In this flow, everything has somewhere to go and as little as possible is duplicated. You will never get this right first time. Set the expectation that this is the flow draft and you'll refine it together as you go. Encourage people to ask "where does this go?"
I make every possible collaborative interaction transparent, accessible and self service
From shared docs to a wiki, I would place the responsibility for sharing and accessing information on the roles (it's on of the sub tasks) not on a meeting or async check in.
The meeting or async check in is to discuss the issues, trade offs and decisions to be made based on the information - not to share the information.
I create some clear conventions around this - types of docs, where they go, what they're called so we have consistency.
We're constantly evolving this dynamic content so that it serves both its creators and consumers.
I create norms around async
I use some simple templates and formats to initiate and encourage certain types of async update or virtual check in.
I make sure we have some shared interaction conventions e.g. thumbs up means we've read it.
I help people carve out space away from async to do deep work.
And I develop a 'what goes where' plan
I make all this really clear in a 'what goes where' infographic which we keep refining as we go.
e.g.
Simple or quick questions ---> async chat (flagged with ❓, emoji response options and a timescale for answers)
Complex or long questions ---> weekly team check in (add to the shared agenda here)
The cycle reflection session is the key to this. Without deliberating thinking about what is and isn't working together, people just get frustrated and resistant.
Let's be clear. I am definitely NOT trying to turn engagement and collaboration into a tick box exercise. In fact, it's the opposite. I'm trying to streamline the basics via some simple architecture to create the space and understanding to access people's best contribution - and THAT'S what unleashes the real human engagement and collaboration we need.
Next time you start a project or team, deliberately design your collaboration norms. Whether you use my method or something entirely different, the only goal is to create some explicit, well designed norms that scaffold and help people contribute with less friction.
