the eng leader shape
Engineering leaders come out of training that sharpens Acuity hard — years of debugging, tradeoff analysis, and systems design instill a strong instinct for signal in noise, and a healthy allergy to hand-wavy reasoning. Resolve is also typically developed: anyone who has survived a rewrite debate, an architecture review, or a VP who wanted to cut a sprint budget has learned to hold a position.
The gap almost always opens in Ken — specifically Room and User. Not because eng leaders aren’t intelligent readers of people, but because they’ve had systematically less exposure to the customer and cross-functional political dynamics than PMs. Room (reading what people in the room actually mean versus what they say) is where eng leaders get blindsided in planning — they read the technical problem correctly and misread the human one. User is where the abstraction from “the system” to “the person using the system” breaks down. You’ve been rewarded your entire career for thinking about the problem, not the person.
Map is variable and often the real differentiator between good and great. Worth (deciding what’s actually worth building among everything you could) is a judgment most eng leaders have an instinct for but rarely articulate — it shows up as a feeling that a feature is a bad idea, not as a crisp framing the product team can work with. Kill is where sunk cost bites hardest: systems you shipped, architectures you championed, migrations you started and couldn’t stop.
On the radar, eng leaders tend to run strong on Acuity and Resolve. Ken is where the gap usually opens, and Kill is where confidence quietly becomes a liability.
the three competencies that decide the year
Worth
Why this one: every architectural bet you make — monolith vs. microservices, build vs. buy, infra investment vs. feature velocity — is a Worth call dressed in technical language. If your Worth judgment is weak, you’re optimizing execution on the wrong problem.
L4 behavior: can articulate, without being asked, which of three pending technical investments has the highest leverage on the actual user outcome — and which one they’d kill if forced, and why.
Failure mode: outsources Worth to the product roadmap. “The PM decides what’s worth building; I decide how.” That division sounds clean and is actively dangerous — the eng leader who can’t call Worth is the one who builds the right thing perfectly and ships it six months after it mattered.
Hold
Why this one: you will be asked, repeatedly, to move fast on a call you think is wrong — by a PM, by a founder, by a deadline. Hold (holding a hard call without folding or bluffing) is what separates the eng leader who earns trust from the one who is managed around.
L4 behavior: when the room wants a different answer, articulates the specific evidence that would change their position — and holds until that evidence exists, not until the pressure gets uncomfortable.
Failure mode: holds the position but not the reasoning — digs in on a call they can no longer defend because reversing now looks like weakness. This is the most common L3→L4 gap we see. The bluff costs more than the flip.
Room
Why this one: this is the competency eng leaders most often underinvest in because they’ve been rewarded for being right about technical things, not for reading what a cross-functional conversation is actually about. Room is the read — what people mean, what’s unsaid, whose credibility is on the line. Getting Room wrong means you win arguments you shouldn’t have and lose trust you didn’t see being spent.
L4 behavior: in a planning meeting where the PM and the design lead are nominally aligned but one of them goes quiet, can name what’s actually happening and surface it before it ships as passive disagreement two sprints later.
Failure mode: treats disagreement as a logic problem — brings more data to a conversation that is fundamentally about status, trust, or fear. Gets confused when the correct argument doesn’t close the discussion.
what to do this week
Pick your last significant architectural call — the one your team executed without much debate. Write a one-page post-mortem: not what you decided, but why you held the position, what evidence you used, and whether you were genuinely open to being wrong or just going through the motions of consultation. If you can’t articulate the evidence that would have changed your mind, you didn’t Hold — you bluffed. Do that before the data forces you to.
read this next
Start with MARK for team calibration — it’s the most immediately operational essay for an eng leader, because your engineers are now making product judgment calls in every AI-assisted spike and architecture doc, and “how do I read whether my team’s judgment is developing or stagnant” is the question that changes how you run 1:1s.
avoid these traps
The technical alibi. Wrapping a Worth or Kill call in technical language so it reads as constraints rather than judgment — “we can’t do X because of Y” when the honest answer is “we shouldn’t do X because of Z.” It protects the eng leader from being argued with. It prevents the team from learning what good judgment looks like.
Sunk-cost architecture. The system you shipped two years ago has a gravitational pull on every decision made near it. Kill (killing your own idea when sunk cost says don’t) is hardest when it’s your code. Recognizing when you’re defending a decision because it’s correct versus because reversing it is embarrassing is an active discipline, not a default.
The room you stopped reading. As eng leaders get senior, they get invited into fewer rooms — and the ones they’re in tend to be pre-agreed. The natural response is to mistake the absence of friction for alignment. Room atrophies fast without deliberate practice. If you haven’t been surprised by what someone actually wanted in a meeting in the last month, you’re not reading the room — you’re reading the deck.
citation
PL Standard v3.1 · MARK for engineering leaders