Collaboration drag: coordination costs more than the collaboration is worth

The most collaborative team I ever worked on was also the slowest. We had cross-functional representation from every discipline, a shared Slack channel, weekly syncs, bi-weekly reviews, and a quarterly alignment ritual that consumed an entire Thursday. On paper, we were the model. In practice, we shipped less than a two-person team working out of a Bangalore apartment with a whiteboard and a deadline.

Nobody on that team was lazy. Nobody was incompetent. But the architecture of our collaboration had become the primary obstacle to our output. We were not working together. We were coordinating the appearance of working together.

I call this collaboration drag. The cost of coordinating across functions exceeds the value the collaboration was meant to produce. Gartner reports 84% of leaders are experiencing it. Teams suffering from it are 37% less likely to hit revenue goals. That number should alarm people more than it does.

The coordination tax

There is a cost to every meeting, every alignment check, every status update, every shared document that requires six people to comment before anything moves. I call it the coordination tax. Like any tax, it is invisible until you calculate the total.

At Adobe, I was part of an enterprise product team where every feature required sign-off from seven stakeholders spread across three time zones. The feature work itself was not complex. A senior designer and two engineers could have shipped it in two weeks. But the coordination required to align those seven stakeholders turned two weeks into three months.

Not because the work was hard. Because getting everyone to agree on the work took longer than doing the work.

We had coordination meetings to prepare for the coordination meetings. I am not exaggerating. There was a pre-alignment call before the alignment review, because the alignment review could not be productive unless everyone had already agreed on what would be discussed. The actual building happened in the cracks between these rituals. The product advanced in stolen hours, not scheduled ones.

But here is the part that nobody in the room would say out loud. The seven stakeholders did not all need to be involved. Three of them had relevant expertise. The other four were included because the organisation's culture equated inclusion with respect. Excluding someone from a decision was read as a political signal, not an efficiency decision. So we included everyone and built nothing.

The calendar was full. The product was empty.

When consensus becomes the product

At Freshworks, I sat through a sprint planning session that taught me something I have not forgotten. The team spent ninety minutes deciding what to build. Detailed discussion. Careful prioritisation. Thorough debate about scope and feasibility. By the time the session ended, everyone felt aligned. Everyone felt heard.

But zero minutes had been spent building. The sprint had not started. The planning of the sprint had consumed the energy that was supposed to fuel it.

I realised, sitting in that room, that the team was optimising for consensus, not progress. Consensus felt productive because it involved talking about the product, thinking about the product, and making decisions about the product. But consensus is not the product. The product is the product. And at some point, someone has to stop talking about what to build and actually build it.

This is the trap most cross-functional teams fall into. The rituals of collaboration (the planning, the syncing, the aligning, the reviewing) become the work. The actual building becomes a secondary activity that happens after the collaboration requirements are met. But the collaboration requirements are never fully met, because every new decision creates a new coordination demand.

Coordination is the work that disguises itself as collaboration. And it wears the disguise so well that most teams cannot tell the difference.

The relay race problem

Think of a relay race. Four runners. The goal is speed. But in most relay races, the baton handoff is where races are lost. Not because the runners are slow, but because the transition between runners introduces friction that running alone does not have.

Now imagine a relay race where the baton handoff takes longer than the running. The runners stand around discussing who should receive the baton next, confirming the handoff protocol. By the time the baton moves, the other teams have finished.

That is how most cross-functional product teams operate. The designers can design. The engineers can build. The product managers can prioritise. But the time spent coordinating between them dwarfs the time spent doing the actual work. The handoff has become the main event.

But the handoff was never supposed to be the main event. It was supposed to be invisible. The best collaborations I have seen in twenty years of product work share one characteristic: you barely notice the coordination happening. It is lightweight, asynchronous, and trust-based. The moment coordination becomes heavy, synchronous, and consensus-driven, the team has crossed a line. Most teams do not notice because they are too busy in meetings to look up.

What small looks like

The smallest team I ever worked on shipped more in three months than the Adobe enterprise team shipped in a year. Not because the small team was better. Because there was nobody to coordinate with. Decisions happened in conversations, not committees. Alignment was implicit, because four people working in the same room on the same problem do not need a bi-weekly alignment review to stay aligned. They just stay aligned, the way a jazz trio stays in time without a conductor.

But organisations do not trust small teams. Small teams feel risky. If the work is important, the logic goes, more people should be involved. More oversight. More review. More input. And every person added to the team adds coordination cost that grows not linearly but exponentially. A team of four has six communication pathways. A team of seven has twenty-one. A team of twelve has sixty-six. The maths is not subtle. But the org chart ignores it because headcount feels like commitment.

I have watched this happen at four companies across three continents. The pattern does not change. The team starts small and fast. Leadership adds people because the project is important. The team slows down. Leadership assumes the problem is harder than expected and adds more people. The team slows down further.

Nobody asks whether the team was faster when it was smaller, because that question implies that some of the people on the team should not be there. And that question is politically expensive in a way that adding another six weeks to the timeline is not.

The honest question

The question most product leaders need to ask, and most will not, is simple. How much of our collaboration is actually producing value, and how much is producing the feeling of value? If your team spends more time talking about the work than doing the work, that is not collaboration. That is theatre. Expensive, well-intentioned, calendar-filling theatre.

But the answer is not to stop collaborating. The answer is to get honest about what collaboration actually requires, which is far less coordination than most organisations believe.

The best collaboration I have ever experienced did not feel like collaboration at all. It felt like building. Two people, a shared understanding of the problem, a whiteboard, and the willingness to make a decision without asking permission from seven stakeholders in three time zones. No alignment meeting. No pre-alignment call. Just the work, and two people doing it.

Somewhere between that moment and the enterprise coordination machine, most teams lose the thing they were trying to create. Not because they stopped caring about collaboration. Because they started caring too much about coordination. And they never noticed the difference.