I’ve been in this industry for twenty-five years and have seen all sorts of companies and projects. You know what I have never heard? Someone saying, “You know what I really like about working here? Cross-team collaboration.”

Unfortunately, this is yet another of the challenges in software engineering where success tends to require the same fundamentals in place simultaneously, but each company fails at it for a different reason—some twisted version of the Anna Karenina principle— and there’s no broader fix that can be applied generally.

But even if the root cause tends to vary, the ways in which a little bit of misalignment compounds into everything from an organization that has too many meetings to get anything done to one where everyone hates everyone else are similar.

I would argue that you must start from the assumption that everyone is trying their best to do what is good for them and for the organization. When that isn’t the case, the priority should be finding and dealing with those people, because no process or org design will help there. Within that base case, why does this happen?

Collaborative Trap

In my experience, there are a few major issues that cause this, and they often build on each other: incentives, incoherent cascading goals, accountability without ownership, and tie-breaking becoming escalation.

The incentive part should be intuitive: people have their own aspirations for themselves and their teams, and they will tend to favor moves that help them fulfill those. This has always been the case, but it has somehow been made worse in recent years by how the industry moved on from the Agile-style “software is a team sport” and almost universally adopted the culture of individual performance developed at Google, where artifacts, testimonials, and visible individual impact can materially affect your compensation and wealth. You can’t show people a game and act surprised when they play it by its rules.

Incoherent cascading of goals happens when a direction is set at the top of the hierarchy but the way it drips down the organization until it reaches the people actually doing the work becomes an inconsistent and even contradictory set of parts that no longer add up to a whole. The classic example is when leadership tells the organization the company needs to improve its financial situation. As the message flows downward, the engineering leader hears that they need to cut costs while the product and marketing leader hears that they must increase revenue. Both sound reasonable, but when the product team pushes for a new feature that requires new infrastructure, they will clash directly with the infrastructure team and their cost-cutting mandate.

The accountability without ownership issue is really about poor organizational design. It’s the situation where you are given accountability over something—its quality, cost, availability, performance—but little or no actual control over how it’s designed and built. That’s when the infrastructure team tells product engineers they are only allowed to use this or that database but offers no support on how to operate it. Or, equally bad, getting support becomes a ritual where the product engineer first has to sit through a lecture about how infrastructure is complex before anything gets resolved. And to make it more fun, the team who is nominally accountable for that database often doesn’t even have actual access to it.

And then there is the matter of tie-breaking becoming escalation. In any group of humans there will inevitably be multiple opinions about what needs to happen and how. Most of the time the diverging parties can find agreement or compromise, but not always. When two parties can’t resolve something, someone needs to make a call. Within a team, that’s the team lead’s job. Between two teams under the same manager, that manager steps in. You can imagine how this gets more complicated as the org gets larger, requiring more meetings, more documents, more arguing instead of delivering. In a typical flat-ish tech company with at least three levels of management, a disagreement between teams from different departments can end up in front of a VP or CTO over something genuinely mundane. And because of where that person sits and how little bandwidth they have for each individual problem, the whole thing becomes ceremonial. Every tie-breaking becomes an escalation.

The Alignment Problem

The real solution to all of this is genuine alignment: teams with a clear and shared picture of the actual goal, incentives that reward working together rather than competing, and a collective understanding of the constraints and trade-offs the whole organization is operating under. When you have that, most of the dysfunction described above either doesn’t emerge or resolves itself quickly.

The most common place to find this naturally is in small teams, be that young startups or companies that have deliberately stayed small. When everyone fits in a room, information travels fast, context is shared, incentives are visible, and disagreements get resolved in minutes rather than weeks. Most importantly, everyone can directly observe the trade-offs the organization is making.

But the reality is that most companies, for good or bad reasons, end up growing beyond the size where these things just happen naturally.

I’ve spent the last fifteen years being brought in when organizations reach the point that a CEO once summarized to me as: “we grew from 20 people to 100 and somehow we’re slower, not faster.”

Invariably, the person trying to hire me has a strong theory of what’s broken. They need to hire more people. They need to replace most of their people. They just need to migrate to microservices, or Rust. These days they definitely need more Agentic AI.

In my experience, what is usually needed is a cohesive engineering strategy, if not a broader business strategy. A good engineering strategy creates a clear relationship between how the company wants to compete and how engineering is organized to support that goal: how teams are sliced, what each team owns, what engineering managers are accountable for, what engineers are expected to optimize for, how incentives and performance reviews are designed, and how trade-offs are made.

But this work takes time, and while it’s happening the company still needs to deliver. That’s where the more pragmatic tools come in. They don’t fix the underlying problem. But they let the organization function well enough while the deeper work gets done.

The pragmatic way to win is not to play

Cross team collaboration always sucks. Sometimes it sucks less, and sometimes it sucks a lot.

While you are incrementally delivering on the engineering strategy that addresses the root causes, you still need to treat the symptoms. My general recommendation is that instead of trying to make cross-team collaboration work by mandate, you should look for the places where cross-team collaboration should not be necessary in the first place.

As discussed earlier, each organization and situation has its own needs and there are many ways to do this—some more productive than others.

Contractual Obligations

The least mature option is to establish a contract between the parties.

This is often softened into language like “a well-defined list of expectations from each side,” but the underlying message is usually less pleasant: these groups do not trust each other to collaborate reliably, so they want a written artifact they can point to when things go wrong and some version of litigation with senior leadership begins—which they already expect to happen.

I am being intentionally negative because this is a terrible signal about the health of the organization. If you are a leader of an organization where coworkers require contracts to work together, you need to do some deep reflection and realize that you are already very behind.

And yet, sometimes this is what you can do right now. This is especially true when you are new to a group or organization and have inherited generations of drama, ambiguity, and misalignment. You may not have the context, authority, people, or political capital to fix the underlying problem immediately. In that situation, a contract can create enough stability for work to continue.

Unfortunately, these contracts can become absurd. I have seen modern technology companies where it was considered acceptable for one team to send another team a Google Doc that might as well have been a DocuSign agreement, written in strange pseudo-legal language, asking the team lead to acknowledge by e-signature that they were committed to delivering a specific scope by a specific date. Needless to say, within a month we discovered that the scope in the document was wrong, the assumptions behind it were broken, and a lot of emergency work was required outside the contract to make reality fit the plan.

The more productive version of this is a team charter. A good charter describes the team’s mission, goals, responsibilities, scope, and constraints. It helps the team build alignment and identity, but it also acts as an API exposed to the rest of the organization. Other teams should be able to understand what this team owns, what it does not own, how to engage with it, what response times to expect, and where the boundaries are.

This may sound bureaucratic—because it is—but it is often the first step toward reducing bureaucracy. When the interface is unclear, every interaction requires negotiation. When the interface is explicit, teams can do more work without constantly re-litigating expectations.

In a mature organization, you should eventually have consistent mechanisms for teams to interact with each other instead of every team inventing bespoke rules. But maturity takes time. A charter is a useful intermediate step: explicit enough to create stability, lightweight enough to avoid turning coworkers into opposing counsel.

When I joined DigitalOcean, I was one of two engineering leaders hired to stabilize the whole engineering department after a CTO abruptly left. Within the first two weeks, the other leader and I got into a room and stared at the LucidChart diagram listing all the teams—about a dozen that covered everything from front-end to hypervisor development. We didn’t know much about the people or the scope yet, but we needed to move fast. So we drew a line down the middle of the diagram. I took the teams on the left, he took the teams on the right.

I then worked with each team to define a charter that included what they perceived as their mission, scope, responsibilities, and how to engage with them. This was a blunt instrument, but it served two purposes. First, it created enough stability for people to keep moving. Second, and more importantly, it forced everyone to make implicit assumptions explicit.

The moment we started writing these things down, disagreements and contradictions surfaced everywhere. Teams believed they owned the same systems. Critical responsibilities had no owner at all. Different groups had completely different ideas of how work was supposed to flow through the organization. The exercise turned vague organizational discomfort into concrete problems that could actually be discussed and fixed.

I quickly worked with the teams to resolve the most immediate conflicts. Even though I barely understood the organization at that point and certainly made my share of bad decisions, a mediocre decision is often better than no decision at all. That was enough to create the stability we needed to deliver on the immediate roadmap.

But beyond the immediate pragmatic unlock, the exercise strongly informed the long-term engineering strategy. The charters and the conversations around them made it obvious that the flat team model we had inherited did not match how work actually needed to flow. What the organization really needed was a layered approach: Product Engineering built on Platform Engineering, which in turn depended on Infrastructure—the people actually racking servers and building out the cloud.

Streaming value

Contracts help create order in a world where scope and responsibilities were distributed in an accidental or even random fashion. But the next step is to make those contracts less necessary by removing as much cross-team interaction from the critical path as possible.

This is where we start getting into organizational design. These are the deeper questions from the long-term strategy: how teams are sliced, who owns what, how incentives work, and how decisions get made. Many of those changes require HR, executive alignment, and broader organizational buy-in. Meanwhile, you still need a pragmatic way to reduce the throw-over-the-wall behavior happening across teams today.

One way to do this is to apply the classic Lean Management playbook and follow the value stream. A value stream is the sequence of activities required to turn an idea, request, or customer need into delivered value. Understanding and improving that stream should be one of the main responsibilities of any line manager, because it ultimately drives everything from team design to systems architecture.

The important move is that you stop treating the org chart as the source of truth and follow the work instead. Where does it start? Where does it wait? Who needs to approve it? Which teams need to be involved? How often does work get thrown over the wall and sit in someone else’s queue?

Going Vertical

Once you do that, the naive conclusion is often: give teams everything they need and remove the handoffs. This is where silos can look very attractive. A team that owns its own infrastructure, operations, roadmap, and delivery path may duplicate effort, but it also avoids spending half its life waiting for another team to prioritize its work.

But silos have their own failure modes. The most drastic example I saw first-hand was as the technology executive for a financial institution. The company had more than ten business units, each responsible for a different segment such as credit products, insurance, or crypto. Each business unit had its own executive, and underneath them their own product and technology leaders.

My role was to build an engineering strategy across all these groups, but I quickly realized they had very little interest in interacting with one another. They saw any dependency on teams outside their business unit as a liability to be mitigated, avoided, or brought internally.

That is how we ended up with more than eight different financial ledger systems and more “universal message brokers” than I could count, each built on a different tech stack by a different team.

As part of building the engineering strategy, I collected evidence and wrote a document for the CEO showing that although each group felt fast locally, the company as a whole was repeatedly rebuilding the same capabilities and moving slower. To my surprise, the CEO did not care at all.

The CEO and many of my peers on the executive team had strong connections with manufacturing and other traditional industries, and little previous experience running software organizations. To them, this was just vertical integration, and vertical integration was common sense.

I can say with confidence that they had built at least ten different companies inside one company. Did it make them fail? Not at all. There were many other aspects of their reality that made this a trade-off they could afford. As much as I can complain that the whole thing was incredibly inefficient, I cannot claim that the company as a whole was unsuccessful.

They chose this trade-off and compensated for it in other ways, mainly by throwing more money at the problem. They had more money than time.

Assuming you do not have as much money as the financial company in this example, one midpoint solution I like is something I first saw working with Alexander Grosse at SoundCloud. Alex had a rule for engineering teams: a team should be able to deliver 80% of its backlog without being blocked by any other team.

The exact number is less important than the principle. Most of a team’s work should be within its own control. Cross-team collaboration should exist, but it should not dominate the execution path.

Obviously, this was not some magic spell Alex cast on the company that made everything perfect overnight. The point is that the rule was aligned with the company’s existing systems and incentives. Every director knew this was part of how they were measured, and the same was true for the engineering managers reporting to them.

They were given a clear expectation, but not a prescribed solution. They had to figure out how to reduce unnecessary dependencies in their own part of the organization. And just as importantly, they were given permission to escalate real blockers without looking like they were land-grabbing. If another team’s ownership boundary was preventing them from executing on this directive, they could take that problem to the VP as a legitimate organizational issue rather than as a political fight.

Topological Sorting

It is normal to start this journey with the blunt tools described above. First you need stability. You need to make responsibilities explicit, reduce the most painful conflicts, and create enough order for work to continue.

But once you get beyond the immediate need for stability—and once you build enough political capital with other leaders and enough credibility with your own teams—you will start thinking about more interesting team structures.

If you keep following the value stream, patterns will emerge. You will find components that are unique to your organization but behave more like internal products and should probably be managed by horizontal teams. You will find capabilities that should not be reinvented by every product team. You will find areas where the real problem is not ownership but enablement, standards, or reducing cognitive load.

And once again, the answer is specific to your organization at that point in time. At SoundCloud, we organized product engineering around personas: Listener, Creator, and Partner. At DigitalOcean, we organized much of product engineering around capabilities such as Droplets, Load Balancers, Observability, and Billing. At SeatGeek, we organized more around classes of systems: On-Prem, Cloud, Front-end Platform, Developer Tools, and Application Platform.

The point is not that any of these models is universally correct. The point is that each was an attempt to make the organization match how value flowed through that company at that moment.

For a long time, this kind of work was something you learned the hard way. When I was figuring out how to do it, the only ways to learn were to talk to friends who might have faced similar challenges, read business management books from the 80s, or, if you were lucky, find a mentor. Over the last decade, not only do we have far more people who have gone through this and were generous enough to share their experience, but some of them have designed models that help us think and talk about these problems in ways tailored to how software organizations actually work.

One such model that I like is Team Topologies, by Matthew Skelton and Manuel Pais. Their model describes a few team archetypes and how they relate: stream-aligned teams that move fast and deliver value to customers, the supporting teams that make them efficient, and a way to handle the moments when cross-organizational change is unavoidable.

The archetypes are useful, but the more important idea is that not every team interaction should look the same. Sometimes teams need to collaborate closely. Sometimes one team should provide a service to another. Sometimes a team should temporarily help another team become self-sufficient and then move on. Team Topologies gives leaders a language for making those interactions intentional instead of letting them emerge accidentally from the org chart.

Like all models, it is wrong in the details. Your company will have its own history, constraints, politics, and product shape. But as a starting point, it is incredibly useful because it moves the conversation away from “who reports to whom?” and toward “how should work flow through this organization?”

Collaborating Fast and Slow

None of these tools is a solution. Contracts, value stream mapping, the 80% rule, Team Topologies—they are all ways of buying time and reducing friction while the deeper work happens. That deeper work, the engineering strategy itself, is slow, political, and never quite finished.

But that is the job. You treat the symptoms so the organization can keep moving, and you treat the causes so that one day it might not need the symptoms managed at all. If you do both well, you eventually arrive somewhere that looks a lot like that small team in a single room—just bigger, and on purpose.