Collaboration vs. Coordination: Why aren’t you achieving as much as you could?
The word collaboration gives the warm and fuzzies to people. If you see it in a job description, you are more likely to apply. When you hear an exec talking about it, you go, “Yes! Let’s collaborate more!” Collaboration makes people feel good and part of the creation of something meaningful. What if I told you collaboration is a bad thing most of the time? What if I told you collaboration slows you down and makes you achieve fewer goals? What if I told you collaboration leads to less trust among coworkers?! If I haven’t lost you by now, buckle up. This ride is wild!
What’s collaboration? What’s coordination?
LMGTFY! OK. I’ll do the lazy work. In as few words as possible: collaboration is about working together; coordination is about working in an organized fashion. In colloquial language, we often use the word collaboration to mean work being done by more than one person. The more accurate meaning is this:
Collaboration = Working together to achieve an activity goal together.
Coordination = Working separately to achieve an activity goal together.
First, let’s talk about the similarities. Both are about a group of people. Both are about trying to achieve a result. Both are about each person contributing by doing tasks. Both have (good and bad) frameworks and processes that help achieve the desired result.
Let’s unpack them a bit more.
Dependency & Knowledge
Some activities can be done in isolation, and it doesn’t depend on anyone else to finish them. Like, being a line cook in a Michelin restaurant cooking the steak or deploying software to a production server. Some activities require two or more people working independently on their task but coming together either after the other or in parallel to achieve the final goal. For example, installing a large wall-mounted cabinet in the kitchen or creating the copy, designing, and implementing a new page. Another example would be interviewing a candidate, where each interviewer takes their turn. Finally, some activities can’t be done alone and require two or more contributors, like planning a product roadmap, defining the brand identity of a startup, or picking the date for the wedding.
The point is that there is a spectrum of dependency. On one end, you have multi-task activities divided into fully independent tasks, and on the other, the tasks are so intertwined that they can’t be done independently.
Another dimension is how much the people know what they are doing and can do it again using the same inputs, tools, and procedures to achieve the same output.
For example, installing the cabinet or deploying it to production can be easily codified, so even someone without a lot of previous knowledge can pick up the task and do it correctly. Creating a new brand identity, planning the next quarter, or writing an app isn’t so easy to codify. You can’t plan every step to get the result you want. The “plan” is the work (or a good chunk of it).
Here’s the diagram that represents this:
The obvious part of this diagram is that you need collaboration when you can’t do the work independently and don’t know the exact output.
Collaboration means working together — and working together is the only way — to achieve the objective. The worst form of collaboration is the “committee” (:eye-roll: content for another post). Still, there are many other frameworks where people take different roles and responsibilities to get the work done.
On the opposite end of the diagram, you have known work (i.e., people have done it and don’t require further direction) that can be done independently, even if that work will combine with other work to achieve the complete objective. What is required is coordination.
A factory production line is a type of coordinated work. Each person does their part and hands it off to the next person. A back-end and a front-end software engineer might collaborate to define the API but then switch to a coordinated work style, and each one builds their part. A dozen front-end and back-end engineers might work independently to build many APIs and aspects of the same application without any (or little) collaboration.
As you can see, sometimes you need a little bit of both, an initial collaboration followed by some coordination:
OK. Store that in the back of your mind, and let’s do another stop in this journey.
Trust and repeatability
Some work might be fine done in a coordinated fashion, but it requires the parties to trust each other. I don’t mean trust in the broader human sense of trust; I mean trust in the sense that the other party’s inputs and outputs are well-understood (the tools and procedures are not relevant in this context).
A person installing the central A/C unit in your house will trust the person who installed the furnace and the person(s) who set up the vents, even though they might not know each other.
Another example of trust is a Visual Designer working with a front-end engineer and providing the assets and files for that front-end engineer to do their work. If they’ve worked together, they develop a system that makes that hand-off work well. Do they use Figma? Do they slice images into a Dropbox? Do they provide redlines in a PDF?
The other dimension of this section is repeatability. Is the activity a one-off, a repeat from a previous activity, or something in the middle?
Similar to my definition of trust (you know what you’ll get), repeatability also depends on input and output. You know that a person will provide you with the same output given the same input. If I order a cheeseburger at a restaurant, I get a cheeseburger at my table 15 minutes later. If I ask for a data engineer to export the latest report from our Data Mart to Periscope, I know exactly when and what I’m getting.
Repeatability can also be about a category of work. In other words, the tools and procedures are similar, but the input and output will be different. For example, if I worked with a team doing content marketing and we’ve done this dance a dozen times, I know that I’ll get an exceptional output when I give them the right inputs.
If you have work that’s not repeated/repeatable, you probably will need to collaborate with the other people in the team. It could be “not repeatable” because the inputs haven’t been well-defined or collected, the procedures are new, or even the desired output is unknown.
You might also need collaboration if the process is repeatable, but the team hasn’t built the trust in each other to do it alone — for example, a new inexperienced team member doing a task they haven’t proven themselves yet.
However, collaboration is unnecessary if the activities are repeatable and the team trusts each other. Each one knows what they need to do and how the pieces fit together. In that case, the team only needs to coordinate the tasks.
This particular way of viewing collaboration vs. coordination presents an interesting quadrant. When the work is not repeatable, and there is no trust among team players. It’s the worst situation because what you get is micromanagement. You’ll get micromanagement independently if there is even a manager in the team. You might have seen situations like this by watching Survival or The Apprentice. The technical business term for this situation is “shitshow.”
I have one last stop in this journey about the differences between collaboration and coordination. Then we get to the really fun part!
Permanence vs. Responsiveness
Does knowing how to get an activity done need to be preserved? There are so many things happening in business (and in life). Some of it might be a one-off. Is it worth it for me and my wife to have a plan on how to rebalance our finances once the next house crisis happens? Should IT prepare for another flooding in the basement now they are moving to a new place? Does the CFO need to write a document explaining their actions to raise a Series A after the fact?
Even activities that happen more than once a year might not elevate themselves to requiring codifying tools, procedures, and, sometimes, not even the outputs.
The other axis is about responsiveness. It’s how long it takes between input and output. Software engineering often talks about responsiveness in terms of latency (for back-end work) and UI refresh rate or readiness (for front-end work). But responsiveness applies to everything in business. How long does it take the accounting team to process the receipts you just sent them? How long will the PM take to respond to your request? How long will the bug be fixed after it’s entered into Jira?
Collaboration is probably the best option if you require real-time back-and-forth (e.g., high-throughput communication), and it doesn’t matter if the process doesn’t need to be remembered.
If that activity needs to be stored in a persistent way (the inputs, the procedures, or the outputs) and there is less sensitivity to the responsiveness (hours, days, or weeks are fine), a coordinated effort is ideal:
This diagram also shows a curious scenario where permanence is vital (tracking inputs, procedures, or output). Still, low latency is essential, for example, in a non-stop production line. Another example is a customer support team dealing with a surge of complaints through their live chat feature when the website is not working well. In these cases, not only coordination will beat collaboration, but automation can help the team achieve even more:
And the last case is where latency is not important, but neither is to persist the procedures, tools, or outputs. It’s a true one-off of low importance.
Let the fun begin!
We have a few takeaways so far
Collaboration is necessary when there is no trust in the team (yet) or when you are doing a new activity. It’s also best when there are unknowns (unknown inputs, procedures, or desired outputs) or so much dependency between the individual tasks that breaking them apart is fruitless. Finally, collaboration is also best when you need close to real-time responsiveness between team members (think the “Situation Room” in the White House).
On the other hand, coordination is best when there is trust among team members working on their task to achieve the whole activity. Or when the tasks are recurring (or repeated with some frequency). Coordination is also ideal when people can work independently on their tasks and understand the input/process/outputs entails. Finally, coordination is excellent when you need to persist the results, the processes, and the inputs.
I want you to keep this image in your head when you think about coordination:
I like that image because there are many roles and people perform many unique and independent tasks to achieve a single activity (changing the tires in a car). There is no verbal communication taking place. There aren’t even non-verbal communications. No one is looking into someone else eyes waiting for a head nod. It’s the apex of coordination and it takes only 2.5 seconds!
Another example of “extreme coordination” is getting a license at the Department of Motor Vehicles (DMV). Many people will be involved in your driving test, knowledge test, taking and processing your forms, payment and information, taking your picture, etc. They don’t need to collaborate at all. They don’t meet to discuss the request. Everyone knows what input they need, what tools and procedures they will use, and the output.
Now, here is an example of collaboration:
You can’t drive in this roundabout without acknowledging the other drivers and sensing the (non-verbal) communication to make sure it’s safe to go.
Why does collaboration suck?
I’m being factitious to make a point. It’s not that it sucks. But we overuse collaboration as a work tool, making the activities less efficient and delivering lower efficacy.
Collaborative work is much slower than coordinated work unless there is a need for high-throughput communication.
Collaborative work creates a lack of ownership and accountability (again, “committees” are the epitome of maximum collaboration, typically leading to minimum accountability). It’s also hard to measure and improve it.
Collaborative work requires presence, making it hard to work on longer tasks, or with team players with busy schedules or in different time zones.
There’s something about collaboration that reminds me of “FOMO.” Let’s bring everyone together, and anyone who wants can join to help us do ______. And you get a room full of well-intentioned people, very aligned, but getting very little done.
Collaboration is one of the biggest bottlenecks in business. It usually manifests itself in the form of meetings. But also email chains with a dozen people or a Slack channel with 30 people, where everyone is chipping in, debating, and doing an amorphous set of tasks to get to the final activity. I’m sure you’ve been to a highly collaborative meeting where you felt no decision or action was taken, but another meeting has been scheduled to “continue the conversation,” no?
You cannot, and I can’t say this strongly enough…
⚠️ You cannot scale a team, a project, or a company by having more collaboration! ️⚠️
There is a directly inverse proportion between the amount of collaboration you have and the amount of work done! The diagram below shows how many lines of communication a team needs based on the number of people actively collaborating:
In Agile Software Development practices, teams should be limited to 7–9 people because Agile assumes high levels of collaboration among people in the same team. That’s also why Amazon uses (used?) the Two-Pizza team for highly collaborative efforts. More people make it worse!
Startups are terrible at this! It’s natural because there aren’t enough processes in place, not enough is documented, and even the file storage is a mess without any apparent organization. Worse, files, documents, tickets, and information are spread across a dozen different services with no consistency, making the task of finding a single file an act of collaboration because you have to ask someone else to find that file for you.
I’ve gone through this so many times! As the startup grows, everyone wants to be in every meeting, email, and decision. It’s highly collaborative and feels incredible until the company reaches about 25 people. Then you realize how much “process debt” has been accumulated and how ineffective the company has become. Growing from 25 to 35 is one of the most significant and painful breakthroughs in startup growth.
Coordination is fantastic!
Coordination means that to achieve a bigger goal together, I work on my part, you work on your part, and we know exactly how they fit together. We don’t block each other. We don’t depend on each other working at the same time. And, if we add more people to work with us, they will also not block us, and more work will get done.
Highly coordinated work is not 10% faster than collaborative work; it’s 1000% faster! It’s so much faster, even if you get it completely wrong, you can still go back and do it nine more times and still be ahead!
Let me put it this way: A designer can create three viable ideas for a new logo by locking themselves in a room for a day or two. If the CEO is sitting next to them, collaborating through the process, they will likely have a half-logo in the same period.
A glass of coordination, a pinch of collaboration
I listed several cases where collaboration is the right tool. Still, we should be asking how we can convert more of our workstreams from collaboration to coordination. What’s preventing us from doing our tasks asynchronously and independently? What’s preventing us from trusting each other or codifying the work? What’s the right amount of collaboration to avoid misalignment and the right level of contribution?
That last question is an important one. Through my observations, a team that never collaborates ends up with too much misalignment and often with resentment. So, the answer isn’t “no collaboration.”
Intermittent collaboration has already been researched and proven to deliver the best results for solving complex problems. I believe it’s more than that. Starting with the right size of collaboration, then switching to a coordinated effort with checkpoints (collaboration) is by far the best way to work in 99% of the situations.
There’s an understanding that creative work requires collaboration. Collaboration helps cement the purpose of the activity and bring alignment, but it doesn’t give people autonomy to execute their tasks and master their skills.
