The Multi-Team Project

Picture this. You're six weeks into a project that involves four teams. Each team has its own manager, its own roadmap, and its own definition of what "done" means. Your weekly sync has fourteen people in it. Three of them have stopped showing up. One team shipped their piece two weeks ago and declared victory. You're still not sure if their piece actually works with yours. The launch date is eight weeks away. You feel, dimly, that something is wrong, but you can't put your finger on exactly what.

This is what a multi-team project feels like from the inside. Not one big explosion. Just a slow, steady accumulation of small misalignments — each one manageable on its own, but together adding up to a project that moves slower and slower until it stops.

Multi-team projects are the hardest thing most engineers ever do. Not because the technical problems are harder — though they often are — but because you are now managing a system that includes people, incentives, org structures, and communication channels, all of which can fail in ways that no amount of good engineering can fix.

This chapter is about understanding exactly why multi-team work is so much harder than single-team work, and what you can actually do about it.

Why Two Teams Is Not Twice the Work

Here is a fact that surprises people when they first encounter it: adding more people to a project does not add capacity proportionally. It often makes things slower. This seems crazy — more hands should mean more output — but it turns out to be one of the most reliable observations in software engineering. Fred Brooks documented it in 1975 in a book called The Mythical Man-Month, and fifty years later it is still true every day in every company.

The reason is coordination cost. Every time you add a person to a project, you create a new communication link between that person and every other person already on the project. One person is one link to nobody. Two people have one link between them. Three people have three links. Four people have six links. Ten people have forty-five links. Twenty people have one hundred and ninety links.

Each of those links is a potential source of misunderstanding, delay, conflict, and dropped information. Each link requires maintenance — meetings, messages, documents, reviews. The number of links grows with the square of the number of people, not linearly. This is why adding a fifth team to a four-team project doesn't add 25% more capacity. It adds something much closer to zero, and might take capacity away.

  Teams    Links    Meetings/week    Coordination overhead
  ─────    ─────    ─────────────    ─────────────────────
  1        0        0                ~0%
  2        1        1–2              ~5%
  3        3        3–5              ~15%
  4        6        6–10             ~30%
  5        10       10–16            ~50%
  6        15       15–25            ~70%

  Formula: links = n(n-1)/2, where n = number of teams
  

The practical implication is this: before you add another team to a project, you need a very specific reason why that team's contribution is worth the coordination overhead it introduces. "We need more capacity" is not that reason. The right reason sounds more like: "Team X owns the authentication system and we cannot ship without changes to it. We have no choice." You add teams because you have no alternative, not because you want to go faster.

The Hidden Tax Nobody Budgets For

When a project involves multiple teams, there is a category of work that almost never makes it into estimates: the coordination work itself. Not the technical work. The coordination work. The meetings. The emails. The design reviews. The alignment sessions. The "can you just take a look at this" Slack messages that turn into an hour of back-and-forth.

In a single-team project of six engineers, coordination overhead might consume 10-15% of each person's time. In a four-team project with six engineers per team, coordination overhead for the people at the center — the tech leads and the project driver — can easily consume 40-60% of their week. And this is not counted anywhere. It doesn't show up in any roadmap. It doesn't exist in anyone's estimates. It is simply subtracted from the time available to build things.

The Four Failure Modes of Multi-Team Projects

Multi-team projects fail in predictable ways. Understanding these failure modes before they happen is the difference between being able to prevent them and having to explain them after the fact.

Failure Mode 1: The Invisible Dependency

Team A is building a service that needs data from Team B's system. Team A's lead knows this. Team B's lead knows this. Both teams have a vague sense that they'll "sort it out" when the time comes. The time comes. Team A is ready to integrate. Team B's system doesn't expose the data in the format Team A needs. Team B's roadmap is frozen for the quarter. The launch slips six weeks.

This is the invisible dependency failure. Not invisible in the sense that nobody knew it existed — everyone knew. Invisible in the sense that nobody made it concrete. Nobody asked the hard questions early: exactly what data do you need, in what format, at what latency, through what interface? Nobody wrote down the answers. Nobody verified that Team B could deliver what Team A needed before the dependency was on the critical path.

Invisible dependencies are the single most common cause of schedule slippage on multi-team projects. The fix is not complicated, but it requires discipline: make every dependency explicit, concrete, and owned before you start building. We will cover this in detail in Chapter 18. For now, the key insight is that a dependency you have not made concrete is not a dependency — it is a future argument waiting to happen.

Failure Mode 2: The Interface Gap

Team A builds their system right up to a boundary. Team B builds their system right up to the same boundary, from the other side. The day before integration, they discover that both teams made different assumptions about exactly what the interface should look like. Team A sends JSON. Team B expects Protocol Buffers. Team A sends events in order of creation time. Team B's system assumes they arrive in order of event time. Team A uses user IDs. Team B uses account IDs. They are not the same thing.

This is the interface gap. Both teams did their work. Both teams are "done." But the two pieces do not fit together because nobody owned the space between them.

Failure Mode 3: The Diffuse Decision

Large decisions on multi-team projects often have no single owner. Should the new service use REST or gRPC? Should the data be normalized or denormalized? Should the rollout be by region or by user cohort? In a single-team project, these decisions get made quickly — the tech lead decides, maybe after a short discussion. On a multi-team project, these same decisions get discussed in meeting after meeting, with representatives from each team defending their team's interests, and no single person with the authority or responsibility to make the call.

The result is decision paralysis. Weeks go by while the decision sits in committee. Engineers who need the answer before they can proceed get blocked. Some of them make their own local decision and move on, creating an inconsistency that will be discovered during integration. Others simply wait, going slowly on the parts that don't require the decision, which is usually everything.

Diffuse decisions kill velocity. Every day a major decision is unresolved is a day of compounding uncertainty across every team that was waiting for the answer.

Failure Mode 4: The Local Victory

Team B finishes their piece of the project. They have done exactly what they said they would do, on time, at high quality. Their manager is pleased. Their performance review will reflect this. They announce completion and immediately pick up the next item on their own roadmap. From their perspective, the project is done.

From the project's perspective, nothing is done. The project only succeeds if all the pieces work together and ship together. Team B's piece sitting in production, unused and unintegrated, is worthless from a user perspective. But Team B's incentives don't care about the project — they care about their own team's deliverables.

This is the local victory failure. It is not a failure of character or competence. It is a failure of incentive alignment. When teams are measured on their own deliverables rather than on the outcome of the project, they will optimize for their own deliverables. This is completely rational behavior that produces terrible project outcomes.

Interfaces Over Ownership

The single most important shift in mindset for multi-team execution is this: stop thinking about ownership and start thinking about interfaces.

Ownership thinking sounds like: "Team A owns the user service. Team B owns the notification service. Team C owns the billing service." Clean lines. Clear boxes. Everyone knows whose job is whose.

The problem with ownership thinking is that it focuses your attention on what happens inside each box, and leaves the space between boxes undefined. And in a multi-team project, the space between boxes is exactly where things fall apart.

Interface thinking sounds like: "The user service exposes this contract. The notification service expects this input and produces this output. The billing service guarantees these semantics." The interface is the explicit, written, agreed-upon description of exactly what one system promises to another.

When you think in interfaces, a few important things happen:

• Teams can build in parallel because they have a contract to build against, not just a vague understanding of what the other team will eventually produce.
• Changes become explicit. You cannot silently change an interface — any change must be communicated, versioned, and agreed to by every consumer of that interface.
• Testing becomes possible before integration. You can write tests against an interface definition without waiting for the other team to finish their implementation.
• Disputes become concrete. When teams disagree, they disagree about a specific written contract, not about vague intentions. Specific disagreements can be resolved. Vague ones cannot.

What a Good Interface Looks Like

An interface is not just a list of API endpoints. A complete interface definition answers five questions:

Most teams define the first item and think they're done. They've described what they provide. But the other four items are just as important. A caller who doesn't know what to do on a timeout will make up their own policy — and it will probably be wrong. A team that doesn't know what counts as a breaking change will make breaking changes accidentally. A team building against an undefined interface will discover problems at integration time, which is the worst possible time.

The Interface Review

Before any team starts building their piece of a multi-team project, all the interfaces between teams should be written down and reviewed by all parties. This is called an interface review, and it is the highest-leverage meeting on any multi-team project.

An interface review is not a design review. You are not designing the internals of any system. You are agreeing on the contracts that will hold the systems together. The questions you are trying to answer are: does Team A's output match Team B's input? Do both teams agree on error semantics? Do both teams agree on the data model? Are there any cases where Team A thinks they've handled something and Team B is depending on something that hasn't been handled?

The interface review should happen before implementation begins, not during it. Once people have already built to their own assumptions, changing the interface is expensive and politically fraught. Nobody likes being told that the thing they spent three weeks building is wrong. Do this early, when everything is still cheap to change.

The Integration Problem

Integration is when the pieces built by separate teams are first combined and tested as a whole. In single-team projects, integration is usually uneventful — the team has been integrating continuously as they build. In multi-team projects, integration is often where projects nearly die.

The pattern goes like this. Each team spends weeks building their piece. Each team's piece passes all of its own tests. Then integration week arrives. The pieces are connected for the first time. Things break. Not small things — fundamental things. The interface turned out to be slightly different from what was agreed. A team made an assumption that was wrong. An edge case that nobody thought about in isolation turns out to be common in the real combination of systems. The data model has a conflict. The deployment order matters and nobody documented what the right order is.

Integration week becomes integration month. The project slips. Fingers get pointed. People get frustrated. And the root cause was always the same: the teams integrated their planning and not their code.

Continuous Integration Across Teams

The fix for integration problems is not to have better integration testing — though that helps. The fix is to integrate continuously throughout the project, not at the end. This means:

Integration environments from day one. Before any team writes significant code, there should be a shared environment where all teams can deploy their pieces, even if those pieces are incomplete stubs. The pipeline that takes Team A's code and Team B's code and puts them together should be set up and working before anyone has written a single line of feature code. If you wait until the features are built to set up integration, you will discover integration problems at the worst possible time.

Contract tests before implementation tests. A contract test is a test that verifies an interface from the consumer's perspective. Team B writes tests that say "I expect to call Team A's service with this input and get this output." Team A runs Team B's contract tests as part of their own test suite. If Team A changes something that breaks Team B's contract tests, they know immediately — not in six weeks when integration happens.

This pattern, sometimes called consumer-driven contract testing, is one of the most powerful tools available for multi-team projects. It makes interface violations visible the moment they happen, rather than at integration time. Tools like Pact exist specifically for this purpose, but you do not need a specific tool — the pattern is more important than the implementation.

Integration checkpoints in the schedule. Every milestone should include an integration checkpoint — a moment where all the teams' current work is connected and run together. Not tested in isolation. Connected. If you only integrate at the end, you only learn about integration problems at the end. If you integrate every two weeks, you learn about them early, when they are cheap to fix.

The Deployment Order Problem

One integration problem that catches teams off guard is the deployment order problem. When you have multiple services that depend on each other, the order in which you deploy them matters. If Service A depends on Service B, and you deploy Service A before Service B is updated, Service A might break — or worse, silently produce wrong results while it tries to talk to an old version of Service B.

The deployment order problem is particularly nasty because it is often invisible during development. In your development environment, everything is deployed at once or in a known order. In production, deployments happen incrementally, and there is always a window when some services are on the new version and some are on the old version.

The solution is to design your systems to be deploy-order agnostic, or to explicitly document and enforce the deployment order. Deploy-order agnostic systems use techniques like feature flags (the new feature is deployed but not enabled until all systems are updated), backward-compatible interfaces (the new interface is a superset of the old one, so old consumers can still work), and versioned APIs (consumers can request a specific version of the interface until they've updated to the new one).

If you are using an explicit deployment order, document it. Write it down. Give it to whoever runs deployments. And test it: deploy in the documented order in your staging environment before you do it in production. The number of teams that agree on a deployment order in a meeting and then forget to document it is surprising.

Designing for Independent Deployability

The gold standard for multi-team projects is independent deployability. This means each team can deploy their changes to production independently, without coordinating deployment timing with any other team. No "big bang" releases. No deployment windows that require all five teams to be on call simultaneously. Each team ships when they're ready.

Independent deployability sounds like a nice-to-have. It is not. It is the difference between a project that can move at the speed of its fastest team and a project that moves at the speed of its slowest team's deployment schedule.

When teams cannot deploy independently, every deployment is a coordination event. You need all five teams to be ready at the same time, which means the deployment happens when the last team is ready — which is always later than everyone else would like. The teams that are ready early are blocked, which means they can't move on to the next thing. Bugs that are fixed on one team can't reach users until all teams are ready to deploy. The cognitive overhead of coordinating a joint deployment is significant, and the risk is higher because you're changing many things at once.

The Backward Compatibility Requirement

Independent deployability requires backward compatibility. If Team A deploys a new version of their service that changes how it talks to Team B's service, then during the window when Team A's new version is deployed but Team B's update hasn't shipped yet, things must still work. This requires that the interface change be backward compatible — the new version of Team A's service can talk to both the old and new versions of Team B's service.

Backward compatibility is not a technical problem — it is a discipline. It requires that your team consciously thinks about every change to an interface in terms of "will this work with the current production version of every consumer?"

The rules are simple in principle:

• Adding fields to a response is backward compatible. Old consumers ignore fields they don't know about. New consumers use the new fields.
• Removing fields from a response is not backward compatible. Old consumers that depended on those fields will break.
• Adding an optional field to a request is backward compatible. Old producers don't send it; the consumer handles the absence.
• Making an optional field required is not backward compatible. Old producers that don't send it will fail validation.
• Changing the meaning of an existing field is never backward compatible, even if the type stays the same.

Following these rules consistently is the technical foundation of independent deployability. When you follow them, teams can ship at their own pace, and the system remains coherent even during the transition window.

Feature Flags as a Coordination Mechanism

Feature flags are one of the most powerful tools for enabling independent deployability on multi-team projects. A feature flag is a configuration value that controls whether a piece of functionality is active. Code that is deployed but behind a disabled flag is invisible to users — it exists in production, but it does nothing until the flag is turned on.

On a multi-team project, feature flags let each team deploy their changes independently without worrying about partial states. Team A deploys their changes behind a flag. Team B deploys their changes behind the same flag. When all teams have deployed, the flag is turned on simultaneously, and the new functionality becomes active. No coordinated deployment window. No "big bang." Each team ships when they're ready, and the activation happens separately from the deployment.

Running the Multi-Team Rhythm

Beyond the technical mechanics, multi-team projects require a specific operational rhythm — a regular cadence of coordination that keeps everyone aligned without consuming everyone's time.

Most teams try to solve multi-team coordination with more meetings. More meetings make things worse. The problem is not that teams don't talk enough. The problem is that when they do talk, the conversations are not structured to produce alignment. People give status updates that nobody acts on. Issues are raised that nobody owns. Decisions are deferred to the next meeting.

The rhythm you need is simple but specific.

The Weekly Cross-Team Sync

One meeting per week, no more than sixty minutes, attended by one representative from each team — the tech lead or whoever is closest to the interface work. Not the entire team. Not the managers. The people who know where the bodies are buried.

The agenda is fixed and takes the same form every week:

Notice what is not on this agenda: status updates about work inside a single team, roadmap discussions, design reviews, or retrospectives. Those have their own forums. The cross-team sync is exclusively about the things that require coordination across teams.

The Interface Owner

Every cross-team interface should have a named human who owns it. Not a team — a human. Teams don't answer Slack messages at 9am on the day of a launch. Humans do.

The interface owner is responsible for: keeping the interface definition up to date, communicating changes to consumers before they happen, answering questions about the interface from consumers, and being the point of escalation if something breaks at the interface.

This role often falls naturally to the senior engineer on the producing side. That is fine. The important thing is that someone has been explicitly named, both teams know who it is, and that person knows they have the role. Informal ownership — "I mean, Sarah kind of knows the most about it" — is not ownership. It is diffuse responsibility, and diffuse responsibility means nobody will act until the problem is already bad.

The Integration Lead

On a project with three or more teams, there should be a single person who owns the integration: one human whose primary job, for the duration of the project, is to make sure all the pieces fit together. This is the integration lead.

The integration lead is not a project manager. They are a senior engineer who deeply understands every interface in the system, monitors the integration environment continuously, and is the first point of call when integration tests fail. They spend their time — not in meetings, but looking at the actual systems, running tests, reading logs, and asking uncomfortable questions like "why is the user service returning a 503 to the billing service three percent of the time?"

On a small multi-team project, the integration lead might be the same person as the tech lead. On a large one, it is a dedicated role. Either way, someone needs to own integration explicitly. If nobody does, integration will happen spontaneously — chaotically, too late, and at great cost.

When Teams Have Different Velocities

In theory, all teams on a multi-team project are working toward the same deadline at the same pace. In practice, some teams move faster than others. This is almost always true, and the gap is usually larger than expected.

Teams move at different velocities for many reasons. One team has three experienced engineers; another has two new hires and a senior engineer who is also on-call. One team's piece of the project is well-understood and straightforward; another team is exploring new territory. One team has clean technical foundations to build on; another is building on top of legacy systems that fight them at every turn.

The velocity gap creates two specific problems.

The Blocking Problem

The fast team finishes first. Now they're waiting for the slow team. The fast team's engineers are nominally "available" but they can't actually move on to other things because they might need to respond to integration questions, make changes based on the slow team's findings, or remain context-loaded for the integration that is still coming. They're not blocked in the traditional sense — nobody has an out-of-office blocker ticket — but they're not productively executing either. They're in limbo.

The answer here is not to make the fast team wait in a holding pattern. It is to explicitly release them. Once Team A's piece is done and integration-tested against Team B's current stub, Team A should be given a clear "you are done with this phase." They should be pulled back to their own roadmap. They remain available for integration questions but are not waiting around. You will call them back when you need them for integration week.

This requires honesty from you as the project driver about what "done" means for each team at each phase. If you're vague about this, teams will either leave before you need them, or stay around doing nothing when their capacity is needed elsewhere. Precision about done-ness is how you use people's time well.

The Critical Path Problem

The slow team is on the critical path. Every day they slip is a day the overall project slips. You can add resources to the fast team but it won't help — the bottleneck is elsewhere. This is the most frustrating situation in multi-team execution, and it is very common.

Your options when a team is slow on the critical path are limited but real:

Reduce scope. What is the minimum version of that team's work that unblocks integration and launch? Often there are requirements that seemed important three months ago that can be deferred. Talk to stakeholders. Negotiate. A 70% feature shipped on time is usually better than a 100% feature shipped late.

Inject capacity. Temporarily move one or two experienced engineers from the fast team to the slow team. This is expensive in coordination cost — two new engineers need time to get up to speed — but it can work if the slow team is slow because of insufficient capacity rather than technical debt or unclear requirements.

Take the work yourself. If the slow team is a blocker because they own something you could technically own, consider taking that piece of work into your own team. This is a significant escalation and should not be done lightly or without management buy-in. But when a dependency is killing a project and the options are "slip indefinitely" or "pick it up ourselves," picking it up is often the right call.

Be transparent early. The worst thing you can do when you see a velocity gap is to not say anything, hoping it will resolve itself. It rarely does. If you see a team falling behind by week three of a twelve-week project, say something in week three. Not in week ten. The options available in week three are much better than the options available in week ten.

The Meeting That Sounds Like Progress But Isn't

Multi-team projects generate a specific kind of meeting disease. It works like this. Something is going wrong — a dependency is unclear, an interface is undefined, a team is behind. Someone schedules a meeting. Everyone shows up. The meeting is long, engaged, and feels productive. At the end, there is a vague sense that things are clearer now. No decisions have been made. No owners have been named. No follow-ups have been written down.

A week later, the same problem comes up in the weekly sync. Someone asks what happened at that meeting. Nobody is quite sure. Another meeting is scheduled.

This is the meeting loop. It is the principal failure mode of multi-team coordination. Teams feel busy. They attend meetings. They discuss things carefully. And yet nothing moves.

The fix is not fewer meetings — sometimes more meetings are needed. The fix is that every meeting that touches a cross-team issue must end with three things: a decision, an owner, and a deadline. Not "we'll continue exploring this." A specific decision, even a provisional one. A specific human who owns executing it. A specific date by which it will be done.

Accountability Without Authority

Here is the hardest part of running a multi-team project: you are responsible for the outcome, but you do not have authority over the people doing the work. You cannot tell Team B's engineers what to do. You cannot force Team C's manager to reprioritize. You cannot make anyone's sprint planning include the work you need done.

This is not a gap in your authority that will be filled if you ask for more. This is the normal condition of senior engineering. Almost every important thing you will do as a principal engineer or tech lead will involve getting people to do things you have no authority to demand. Understanding this — really internalizing it, not just knowing it intellectually — is one of the biggest shifts in how effective senior engineers operate.

The tools you have are not directive authority. They are influence tools. Understanding them and using them deliberately is what separates people who can run large multi-team projects from people who cannot.

Clarity as Influence

The most underused influence tool in multi-team execution is clarity. When you make a problem concrete and specific, people act on it. When you leave it vague, people defer it.

"Team B needs to deliver their piece soon" does not create urgency. "Team B needs to have the user lookup API returning real data instead of stubs by November 14th or the integration milestone slips by two weeks and we miss the Q4 launch window" creates urgency. Same underlying problem. Completely different response.

Concrete, specific descriptions of problems and deadlines are not nagging. They are the service you provide to busy people who have fifteen competing priorities and need to know, unambiguously, which ones are load-bearing.

Transparency as Accountability

When the status of a multi-team project is visible to everyone — including all the teams' managers and leadership — teams behave differently than when it is visible only to you. This is not about embarrassing anyone. It is about creating shared accountability through shared visibility.

A good project status update, shared weekly with all stakeholders, should include: what is on track, what is at risk, and what is blocked and why. When a team's piece is listed as "at risk because the integration API is not yet defined," that team's manager reads about it. They ask their team about it in the next one-on-one. The team knows their status is visible. Things tend to move.

Transparency is not passive-aggressive. Do not write status updates designed to make a team look bad. Write them with the intent of making the project's actual state visible so that everyone who can help, does help. Framing matters. "Team B's API is blocking integration — they are actively working to resolve this and we expect it done by Friday" is transparent and respectful. "Team B has not delivered their API and this is why we are behind" is accusatory. The first one creates shared urgency. The second one creates defensiveness.

Escalation as a Tool, Not a Weapon

Escalation is the act of involving someone with more authority than you when a decision or a blocker needs resolution at a level above the team. It is a legitimate and important tool. It is also frequently misused.

Escalation is not a complaint. It is not a way to get someone in trouble. It is a way to bring additional resources — specifically, managerial authority — to bear on a problem that cannot be resolved at the team level. Used this way, it is neutral and professional.

The test for whether escalation is appropriate: have you tried to resolve this at the team level, made the problem specific and concrete, given the team a clear deadline, and still not gotten resolution? If yes, escalate. If you've only tried once informally and haven't yet given a clear deadline, try that first.

When you do escalate, escalate to the right level. A dependency between two teams that are two levels below a common manager should be escalated to that common manager, not to the CEO. Over-escalating wastes everyone's time and signals poor judgment. Under-escalating — trying to handle everything at the team level when the problem is fundamentally a management decision — means problems fester until they're crises.

The Integration Test Suite You Actually Need

Let's talk about testing. Not unit tests — those are each team's own business. Integration tests: the tests that verify the system works when all the pieces are connected.

Most multi-team projects have insufficient integration tests because writing integration tests is harder than writing unit tests, it requires understanding multiple systems, and nobody explicitly owns it. The result is that integration problems are discovered manually, by humans, at the worst possible time.

A good integration test suite for a multi-team project covers three categories:

Happy Path Tests

These verify that the most important user flows work end-to-end with real systems, not mocks. A user signs up, the identity service creates an account, the billing service charges the card, the notification service sends a welcome email. Every critical path through the system should have a happy path integration test that runs automatically on every deployment.

Failure Mode Tests

These verify that when one service is unavailable, degraded, or returning errors, the other services handle it correctly and the system degrades gracefully rather than catastrophically. What happens when the fraud service is down during checkout? Does the whole checkout fail, or does checkout succeed with elevated fraud review queued for later? Both might be right, but only one of them is what you actually implemented. The test tells you which.

Contract Tests

Consumer-driven contract tests, described earlier. Each consumer team writes tests that describe exactly what they expect from the producer's interface. The producer runs those tests as part of their continuous integration. Interface violations are caught at the moment of change, not at integration time.

None of these test categories requires fancy tooling. They require discipline — someone deciding they own this work and actually building it. On a multi-team project, this someone should be the integration lead, with tests contributed by each team for their own piece of the stack.

Putting It Together: The Multi-Team Launch Checklist

Before you are ready to launch a system built by multiple teams, you need to be able to answer yes to all of the following questions. If you cannot, you have work left to do.

The Long Game: Building Cross-Team Trust

Everything in this chapter is about the mechanics of multi-team execution. But the mechanics only work when they're sitting on top of something more fundamental: trust between teams.

Teams that trust each other share bad news early. They flag interface changes before making them. They escalate dependencies without it feeling like an accusation. They run integration tests without feeling like they're being monitored. They can have direct, honest disagreements about interfaces and walk away without resentment.

Teams that do not trust each other withhold information, defend their own turf at the expense of the project, use interface discussions as political leverage, and treat integration failures as blame opportunities rather than debugging opportunities.

The mechanics of multi-team execution — interface reviews, contract tests, integration environments — are also trust-building mechanisms. When teams work together on interface design, they build shared context. When contract tests catch a breaking change, the producer feels accountable to the consumer in a concrete way. When the integration environment is shared, teams see each other's work continuously instead of only at integration time.

Trust is built slowly, in small positive interactions, and lost quickly in large negative ones. As the person driving a multi-team project, you have disproportionate influence over both. When teams are working well together, name it out loud. When there's tension, address it directly and privately rather than letting it fester. When a team delivers early or goes out of their way to help another team, acknowledge it publicly. When a team misses a commitment, talk about it as a project problem, not a team failing.

The goal is that by the time the project launches, the teams involved would be willing to work together on the next one. That outcome — a set of teams that have learned to operate effectively together — is worth almost as much as the shipped product itself.

Summary

Multi-team execution is hard. It is also learnable. The engineers who consistently ship large, multi-team projects are not superhuman coordinators. They are engineers who have internalized one fundamental insight: the work happens inside the teams, but the project succeeds or fails in the spaces between them. Every tool in this chapter is a tool for making those spaces visible, explicit, and managed.

The next chapter takes the dependency problem specifically and goes deep on it — how to find every dependency before it bites you, how to manage them as living contracts, and what to do when a critical dependency goes late.