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 leaders 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. 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: 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. Some leaders perform loyalty in the leadership huddle while their own team cannot get a decision out of them. Hold it loosely.) And build the relationships before you need them. Trust is cheap to build in peacetime and nearly impossible to build mid-conflict, when every friendly gesture 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. 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: the goods that move between two leaders are not made of credibility; they are made of roadmap. 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 deep relationships with every leader in the company, and trying to is the most common failure: 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: 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. This is what separates the move from generic networking: the criterion is where you will need their 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 is enough. The agenda is the part people get wrong: it is theirs. 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. Then the channel is dead exactly when you need it. The way to keep it alive is to keep it useful to them, which is why the agenda stays theirs.

Trade in the goods only leaders hold

This is the center of the playbook, and the part the standard advice does not cover, because it only exists between people who both control real resources. Between two engineering leaders, five goods do most of the work:

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.

The pattern to hunt for across all five: trades that are cheap for the giver and valuable for the receiver. The best trades are wildly asymmetric, which is why this layer can create value the org chart cannot. Two teams trading sequencing concessions can each save a quarter at the cost of a sprint.

A typical shape: 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; every later team gets a smoother path. Nobody escalated anything.

Two cautions. First, when a peer asks for something you cannot give, refuse early and plainly; a slow-walked maybe costs more relationship than a fast no. Refusing without burning the relationship is its own craft. Second, and more important: never let the ledger show. The moment a peer feels invoiced, the relationship turns transactional, and transactional relationships stop compounding. You are not running a balance sheet; you are keeping rough reciprocity over the long run.

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.

This is not about transparency in general; it is about sequencing who hears first. The information will reach them either way; what you control is whether it reaches them 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. A peer who gets surprised in public, even once, will quietly route around you for a long time.

The pull to skip this is strongest exactly when it matters most: when the news is embarrassing, a slip, a reversal you argued for. Make the call anyway: bad news does not kill the relationship; surprise does.

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, and you gain nothing obvious. And word travels; it always travels.

The move is precise: state their constraint fairly and name their team's contribution; not flattery, and not alliance politics. You are not defending their every position; you are defending the fair reading of their situation, the one they would give if they were in the room. 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. That is how a reputation spreads 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 determines the cost. Write the disagreement jointly: one document, both positions stated fairly, agreed by both of you before it goes up. 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.

The matching failure is escalating too early, before you have done the peacetime work and looked for a trade. Leaders who escalate first teach the org that they cannot operate sideways, and the org responds by routing around them.

Where the playbook ends

Three boundaries. This is the cooperative playbook, and it 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.

The leaders who move organizations build these relationships before they need them and maintain them while nothing is wrong. Then, when something important is on the line, they spend them: on the migration that needs a first mover, on the escalation that goes up as one document with two names on it.