Sideways: peers who don't report to you

As an engineering leader you influence in three directions: upward, toward the people who set your constraints; sideways, toward the peers who run the teams next to yours; and outward, toward the industry beyond your company. Each direction is its own craft and gets its own essay. This one is about sideways, because it is the direction most of us underinvest in, and it is where most org-wide progress happens.

Look at how anything that spans teams ships. A migration or a change to how releases work touches three or four teams, and no single leader can order it done. The shared boss could in theory, but in practice a director who has to arbitrate every cross-team question becomes the bottleneck for all of them, and they know it. So the real decision gets made in the peer layer, in conversations between the leaders whose teams have to do the work, and what goes up is a request for ratification. If you only learn to influence upward, you have learned to win the last step of a process that was already decided without you.

The standard advice on working with peers is mostly right, so start there. People who do not report to you respond to exchange: you cannot assign work to a peer, so you learn what they value and you trade in it. Your first team is the peer group you lead alongside, and only then the people who report to you, because when the leaders next to you succeed, your own team's environment gets better, so their problems deserve a real share of your attention. (Held too tightly that idea curdles into leaders who perform loyalty in the leadership huddle while their own team cannot get a decision out of them, so hold it loosely.) And build the relationships before you need them, because trust is cheap to build in peacetime and nearly impossible to build mid-conflict, when every friendly gesture from someone who needs something from you looks like a negotiation tactic.

All of that is true, and almost all of it was worked out for people who lead without authority: the senior engineer steering an architecture with no reports, whose only tradable asset is credibility, earned through expertise and spent nudging decisions. A peer engineering leader is a different counterpart, because you both hold real authority, just over different territory: you control a roadmap and a team's capacity, and so do they. That changes what you can trade, because the goods that move between two leaders are made of roadmap rather than credibility. The rest of this essay is the playbook for that trade.

Pick the peers your year depends on

The work starts with a selection problem. You do not have the hours to build a deep relationship with every leader in the company, and trying to is how most of us fail at this: attention spread so evenly that no single relationship is deep enough to call on when you need it.

So pick deliberately. When you plan a quarter or a year, read the plan for boundary crossings: which teams' systems you will touch, whose roadmap your dates depend on, who will have to approve or absorb what you ship. That reading yields three to five names, and those are the relationships to invest in, in proportion to dependency rather than to who sits near you or who is pleasant at the leadership meeting. Generic networking would have you invest in whoever you get along with, but this list comes out of the plan, keyed to where you will need a yes this year.

Keep the channel warm in peacetime

If the only times you talk to a peer are escalations and planning collisions, the relationship exists only in wartime, and wartime is the worst moment to start building one.

Build recurring, light-touch contact with the peers on your map, thirty minutes every few weeks. The agenda is the part people get wrong: it is theirs, meaning their top constraint right now, the thing their boss is pressing on, whatever is on fire this week. You are not there to report status or to advance an ask. You are there to refresh your model of their world while nothing is at stake, and to leave each conversation knowing one cheap thing you could do that would help them.

These conversations decay in a predictable way: they drift into status syncs, and a status sync between two busy leaders is the first meeting either of them cancels, because nothing visible breaks the week it gets skipped. Then the channel is dead exactly when you need it. The channel stays alive only as long as the meeting stays useful to them, which is why the agenda stays theirs.

Trade in the goods only leaders hold

Between two engineering leaders, five goods do most of the work, and the standard advice covers none of them, because they only exist between counterparts who both control real resources.

Sequencing. The timing of a peer's dependency can matter more to them than whether you take it on at all. Pulling a blocker forward two sprints can cost you a mild reshuffle and save their quarter.

Capacity. Review bandwidth, an engineer lent for a sprint, a share of your on-call rotation during a peer's crunch. Make the loan explicit and bounded, so it comes back.

Risk absorption. Someone's team has to go first through the painful migration, find the sharp edges, and write up what broke. Volunteering for that position is expensive for you and enormously valuable to everyone behind you, and peers remember who went first.

Credit. Naming a peer team's contribution in the review your boss reads costs you one sentence. It can be the only signal their skip-level ever receives about that work.

Early information. What you know about a coming reorg or a budget shift, shared before it becomes public. Shared carefully, and only when you are free to share it, it is the difference between a peer who plans and a peer who reacts.

Across all five you are hunting the same shape: a trade that is cheap for the giver and valuable for the receiver. The wildly asymmetric ones are how this layer creates value the org chart cannot, since two teams trading sequencing concessions can each save a quarter at the cost of a sprint.

Say a platform lead needs client teams to adopt a new build pipeline, and every client lead has quietly filed it under next quarter. One of them offers to go first instead, in exchange for the platform team pulling one long-standing request of theirs forward. The early adopter absorbs the rough edges and gets their request, the platform lead gets a reference implementation and proof that adoption is survivable, and every later team gets a smoother path. Nobody escalated anything.

Two cautions apply. First, when a peer asks for something you cannot give, refuse early and plainly, because a peer can plan around a fast no, while a slow-walked maybe wastes their planning window and then delivers the no anyway. Refusing without burning the relationship is its own craft. Second, and more important: never let the ledger show. A peer who feels invoiced starts pricing every interaction with you, and priced relationships stop compounding. You are keeping rough reciprocity over the long run, which only works if neither side is counting out loud.

Tell them before you tell the room

When your direction or your staffing is about to change in a way that lands on a peer's team, tell that peer before the announcement: before the all-hands, before their own engineers hear it secondhand and walk it into their standup.

The general case for transparency is a different argument. You control one narrow variable here, the sequence: the information will reach them either way, from you with time to react, or from the room with an audience watching their face. A peer who consistently hears bad news from you first will extend you enormous benefit of the doubt, and a peer who gets surprised in public, even once, will quietly route around you for a long time.

The pull to skip the call is strongest exactly when the call matters most, when the news is embarrassing: a slip, a reversal you argued for. Make the call anyway, because peers absorb bad news from you far better than they absorb being surprised by it in a room.

Defend the absent peer

Sooner or later a peer's team gets criticized, or their contribution is about to go unnamed, in a forum they cannot attend. What you say in that moment builds more trust than anything you could do in front of them, because it is visibly unforced: they are not there, you gain nothing obvious, and the account of what you said will reach them anyway, since hallway accounts always travel.

The move is narrower than loyalty: state their constraint fairly and name their team's contribution, which is neither flattery nor alliance politics. You are defending the fair reading of their situation, the one they would give if they were in the room, rather than their every position. If the criticism is legitimate, do not defend at all, because spending your credibility on a bad position devalues every future defense you mount.

Do this a few times and peers begin doing the same for you when you are the absent one, which spreads a reputation through an org faster than you could ever push it yourself. Building that reputation over a career is its own essay.

Escalate with them

Sometimes none of this resolves it. You and a peer understand each other's constraints, you have looked for trades, and you still disagree, and the cost of not deciding is rising. Escalation is the right move, and it is spending rather than failing: you are spending your shared boss's attention, and a piece of your sideways reputation, to buy a decision. Sometimes the price is right.

The form of the escalation determines most of its cost. Write the disagreement jointly, one document, both positions stated fairly, agreed by both of you before it goes up, and then take it up together. A joint escalation preserves the relationship because it is something you did with the peer rather than to them, and it gives the decider clean inputs instead of two competing hallway versions. The alternative, lobbying the shared boss first and letting the peer find out later, looks like an end-run to the peer and to everyone watching, and that reputation is expensive to win back.

Escalating too early is the matching failure: leaders who go up before doing the peacetime work or looking for a trade teach the org that they cannot operate sideways, and the org responds by routing around them.

Where the playbook ends

The playbook has three boundaries. It is cooperative and assumes a counterpart playing roughly the same game; the peer who fights dirty is a different problem with different rules. Joint escalation means sometimes losing, and what you do after losing is its own discipline. And the first-team caution from the top of the essay applies to everything here: if your own engineers cannot get your attention because you are tending the peer layer, you have inverted the purpose of the whole exercise.

Past those boundaries there is not much more to it than patience. The peer who goes first on your migration, or puts their name next to yours on a joint escalation, is drawing on trust built in thirty-minute conversations, months earlier, when nothing was at stake.