Managing up and sideways

Most engineering leaders describe their peer relationships in terms of what those peers do wrong.

Sales promises things. Finance says no. Product changes its mind.

All three are accurate descriptions of people doing their jobs, and the friction between you is mostly a translation failure.

Sales is compensated for closing, and a customer asked for a date. Finance is accountable for a runway number, and your headcount request is the largest line they'll see all quarter. Product is responding to something they learned and you haven't heard yet.

None of it is an obstacle. Each one is a constraint with a reason attached, and you can find the reasons out by asking.

Know what your CEO is actually worried about

Almost every founder or CEO is carrying two or three specific fears at any given moment, rarely the ones stated at the all-hands.

Runway. One large customer who's gone quiet. Whether this leadership team is good enough for the next stage.

Find out which by asking, then point some of your work at them. The same update you were going to send lands as partnership rather than as reporting.

That's a lesson of its own, "What your boss is carrying." Probably the highest-return thing in this whole track.

The corollary belongs here, though.

Bring them problems before you've solved them. Sometimes.

A CTO who only ever presents resolved situations is easy to work with and impossible to help, and eventually the CEO stops believing the picture is complete.

The update an exec team will read

Written. Short. Structured so the important thing sits in the first three lines.

What shipped, and what it changed for the business. What moved for a customer, or for a number.

What's at risk, named, with what you're doing about it.

What you need from them, specifically. A decision, a person, a conversation with a customer.

If there's nothing, say nothing. The credibility of that section holds for the month when there is something.

What I'd leave out: sprint detail, ticket counts, anything requiring engineering vocabulary, and any metric that only makes sense to you.

A number nobody else can interpret is a number that makes you look like you're managing perception.

What makes an update trusted is that the bad news turns up in it before it turns up anywhere else.

One update naming a problem early, ahead of them hearing it from somebody else, buys more standing than a year of green status.

The date that arrives fully formed

Sales has promised a customer March. Nobody asked you. It's on a slide now.

Push back immediately, before you've even assessed it.

The moment you see it, because the window where that commitment is still soft is measured in days, and after that it hardens into a company promise costing somebody else's credibility to unwind.

And push back on scope rather than on the date.

"That date is unrealistic" starts an argument about your team's speed and casts you as the person who says no. "We can hit March, and here's what will be in it" moves the whole conversation over to a trade.

Trades are what your commercial colleagues do all day.

Then be specific about that trade, in their terms. This version by March. The fuller one by June. Or the whole thing by May if we stop the other project.

Three options with consequences beats one refusal every time.

Say what you need in exchange, in the same conversation. A decision by a date. One person freed up. A feature dropped.

If the answer to all three is no, you've established that the constraint is real and shared, rather than yours alone.

Afterwards, fix the upstream problem separately and calmly. How did a date get committed without engineering in the room.

That's a process conversation for when nothing is burning, and it usually ends in a simple rule. Nothing dated goes into a contract without a named engineering sign-off.

Have that conversation once, instead of having the same argument every quarter.

Credit before you need it

The currency here is credibility, earned in quiet periods and spent in loud ones.

The things that build it are unglamorous.

Doing what you said, on the date you said, repeatedly, including the small things. Flagging problems while they're still cheap. Helping a peer with something that isn't your job. Being the person whose numbers get believed, because they've never once been massaged.

If the relationship with a peer function is bad, the move I'd recommend is to go and spend real time inside their work.

Sit in on sales calls. Watch support handle tickets for an afternoon.

You'll come back with a list of small engineering changes that would remove a disproportionate amount of their pain, and doing two of them changes the relationship more than any number of alignment meetings.

Then spend the credit deliberately, on the few things that actually matter.

A leader who fights every issue has none of it left for the one that counts, and everybody learns to discount their objections.

Sideways is where the real work is

Most of the coordination cost in a company runs across rather than up or down, and it rides on relationships that either exist or don't.

Which argues for something as simple as it sounds. A standing monthly conversation with each of your peer leads, no agenda, nothing project-related.

Half of them will feel like a waste of time for two months and then save you a quarter, because the thing that was going to become a conflict gets mentioned in passing while it's still small.

The alternative is peer relationships made entirely of escalations. Every interaction is an argument. And eventually that's just what the relationship is.