Cross-Team Collaboration

First published at Wednesday, 7 October 2026

Cross-Team Collaboration

This is a blog article out of a series where I reflect on what I learned during funding, growing (, and selling) SaaS product companies. While I write those things down for myself, since I believe self-reflection helps me learn, I also want to share my thoughts with anybody who might be interested. An overview of all related topics can be found below. I have a bunch of these blog posts lined up, so you also might want to follow me if you like this one.

There is a sentence that, once you start hearing it regularly, tells you something is already broken: "we can't deliver because of another team." A rare, specific complaint happens everywhere. A steady background hum across the organisation is different. When you hear it that often, the teams are usually right, and the cause is almost always the same. You have optimised each team's own velocity so hard that you have killed the company's.

The local optimum that starves the global one

It is an easy trap, because every step into it looks responsible. You want teams to be productive, so you measure their output. Story points, throughput, whatever the unit. Each team optimises for its own number, as you asked, and each team's number looks fine. And yet nothing meaningful ships, because the work that matters crosses team boundaries, and at every boundary one team is now waiting on another that has no reason to stop and help.

Each team is locally optimal and the whole is starving. You did not slow the company down by accident. You built an incentive that rewards each team for guarding its own throughput and ignoring everyone else's, and then you are surprised that they guard their own throughput and ignore everyone else's.

The metric rewards not helping

Look at what the measurement actually does. When a team is judged, and its people are paid and promoted, on its own output, you have connected reward directly to not helping other teams. An afternoon spent unblocking a neighbouring team does not show up in your story points. It shows up as you missing your number.

This is Goodhart's law in its plainest form: once a measure becomes a target, it stops measuring what you cared about. You cared about the company delivering. You targeted per-team output. The gap between those two is exactly the cross-team work.

On top of that, the valuable work here is close to invisible. When a team gets another team unstuck, there is no ticket on your board and no line in any dashboard. The effect is real, the whole company moves, but it is diffuse and it lands on someone else's numbers. Work that no metric captures and no reward recognises does not survive in a system that measures and rewards everything else. It quietly stops.

The people you lose are the ones you can least afford to

There is a specific cost that makes this worse than a general slowdown. The people who naturally move between teams, who carry context across boundaries and get others unstuck, are very often the same people who actually understand the business requirements. That is not a coincidence. Real requirements rarely live inside one team's boundary; they span several, and the person who sees the whole shape of one is usually the person who talks to all the teams it touches. These people drive change and push the product toward fit.

Measure hard on per-team output and you do one of two things to exactly these people. You drive them out, because the system keeps telling them their most valuable work is a distraction from their real job. Or you starve them of the time to do it, until they stop. Either way you lose your connective tissue to a spreadsheet, and you usually do not notice until the product stops cohering.

What to do instead

Two things, and neither is a metric.

First, give teams deliberate slack. A team running at a hundred percent of its own capacity has nothing left to help anyone with; the help comes out of the margin. Tom DeMarco made this argument years ago in his book Slack: an organisation optimised for full utilisation loses exactly the responsiveness and cross-cutting work it leaves no room for. Unbooked capacity is what lets the company flex.

Second, because the work is invisible to your metrics, make it visible yourself. Notice cross-team help out loud, value it in the open, talk about the person who dropped their own sprint to unblock another team as someone who did exactly the right thing. A manager publicly rewarding the invisible work is a visible action, and it does far more to produce collaboration than any amount of telling people to collaborate. The cross-connectors are also, not by accident, an informal information network, the one that routes around the filtering and withholding I described in hierarchy exists, so protecting them buys you more than throughput.

This gets harder when the team is distributed. In an office some of the cross-team contact happens by accident, in a hallway or a kitchen. Remote, it happens only if you make room for it, so the slack and the connectors matter more, and you have to arrange the contact on purpose.

Not every organisation will allow any of this, because some are committed to the idea that every team's and every individual's output must be measured and compared. Those organisations get what they measure: locally optimal teams and a company that cannot ship across them.

Summary

Measuring per-team output attaches reward to not collaborating, so the work of one team unblocking another stops, and the people who do it leave or burn out. Give teams real slack, reward the cross-team work out loud, and protect the people who connect. When you hear "we can't deliver because of another team" on repeat, do not blame the teams. That is your own metric talking back to you.

Related topics

In the context of the lessons I have learned during my last years of work, there are several blog posts. This list will be updated with every additional blog post I write (the titles might still change while writing about those topics):

Software Architecture
Remote culture
Leading tech teams
Collaboration with your product team(s)

Subscribe to updates

There are multiple ways to stay updated with new posts on my blog: