Do We Collaborate Too Much?

I love collaboration. That’s simplistic, but true: I’m my most energized, creative, and successful self— and I create the best products — when I’m collaborating constantly.

To some extent, that’s just about me. But working with teams across a variety of companies, I’m comfortable saying they could stand to collaborate more. Then I saw this LinkedIn post from Stella Garber:

Garber is right, of course: our collaboration tools and norms can demand so much of us that we never have time to get actual work done. Peer reviews, status updates, standups, team working sessions, cross-functional alignment meetings, leadership check-ins, kickoffs…what are we actually accomplishing? What if we stopped collaborating all the damn time and just got something done?

And yet: I stand by my original premise. Too often, teams aren’t collaborating when they need to. How can both be true? How can we need more collaboration and less collaboration at the same time?

The answer is simple: most of what we call collaboration — what we do in meetings, in Slack or Teams, and on email — isn’t actually collaboration at all. And sometimes it’s organizational dysfunction and inefficiency disguised, excused as collaboration.

After all, it sounds a lot better to say, “Our CMO takes the time to collaborate with her marketing team,” than, “Our CMO spends hours nitpicking everybody else’s work because she wants it done her way.”

Collaboration: Creating Together

Oxford Languages defines collaboration as, “the action of working with someone to produce or create something.” I like that definition but let’s shorten it to “creating together,” and divide it into two categories:

• Generative collaboration happens when we’re all part of the initial act of creation: writing in tandem, pair-programming, sketching on a whiteboard, building a schedule for the offsite in real time.
• Reactive collaboration happens after initial creation: the creator solicits feedback on her creation in order to improve or validate it.

Both categories are valuable, and the distinction is important because they yield different results. Generative collaboration is symmetric: we’re starting together, with everyone’s perspective and ideas on equal footing (at least in theory). Reactive collaboration is asymmetric: the conversation is constrained and guided by the creator’s initial work. There may be space for new ideas, but the focus will inevitably be on refining and evaluating.

Sometimes when it feels like collaboration is bogging us down, it’s because we’re using reactive collaboration in place of generative. I see this frequently on product-development teams.

For example: the PM writes a product-requirements doc (PRD), then presents it to designers and engineers (reactive collaboration). They have big, foundational questions and concerns. The PM is frustrated: she’s created a schedule and there’s no time to go back and revisit the big questions. The designers and engineers are frustrated, too: the PM is dictating how they do their jobs and not taking their perspectives seriously.

The solution: start with generative collaboration. Get together and discuss the project before writing the requirements. The PRD then becomes a reflection of the conversation rather than a precursor to it, resulting in a number of benefits:

• The requirements incorporate the product, design, and engineering lenses from the beginning and benefit from the entire squad’s expertise.
• Any initial disagreement, debate, and iteration happens within that first conversation, with the potential to save everyone time.
• The PRD can be shorter, more along the lines of a product brief, because its job is to record and codify rather than to explain.
• Designers and engineers already know the high-level requirements and can get to work even as the PM is writing the doc.

Similar scenarios — with the same solution — apply at other stages of the process, too. We save design time via generative collaboration before anybody makes a mockup. We reduce wasted engineering cycles by discussing scope and architecture before writing an eng doc or any code.

Synchronous vs. Asynchronous Collaboration

Teams often fall into the trap of assuming asynchronous collaboration is more efficient than synchronous. We look around the meeting, add up everyone’s salaries, and say, “Do you realize how much this meeting is costing us?” But we rarely consider the trade-off: how much we’ll spend debating on Slack, writing and commenting on docs, escalating when that results in angry disagreements (because those happen on Slack), and ultimately scheduling even larger meetings to resolve those disagreements and the related interpersonal issues.

Simply put:

• Asynchronous collaboration is great for simple, tactical questions.
• Synchronous collaboration is great for complex issues, emotionally-intensive topics, and when people are misaligned.
• Usually but not always, generative collaboration should be synchronous.
• When asynchronous discussion becomes verbose or heated, move to synchronous.

Most importantly: asynchronous collaboration will not reliably save you time. Thirty minutes in a meeting can save hours of difficult discussion over email or Slack.

Asynchronous collaboration will not reliably save you time.

Not Collaboration

When things that aren’t collaboration are allowed to masquerade as collaboration, it can mask a need for culture or process change — and, again, can feel like too much collaboration.

Here are some common pitfalls:

• Approval disguised as feedback. If the purpose of the “feedback” meeting is to convince someone to allow something to happen, that’s not collaboration.
• Executive whims disguised as feedback. If, as a PM, you’ve ever heard, “I don’t think our customers will use this,” from an executive who hasn’t seen the research, then you know what I’m talking about. (Designers will be familiar with the dreaded, “Can we do this with fewer clicks?”)
• Dissemination. Here the goal is to let people know a thing, without giving them the opportunity to change it. That’s fine — not everyone needs to collaborate on everything. But it’s not collaboration.
• Buy-in or alignment. There’s a difference between, “Here’s our plan — any issues?” (alignment/buy-in) and “Here’s what we’re thinking of doing — what are we missing?” (reactive collaboration).
• A need to let go. As organizations grow, leaders need to let go of the details and trust their teams. When executives “helicopter in” and thrash projects, it’s often a vestige of legitimate collaboration when the team was smaller. It was fine last year, but now they don’t have the time or context to participate at the necessary level for it to be productive.
• Pure conversation. Teams run on relationships, and those relationships require work. Team lunches, and social hours tackle that head-on; but so do weekly team meetings, 1:1s, and various ad-hoc check-ins. It’s certainly possible to do too much of this, but some is valuable, and it’s distinct from collaboration — even as it will tend to make that collaboration easier.

What’s Your Goal?

So: is your team collaborating too much? Or are you collaborating the wrong way? Or treating non-collaboration activities as collaboration — and potentially excusing destructive behavior along the way?

In the end, what’s true of meetings is true of collaboration in general: start with your goal. What are you trying to accomplish? What sort of activities will best move you toward that goal? Those questions will serve you well whether you’re a PM kicking off a project, a designer brainstorming solutions, a product marketer planning next quarter’s big launch, a leader creating a quarterly planning cadence — or, like me, someone who just wants to create, together.

Does your product-development team need better collaboration? Or different collaboration? Do your PMs, designers, and engineers talk at cross purposes? Is something…off…but you don’t quite know what? I’m available for consulting and fractional leadership roles—drop me a line.