2026-10-29
October 29, 2026
Most cross-team friction is not a personality clash. It is two teams holding different, unspoken answers to "how are we working together?"
Every senior TPM and tech leader has run the playbook for influence without authority: build relationships, earn trust, show up with data, be patient. It works, and it is also incomplete, because it treats influence as a property of you. At scale, influence is largely a property of the arrangement between you and the other party.
Watch where cross-team programs actually stall. A platform team believes it is providing a service with a queue and an SLA. The product team believes it has a partner who will pair on their migration. Both are acting in good faith. Both think the other is being difficult. Nobody ever said which relationship they were in, so each side is quietly punishing the other for violating a contract that only one of them signed.
This issue argues for a small discipline that costs almost nothing: before you try to influence anyone, name the interaction mode. The rest of the issue is how to do that, why it matters more now that organizations are flattening, and a method with a clean pedigree for doing it.
Start with an uncomfortable fact about the senior-IC and TPM role: responsibility routinely exceeds control. Tim Huegdon makes this point in his Leading Without Authority essay, where he lays out an "Influence Pyramid" of technical excellence, communication, relationship building, and strategic thinking, built in that order. It is a sound ladder. Its weakness is that every rung is about what you bring. None of it tells you what to do when the other team has a different model of the relationship than you do.
That gap is widening. The Pragmatic Engineer's Pulse #162 summarized the shift toward fewer middle managers, "team of teams" structures, and engineers making decisions with fewer layers of oversight, along with the trade-off: less managerial bandwidth for mentorship, career progression, and cross-team coordination. Read that last clause as a TPM. When the middle layer thins, the coordination work it used to absorb does not vanish. It falls to whoever is willing to pick it up, which is usually a TPM, a staff engineer, or a director with too many direct reports. You will be asked to produce alignment across teams that have no common manager nearby. Authority was never going to be the tool. Clarity of arrangement is.
Why rapport alone fails. Relationships are expensive and they do not scale. You can build deep trust with perhaps a dozen people on a program. A multi-quarter initiative can touch thirty teams. For most of them you will have a thin relationship at best, and thin relationships break the moment the other team's priorities shift. What survives a priority shift is a shared, explicit expectation: we are collaborating on this for six weeks; after that you consume it as a service; I am here to teach you, not to do it for you. Expectations written down outlast goodwill.
Three modes, three different asks. Matthew Skelton and Manuel Pais, in Team Topologies (2019), define three interaction modes between teams: collaboration (working together for a defined period to discover something new), X-as-a-Service (one team provides, another consumes), and facilitation (one team helps and mentors another). They are usually taught as a way to design org structure. They are more useful, day to day, as a vocabulary for diagnosing the relationship you are in right now.
Each mode implies different behavior. In collaboration, high-bandwidth contact is the point, and it is expensive, so it should be time-boxed. In X-as-a-Service, the right interface is a contract: documented, versioned, supported, with the cost of a request visible to the requester. Demanding a pairing session from a team that has declared itself a service is asking for an exception, and exceptions are the first thing a stretched team refuses. In facilitation, success is the other team no longer needing you, which means your metric is their independence.
Mismatch is the failure mode. Most of the friction you will diagnose this quarter is one of three mismatches. You are collaborating; they think you are a customer filing tickets. You are a customer; they think they are your collaborator and resent the lack of context sharing. Or you are facilitating, and they hear it as supervision. Each of these produces the same surface symptoms: slipped dates, tense status meetings, "they are not responsive." Each has the same fix, which is to say the mode out loud and agree on it.
Modes expire. The subtler point is that the right mode changes. A new capability starts as collaboration, because nobody knows the shape yet. If it works, it should graduate to a service, and the collaboration should end on a date. Programs go sideways when a collaboration that should have ended in week six is still running in month six, quietly consuming the best people on a team that has other commitments. Putting an end date on a collaboration is a gift to the other team's manager, and gifts to other managers are how you buy influence you can reuse.
What this does to your own role. Naming the mode also clarifies what you can honestly ask. Under X-as-a-Service you ask for what the contract promises and escalate through the owner's roadmap process, not through personal favors. Under collaboration you can ask for time and judgment but you owe a clear scope and exit. Under facilitation you owe patience. When you notice yourself reaching for a favor, treat it as a smell: it usually means the interface is undefined and you are paying relationship currency to cover a design gap.
None of this replaces trust. It makes trust cheaper to spend, because less of it is consumed settling what the relationship is.
Try this week. Pick the one cross-team dependency currently causing you the most friction. Write one sentence for each side: "We are in ___ mode, it runs until , and the other team owes me ___ while I owe them ." Send it to your counterpart as a question ("Is this how you see it?"), not an announcement. If their answer differs from yours, you have found the real problem.
What it is. A vocabulary of three ways two teams can work together (collaboration, X-as-a-Service, facilitation), used to make the intended relationship explicit instead of assumed.
When to use it. When a cross-team dependency is producing friction that nobody can attribute to a single cause, when you are starting a multi-team program, or when a long-running collaboration seems to have no end.
How to run it:
When NOT to use it. Skip the ceremony for small, one-off requests between teams that already work well together, and do not impose it as a mandate; it works as a shared language, not a compliance form.
Example: "We are collaborating on the auth migration through the end of Q1; after that, your team consumes the new library as a service with a documented upgrade path."
Pulse #162: Even Fewer Middle Managers and More Flexible Teams? — The Pragmatic Engineer's February 2026 read on flattening hierarchies, and a clear statement of the coordination cost that lands on TPMs when the middle layer thins.
Leading Without Authority: The Senior Engineer's Paradox — Tim Huegdon's Influence Pyramid, with time-boxed tactics (this week, month, quarter, year) you can steal for staff-level coaching.
Engineering Leadership in 2026 — LeadDev editor-in-chief Scott Carey's LDX3 London talk on how 600+ engineering leaders say their roles are changing. The video needs registration, but the slide deck is linked.
"Any organization that designs a system will produce a design whose structure is a copy of the organization's communication structure."
— Melvin Conway, "How Do Committees Invent?" (1968)
Don't miss what's next. Subscribe to Critical Path: