Good Teams Don't Maximize Collaboration. They Design It.

A bad meeting sent me digging into research on team interdependence and led me to a different model: collaboration should be designed task by task, not maximized team-wide. The hardest system to redesign turned out to be my own defaults.

Published: 2026-09-02

Earlier this year, a teammate shared a first-pass analysis of an internal research project with our team. Before the meeting, our manager had told us to expect a quick update followed by a discussion of how the team could help with the analysis. When the discussion turned to what we should do next, I thought the data still needed more context and structure before we could interpret the patterns meaningfully. A colleague preferred to start with the broad themes and decide afterward which areas deserved deeper analysis.

To me, the missing context was part of what made the findings interpretable in the first place, and I became increasingly frustrated as the discussion continued. That frustration eventually became visible. A colleague later told me that some of my reactions had looked dismissive, and when I reviewed the meeting, I could see why.

The feedback first made me question my own default. I had assumed good work should start with enough context, move through clear ownership and independent progress, and bring the group back when its input could materially improve the answer. Because I treated that sequence as obvious, I was too quick to see a different approach as inefficient, and that frustration affected how I responded.

I also looked more closely at the meeting itself. We had spent a lot of time debating interpretations and approaches without moving the work much further. I wanted to understand why a group of capable people trying to help had produced so much friction for so little progress, so I started reading the research on team interdependence, autonomy, synchronous work, and collective problem solving.

Clarity Is Not Just One Thing

My first instinct was that the meeting lacked a clear goal, even though we had received a note beforehand explaining the agenda and how the team would participate. But I wasn't sure whether the goal itself was unclear, or whether I had simply expected a different kind of clarity.

Hu and Liden (2011) distinguish between goal clarity and process clarity. That distinction fit the meeting well. We knew how the discussion was supposed to proceed, but we had less agreement on what the analysis was ultimately meant to produce.

That helped explain why our preferred next steps diverged. If the goal was to surface broad areas worth exploring, starting with themes made sense. If the goal was to interpret those patterns with confidence, I wanted more context first. We were debating the sequence without fully agreeing on what the sequence was supposed to accomplish.

The research also changed what I meant by asking for "more structure". Hackman and Wageman emphasize compelling direction, enabling structure, and supportive context as conditions for effective teamwork. Autonomy does not remove the need for structure either. A field study on autonomy similarly suggests that giving teams freedom works better when people have enough clarity and feedback to direct it. Clarity, in this sense, does not require specifying every analytical step in advance. It gives people enough of a destination to make sensible choices about the route.

There is an important boundary, though. Sometimes people cannot fully define the task before they collaborate. Raveendran, Silvestri, and Gulati (2020) describe knowledge interdependence, where the information needed to understand or structure the task is distributed across different people. In those situations, people may need to combine their expertise before they can decide how the work should be divided.

That left me wondering why some work can be clearly defined and handed to one person, while other work has to take shape through collaboration.

The Unit of Collaboration Should Be the Task

The research on task interdependence gave me a way to answer that question. Different tasks create different dependencies between the people doing them, even within the same team or project.

In a 2012 study of F-16 pilots, researchers broke team performance down into specific tasks that differed meaningfully in their level of interdependence. Teams that more accurately perceived those task-level differences performed better in subsequent flight training evaluations.

The older organization-design literature gives the conceptual lineage. Thompson's (1967) classic framework identifies fundamental forms of interdependence, each requiring different coordination mechanisms. A later meta-analytic review finds that task interdependence and outcome interdependence relate to team performance differently. That made me increasingly skeptical of collaboration as a team-wide default.

The unit of collaboration should be the task, not the team:

• Some work has low interdependence. Depending on the context, one person may be able to clean a dataset, draft an analysis, build a prototype, or write a first version largely independently. This is the kind of work I instinctively push toward individual execution. Clear ownership is often a reasonable choice because the task itself creates little need for continuous coordination.
• Some work is sequential. One person's output becomes another person's input: research informs prioritization, design hands an artifact into implementation, or one person cleans data before another validates the model. Here, the important thing is usually a clear interface and a reliable handoff.
• Other work is reciprocal. People's contributions repeatedly change one another. Technical feasibility changes the product framing, which changes the analysis. A new interpretation sends the team back to inspect different evidence. These tasks need feedback loops and repeated integration because sequential handoffs are no longer sufficient.

For low-interdependence work, my instinct toward clear individual ownership often makes sense. As dependencies increase, that operating model becomes less useful on its own. The issue shifts from who owns the work to where people actually depend on one another.

But knowing that a task requires collaboration still does not tell me whether it needs a meeting. Some dependencies can be handled asynchronously. Others require people to work through the problem together in real time.

Needing Collaboration Is Different From Needing a Meeting

I wanted a better way to distinguish those cases. Rishani, Hoever, and van Dierendonck (2025) studied 176 teams and found a useful tradeoff. Asynchronous communication makes it easier to revisit information, think before responding, and coordinate across schedules. But higher asynchronicity was also associated with lower information elaboration, the deep processing where team members build on, challenge, and integrate one another's contributions.

This gave me a practical way to distinguish when a meeting adds more value than asynchronous work:

• Some work mainly needs information to be produced, inspected, documented, or handed off. Drafting, first-pass analysis, data preparation, reviewing an artifact, or leaving comments often benefit from working separately.
• Other work needs information to be surfaced, combined, challenged, or reinterpreted. Different people may hold critical context. Evidence may support competing interpretations. A technical constraint may change the product decision being discussed. In those situations, real-time interaction becomes more useful.

A meeting should begin where working separately has stopped being useful.

I mean "working separately" broadly. It could be one owner's first pass, several people developing independent views, asynchronous review, or targeted one-on-one conversations. Synchronous time becomes useful when those separate efforts need to be integrated.

But that raised one more question. If a meeting does not always need to be the first move, what should be?

There Is No Single Correct First Move

Vroom's work on participation and decision-making gave me a broader framework for choosing the first move. His model does not assume that more or less participation is inherently better. It asks what the situation requires, including how structured the problem is, where the relevant information sits, and whether implementation depends on other people's commitment.

That made me stop treating owner-first as the default and look for different ways work could begin. Some work can start with an owner, some needs the group to define the problem together, and some benefits from independent thinking before discussion:

• Owner-first. The task-interdependence research made this the clearest case for me. When a task is already well defined and creates little need for continuous coordination, one person can often make meaningful progress independently. This is still my natural default: give someone enough context, let them produce a first pass, and bring others in when their input becomes useful.
• Think-first. This was less intuitive to me. Some work benefits from preserving independent judgment before discussion begins. Minson, Mueller, and Larrick found that when pairs discussed estimation problems without first forming independent judgments, they considered a narrower range of answers and performed worse. A separate study of idea generation found a similar advantage for a hybrid structure: people first generated ideas independently and then worked together, producing more and better ideas than teams that collaborated from the start. Together, these studies made me take independent thinking more seriously as a stage of collaboration, rather than treating it as the absence of collaboration.
• Collective-first. This challenged my default in the opposite direction. The knowledge interdependence research shows why some work cannot be cleanly assigned before people combine what they know. Shared work can also matter when effective coordination depends on a shared understanding of the task, roles, and situation. Mathieu et al. found that stronger shared mental models were positively related to subsequent team processes and performance. In both cases, collective work is doing something that cannot be replaced by simply assigning pieces of an already-understood problem.

This was a bigger correction to my original model than simply becoming more open to meetings. The alternative to a meeting is not always a single owner. Sometimes it is multiple people thinking separately before coming together. And sometimes the meeting really does need to come first.

The Harder System to Design Was Myself

By the end of the research, I had a better explanation for what happened in that meeting. My instinct toward structure and ownership still made sense under certain conditions. The more uncomfortable realization was how quickly I had treated those conditions as universal, and how easily that certainty had turned a process disagreement into a judgment about the people in the room.

After the research, I went back to the situation with a different lens. I repaired the relationship I had strained and talked through the meeting with my manager. Those conversations gave me a few practical habits I want to keep:

• Before debating methods, I try to make sure we agree on what the work is trying to accomplish.
• When someone proposes an approach I disagree with, I try to understand what they are trying to achieve before evaluating the method.
• If I feel strongly about a disagreement, I try to restate the other person's point before moving into critique, so I can check that I have understood it correctly.

The harder part was examining the defaults underneath my reaction. I move quickly toward structure, prefer clear ownership, and tend to challenge directly when I think a process is inefficient. I still value those instincts, but I am more aware now of the assumptions behind them.

This experience pushed me to make that self-examination more explicit. I created a Working With Me page to document how I tend to operate, where those instincts help, and where they can create problems. I want to keep updating it as new situations expose assumptions I have been treating as obvious.

I started this research because I wanted to understand why one meeting had gone so poorly. I was pleasantly surprised to end up with a better model of collaboration and a less finished model of myself.