{"authors":[{"name":"Csaba Okrona","url":"https://www.linkedin.com/in/ochronus/"}],"description":"Engineering leadership, management guides, and actionable tips for tech leaders.","favicon":"https://leadership.garden/favicon-32x32.png","feed_url":"https://leadership.garden/feed.json","home_page_url":"https://leadership.garden/","icon":"https://leadership.garden/lg.png","items":[{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eLast week I asked an agent to read about 260 comments for me.\u003c/p\u003e\n\u003cp\u003eRich Hickey had published a short piece called \u0026ldquo;\u003ca href=\"https://www.linkedin.com/pulse/ai-tool-rich-hickey-kjl8e/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u0026lsquo;AI\u0026rsquo; is Not a Tool\u003c/a\u003e\u0026rdquo;, and it started two fights at once: 85 comments under the LinkedIn post and well over 170 on Hacker News. I wanted the shape of both threads without giving up an evening, so I pointed an agent at them and got back a tidy digest. Halfway through reading it, I realized I\u0026rsquo;d just done the thing the essay is about. I didn\u0026rsquo;t read the threads. Something else read them, and I read its summary.\u003c/p\u003e\n\u003cp\u003e(I went back and read the parts that mattered. That ate the evening anyway.)\u003c/p\u003e\n\u003cp\u003eIf you run an engineering org, you\u0026rsquo;ve heard \u0026ldquo;it\u0026rsquo;s just a tool\u0026rdquo; in a rollout meeting, usually from someone who wanted the meeting to end. I think Hickey is right about that phrase. I also think managers should take him more seriously than anyone, because most of us already made this trade with our own careers.\u003c/p\u003e\n\u003ch2 id=\"what-hickey-actually-argues\"\u003eWhat Hickey actually argues\u003c/h2\u003e\n\u003cp\u003eMost of the angry replies argue with an essay he didn\u0026rsquo;t write. On HN, people demanded rulings on gdb, cameras, catapults and ffmpeg, as if he\u0026rsquo;d published a taxonomy. When someone on LinkedIn tried the same with lathes and CNC machines, he answered that sorting the world into two bins was never the point. He even agreed with a commenter who called the model itself a lossy knowledge base you query in plain English. His target is the chat products sold as tools for homework, research, writing and coding.\u003c/p\u003e\n\u003cp\u003eHis test for a tool is narrow on purpose: \u0026ldquo;A tool is something you wield.\u0026rdquo; You hold it, it pushes back, you correct, and the correcting is where expertise comes from. A drive-thru is useful, but nobody learns to cook at one. You ask, something else does the work, and what you learn is how to phrase the order. The next model release can make even that knowledge worthless.\u003c/p\u003e\n\u003cp\u003eHe also conceded in the replies that toolness is a spectrum. The more using a thing feels like ordering a sandwich, the less of a tool it is. That concession matters, because most of us use these products near the sandwich end, and the word \u0026ldquo;tool\u0026rdquo; hides it.\u003c/p\u003e\n\u003ch2 id=\"where-the-objections-are-fair\"\u003eWhere the objections are fair\u003c/h2\u003e\n\u003cp\u003eI went through both threads looking for pushback that actually lands, and some of it does.\u003c/p\u003e\n\u003cp\u003ePower tools misbehave too. Several people pointed out that a table saw isn\u0026rsquo;t deterministic, that no two boards are alike, and that a router can throw a workpiece back at you. All true. But nobody hands a table saw a description of a cabinet and walks off to get coffee. The saw goes wrong in your hands, while you watch, and you make the correction. One HN commenter drew the line better than I could: a lathe gets more useful as its operator gets more skilled, while the chat products mostly hand you an accept or reject decision on output you didn\u0026rsquo;t shape.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;It depends on how you use it\u0026rdquo; is harder to wave away. A retired engineer on HN described building a data pipeline of close to 200,000 lines in about six weeks. He reads the agent\u0026rsquo;s reasoning as it runs and interrupts when it heads somewhere he dislikes. He has it build competing prototypes and compare them. Half the codebase is tests, property checks, Lean proofs and TLA+ models. Another commenter framed it as a spec problem: one-shot a whole app and you have a wish machine, but give it a tight interface and your own test suite and it starts to behave like a tool.\u003c/p\u003e\n\u003cp\u003eI believe both of them, and I\u0026rsquo;d happily work with either. Read what they actually do, though. They rebuilt the feedback loop by hand, through their own effort, against the defaults of the product. The retired engineer even granted that Hickey is probably right about it not being a tool for writing code. What he wields is the engineering around the code. Nothing in the product nudges anyone toward working that way, and one commenter offered a simple check: look at how these products get pitched to your employer.\u003c/p\u003e\n\u003ch2 id=\"managers-already-made-this-trade\"\u003eManagers already made this trade\u003c/h2\u003e\n\u003cp\u003eHickey\u0026rsquo;s essay describes the move I made when I went into management.\u003c/p\u003e\n\u003cp\u003eWhen I stopped shipping code for a living, I moved from wielding to requesting. I describe outcomes, other people do the work, and I review what comes back. Most of what Hickey says about automation applied to me. I lost the continuous feedback. My sense of how long things take began to drift. After a few years I could judge a design faster than I could write one, and now that I lead leaders, I sit two steps away from the code.\u003c/p\u003e\n\u003cp\u003eI don\u0026rsquo;t regret it. I did make the trade knowingly, with a rough sense of what it would cost. Management has plenty of words for that cost, starting with the director who is \u0026ldquo;out of touch\u0026rdquo;. We built rituals against it too, like skip-levels and the occasional week spent back on the on-call rotation.\u003c/p\u003e\n\u003cp\u003eTwo HN commenters got to the same place from opposite directions. One said an agent is closer to an employee than to \u003ccode\u003erm\u003c/code\u003e, which is why the industry calls it an agent. Another, less charitably, said paying for Claude and paying a contractor amount to the same act: you\u0026rsquo;ve stopped working. I\u0026rsquo;d call both of those \u003cstrong\u003edelegation\u003c/strong\u003e, the one skill managers get trained on, badly, in their first year. Delegation buys you output and costs you contact with the work. \u003cem\u003eAnd it only holds up while the person delegating can still \u003ca href=\"/dopamine-fracking/\"\u003etell good output from plausible output\u003c/a\u003e.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThat last condition is the one that worries me.\u003c/p\u003e\n\u003ch2 id=\"the-judgment-has-to-come-from-somewhere\"\u003eThe judgment has to come from somewhere\u003c/h2\u003e\n\u003cp\u003eMy judgment came from \u003ca href=\"/cost-of-objection/\"\u003eyears of wielding\u003c/a\u003e. I can review a pull request because I wrote hundreds of bad ones and had them torn apart in review. A senior engineer can steer an agent off a doomed approach because she tried that approach by hand once and watched it collapse.\u003c/p\u003e\n\u003cp\u003eHickey\u0026rsquo;s list of what you lose when something else does your reading (noticing things, learning how an argument hangs together, working out whose work to trust) reads a lot like a junior engineer\u0026rsquo;s first three years. It\u0026rsquo;s also the stock every delegator draws down later.\u003c/p\u003e\n\u003cp\u003eWhen a senior engineer hands a task to an agent, she\u0026rsquo;s spending judgment she already has. When a junior does it, there\u0026rsquo;s nothing to spend yet, and the task that would have built some just got done by something else. \u0026ldquo;Just a tool\u0026rdquo; flattens those two cases into one.\u003c/p\u003e\n\u003cp\u003eOne line from the HN thread stuck with me: a camera is an excellent tool for producing photographs and a poor one for becoming a better painter. (I take a lot of photos. I never learned to paint, and the camera is part of why.) Whether that matters depends on whether your organization still needs painters. \u003cstrong\u003e\u003cem\u003eEvery engineering org I know does\u003c/em\u003e\u003c/strong\u003e. Somebody has to catch the bug the agent keeps putting back. Somebody has to hold a whole system in their head when the agent\u0026rsquo;s context runs out, and notice when a confident answer is wrong.\u003c/p\u003e\n\u003ch2 id=\"why-the-word-matters-in-a-rollout\"\u003eWhy the word matters in a rollout\u003c/h2\u003e\n\u003cp\u003eOne HN commenter dismissed the whole essay as a stipulated definition followed by a \u0026ldquo;so what?\u0026rdquo; Inside a company, the \u0026ldquo;so what\u0026rdquo; is easy to find.\u003c/p\u003e\n\u003cp\u003eAnother made the opposite case on political grounds. Keep calling it a tool, he argued, so humans stay accountable and nobody gets to blame the machine. I see the appeal in public debate. In a planning meeting, I think it backfires.\u003c/p\u003e\n\u003cp\u003eThe usual rollout announcement says new tool, licenses for everyone, and an adoption target. Nobody in that meeting asks what the team will stop learning, because nobody asked that about the last IDE either. So the plan tracks adoption and has no line for skills.\u003c/p\u003e\n\u003cp\u003eCall it automation, or delegation, and different questions show up:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhat does this team stop practicing if the rollout works?\u003c/li\u003e\n\u003cli\u003eWho still needs to do the task by hand, and how do they keep that ability?\u003c/li\u003e\n\u003cli\u003eWhen the output is wrong in a plausible way, who notices, and what experience lets them notice?\u003c/li\u003e\n\u003cli\u003eIf the vendor swaps the model next quarter, what do we lose?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eYou\u0026rsquo;d ask these before automating any other workflow. Calling it a tool is how a team gets to skip them.\u003c/p\u003e\n\u003ch2 id=\"what-id-ask-of-other-leaders\"\u003eWhat I\u0026rsquo;d ask of other leaders\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;m not going to ban anything, and I doubt the no-AI Fridays fix much.\u003c/p\u003e\n\u003cp\u003eStart by naming the mode, task by task. The same product can sit anywhere on Hickey\u0026rsquo;s spectrum. An engineer who asks it to explain an unfamiliar codebase while she traces the calls herself is close to the tool end. An engineer who prompts a feature, skims the diff and merges is ordering a sandwich. Either can be right for the task. I want people to know which one they\u0026rsquo;re doing, and to have picked it.\u003c/p\u003e\n\u003cp\u003eFor early-career engineers, keep some work by hand: debugging their own incidents, writing the first draft of a design, reading the actual RFC instead of a summary of it. Some of them will feel hazed. I\u0026rsquo;d still rather they build the judgment now than \u003ca href=\"/the-senior-engineer-crisis/\"\u003efind out in five years that they never did\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eCount the feedback loop as work. The retired engineer spent a lot of those six weeks on proofs and property tests that no product asked him to write. In plenty of performance conversations, that effort would read as slowness. It should read as the job.\u003c/p\u003e\n\u003cp\u003eAnd drop \u0026ldquo;just a tool\u0026rdquo; from your own vocabulary. When someone on my team reaches for it, I\u0026rsquo;d rather hear what they\u0026rsquo;re automating and what it costs.\u003c/p\u003e\n\u003cp\u003eHickey closes with a warning about what automation does to the people who rely on it. Managers learned the delegation version of that lesson the slow way. We\u0026rsquo;re now handing the same trade to every engineer in the building, mostly without saying so out loud. They deserve to hear it plainly: you can stop doing the work, but know that you stopped.\u003c/p\u003e\n","date_modified":"2026-10-24T13:30:44Z","date_published":"2026-10-24T13:30:00Z","id":"https://leadership.garden/not-just-a-tool/","summary":"“Just a tool” lets AI rollouts skip the hard question: what will your engineers stop learning?","tags":["ai","judgment","growth","management"],"title":"AI Is Not Just A Tool","url":"https://leadership.garden/not-just-a-tool/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eLast quarter I nearly sent my manager a slide I\u0026rsquo;m still slightly embarrassed by.\u003c/p\u003e\n\u003cp\u003eIt had three numbers on it. Merged pull requests across my org were up a little more than double year over year. Median cycle time had dropped by about a third. Almost every engineer was using a coding agent every day. I had the speaker notes written, and I was going to call it our best half for delivery in years.\u003c/p\u003e\n\u003cp\u003eThen I tried to write the fourth bullet, the one about what customers got out of all this. I looked at that empty line for most of an evening. (I cut the slide in the end, which is the only reason I can write this post without wincing.)\u003c/p\u003e\n\u003cp\u003eIf you run managers who run teams, there\u0026rsquo;s a decent chance you have a slide like that open somewhere right now. I don\u0026rsquo;t think the fourth bullet is blank because our teams are doing bad work. Something about the way evidence moves through an org this year makes the first three bullets easy to write and the fourth one close to impossible, and I want to work out what that something is.\u003c/p\u003e\n\u003cp\u003ePaulo André\u0026rsquo;s essay \u003ca href=\"https://hagakure.substack.com/p/quick-to-build-slow-to-know?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eQuick to Build, Slow to Know\u003c/a\u003e is the best thing I\u0026rsquo;ve read on this, and I\u0026rsquo;d send it to anyone who owns a roadmap. His word for it is overshoot. The org learns in days that it can produce more and in months whether it should have, and in that gap sensible people keep expanding. I have one quibble. In his telling, overshoot is something \u0026ldquo;the system\u0026rdquo; does, which is true and lets everyone inside it off a little easy.\u003c/p\u003e\n\u003cp\u003eI sit in the middle of that system, between the teams who see the work and the executives who make commitments on it. From here, the system is mostly people like me deciding which line makes it onto the slide. He closes by asking what kind of leader this needs, and I\u0026rsquo;ll try to answer from my chair.\u003c/p\u003e\n\u003ch2 id=\"speed-reports-itself\"\u003eSpeed reports itself\u003c/h2\u003e\n\u003cp\u003eEvery AI tool we bought this year came with a dashboard. Acceptance rates, sessions per developer, lines suggested, PRs touched. Our engineering metrics platform added an \u0026ldquo;AI impact\u0026rdquo; tab within a quarter. I didn\u0026rsquo;t ask for any of it, and all of it updated daily.\u003c/p\u003e\n\u003cp\u003eNothing in our stack updates daily on whether the work mattered.\u003c/p\u003e\n\u003cp\u003eThink about what would actually tell you. Did customers keep using the feature after the first week? Did support tickets about that flow go down? The integration someone built in an afternoon, does it still work now that the partner changed their API, and is the new service as cheap to run as we said? That evidence doesn\u0026rsquo;t land on a dashboard. Some of it surfaces as a hunch in a retro six months later. Some of it never surfaces, because the people who would have noticed moved teams.\u003c/p\u003e\n\u003cp\u003eSo the evidence is lopsided before anyone decides anything. I don\u0026rsquo;t think most leaders consciously prefer the fast kind. A vendor just delivers it to their inbox every Monday, while the slow kind is a project somebody has to staff, usually somebody who already has a full week.\u003c/p\u003e\n\u003ch2 id=\"the-overshoot-climbs-the-org-chart\"\u003eThe overshoot climbs the org chart\u003c/h2\u003e\n\u003cp\u003eThe route overshoot takes through an engineering org is the reporting chain. Picture how it moves in an org of forty or fifty engineers. An engineering manager sees her team\u0026rsquo;s throughput jump and mentions it in her monthly update. She\u0026rsquo;s careful about it. She notes that review load on her two seniors has gone up and that she isn\u0026rsquo;t sure the extra PRs are the ones that matter. Her director pulls together five of those updates. The caveats don\u0026rsquo;t survive the merge. What survives is \u0026ldquo;throughput roughly doubled across the group.\u0026rdquo; The head of engineering turns that into a planning assumption: if we ship twice as much, next half\u0026rsquo;s roadmap can absorb more. The roadmap goes to the business with dates on it. Sales starts mentioning features to customers.\u003c/p\u003e\n\u003cp\u003eNobody in that chain did anything wrong. Go back and read the manager\u0026rsquo;s original update, and her line about the two seniors is still the most important sentence in it. It just didn\u0026rsquo;t fit the template the director was filling in, which had one cell per team for a headline number. By the time the chain reaches the people who make external commitments, a fast signal has turned into a promise, and the doubt that came with it is sitting in a monthly update nobody above the director will open.\u003c/p\u003e\n\u003cp\u003e(I\u0026rsquo;ve been the director in that story, and I\u0026rsquo;ve been the head of engineering. The caveats are always the first thing to go. I\u0026rsquo;ve cut them myself, because the slide had room for one line.)\u003c/p\u003e\n\u003cp\u003eSome companies go one step further and wire the fast signal straight into incentives. Managers at JPMorgan reportedly \u003ca href=\"https://synodus.com/thought-leadership/when-ai-writes-the-code-the-hidden-bottleneck-slowing-software-releases/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003etrack how often developers use AI coding tools\u003c/a\u003e and factor it into performance. I can see how a well-meaning finance partner gets there: the license line is big, and usage is the one number the vendor will happily hand you. But once usage counts in someone\u0026rsquo;s review, you\u0026rsquo;ve told the whole org which signal keeps score, and people will play to it. I would too.\u003c/p\u003e\n\u003ch2 id=\"scarcity-was-doing-your-prioritization\"\u003eScarcity was doing your prioritization\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve sat in a lot of planning meetings where the most useful sentence anyone said was \u0026ldquo;that\u0026rsquo;s three engineers for six weeks.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eIt was a bad mechanism, and I don\u0026rsquo;t miss those meetings. Estimates got padded by engineers who had been burned before, then haggled down by PMs who had already promised a date to someone, and the number everyone signed off on was a fiction both sides recognized. It also punished ideas for being expensive when it should have punished them for being wrong.\u003c/p\u003e\n\u003cp\u003eBut it did one thing well. It put a price on yes. Somebody had to say out loud that an idea was worth six weeks, in front of the people who would spend those six weeks.\u003c/p\u003e\n\u003cp\u003eThat price has mostly disappeared. A PM asks whether we can try something, and the honest answer is \u0026ldquo;sure, it\u0026rsquo;s an afternoon.\u0026rdquo; The answer is accurate. It also answers the wrong question, because the afternoon was never the expensive part.\u003c/p\u003e\n\u003cp\u003eMost of what a yes costs shows up after the code exists, usually as somebody\u0026rsquo;s on-call shift or somebody\u0026rsquo;s help article, a year after the person who said yes has moved on to other things. AI made none of that cheaper. There\u0026rsquo;s just more of it.\u003c/p\u003e\n\u003cp\u003eI saw this first with internal tooling, not product features. Over one quarter, one of my areas grew a handful of small services, scripts, and dashboards, each built by someone solving a real problem in an afternoon. I found out about most of them when an on-call engineer asked in Slack who owned the one paging her at 2am. Nobody answered for a day.\u003c/p\u003e\n\u003cp\u003eThese days the question I ask in planning is who owns it in twelve months, and what would make us delete it. How long it takes barely comes up anymore. No owner means we don\u0026rsquo;t build it. An owner without an answer to the second part still gets built, but with a date on the calendar when we decide its fate.\u003c/p\u003e\n\u003ch2 id=\"just-ship-faster-fails\"\u003eJust Ship Faster fails\u003c/h2\u003e\n\u003cp\u003eStay SaaSy would tell me I\u0026rsquo;m overthinking this. In \u003ca href=\"https://blog.staysaasy.com/p/the-best-prioritization-is-no-prioritization?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eThe Best Prioritization Is No Prioritization\u003c/a\u003e they argue that scoring frameworks are theater and nobody can prove they prioritized well, so you\u0026rsquo;re better off spending that time getting faster and letting shipping teach you. It\u0026rsquo;s a good post, aimed at a real disease, and it reads like it was written by someone who has sat through one RICE session too many.\u003c/p\u003e\n\u003cp\u003eI agree with more of that than I\u0026rsquo;d like to. Most scoring frameworks I\u0026rsquo;ve watched in practice were a way to dress up a decision someone had already made. I\u0026rsquo;ve also watched a team spend a month ranking a backlog that one week of building would have settled.\u003c/p\u003e\n\u003cp\u003eBut the argument assumes that the lesson from shipping arrives before your next decision. If you change a pricing page on Monday and the conversion data is clear by Friday, speed really can replace judgment. You can choose badly, because you\u0026rsquo;ll find out before it costs much.\u003c/p\u003e\n\u003cp\u003eNow stretch the loop. You ship an integration that enterprise customers will roll out over two quarters. Or an internal platform that other teams will adopt whenever their own roadmaps allow, which in practice means sometime next year. You won\u0026rsquo;t know whether it worked for six months, maybe longer. Meanwhile you\u0026rsquo;ve made twenty more decisions, most of them built on the assumption that the first one was right. If the first one was wrong, you find out about all twenty-one together.\u003c/p\u003e\n\u003cp\u003eThe rule I\u0026rsquo;ve landed on: \u003cstrong\u003espeed can stand in for judgment only when time-to-know is shorter than the time between your decisions.\u003c/strong\u003e Past that point, going faster mostly means more bets placed blind, and build time, the number we used to fight over in planning, becomes the least interesting thing about a proposal.\u003c/p\u003e\n\u003ch2 id=\"time-to-know-is-a-number\"\u003eTime-to-know is a number\u003c/h2\u003e\n\u003cp\u003eI used to treat \u0026ldquo;will we ever find out if this worked\u0026rdquo; as a philosophical question. I now treat it as something you can estimate, roughly, before you start.\u003c/p\u003e\n\u003cp\u003eFor any bet worth a conversation, I want these written down before work starts:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhat would tell us this worked? I want a behavior, something like \u0026ldquo;the forty accounts that asked for this export use it at least twice a month.\u0026rdquo; \u0026ldquo;Engagement\u0026rdquo; doesn\u0026rsquo;t count.\u003c/li\u003e\n\u003cli\u003eWhen is the earliest we could see that?\u003c/li\u003e\n\u003cli\u003eWho is going to look, and is it already on their calendar?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe gap between the ship date and the answer to the second question is time-to-know. For a copy change, days. For a platform migration, or anything enterprise customers adopt on their own schedule, I\u0026rsquo;d bet on two quarters, and I\u0026rsquo;ve rarely lost that bet.\u003c/p\u003e\n\u003cp\u003eWhen we started writing this down, a surprising number of proposals couldn\u0026rsquo;t answer the first question at all. Those were exactly the ones that most needed a no, and under the old regime most of them would have died at the six-week estimate. We also found work where time-to-know was far longer than anyone had assumed. Nobody wanted to stack three follow-up bets on a foundation we wouldn\u0026rsquo;t be able to judge until spring, so we stopped doing it.\u003c/p\u003e\n\u003cp\u003eYou can also shorten it, and right now I\u0026rsquo;d put more leadership attention there than anywhere else. The cheap version is instrumenting before you ship, so that finance asking how the feature is doing isn\u0026rsquo;t the first time anyone looks. The underrated version is shipping to five customers you can phone before shipping to five hundred you can\u0026rsquo;t. Much of what we used to call velocity work, I\u0026rsquo;d now call time-to-know work, and given the choice I\u0026rsquo;d fund it over another round of seat licenses.\u003c/p\u003e\n\u003ch2 id=\"write-down-what-is-enough-before-you-start\"\u003eWrite down what is \u003cem\u003eenough\u003c/em\u003e before you start\u003c/h2\u003e\n\u003cp\u003eOne of the questions Paulo ends on is how long the \u0026ldquo;enough\u0026rdquo; signal takes to show up. My worry is that most teams never decided what \u0026ldquo;enough\u0026rdquo; would look like in the first place. They decide afterward, once they\u0026rsquo;re invested, and nobody invested in a feature has ever looked at mediocre adoption numbers and concluded it should go. So write the kill criteria before the work starts, with a date attached. \u0026ldquo;If fewer than fifteen of the accounts that requested this use it by the end of February, we remove it.\u0026rdquo; Put the review on the calendar on the day you approve the work.\u003c/p\u003e\n\u003cp\u003eThe harder part is cultural. Removing a feature feels like admitting failure, so teams avoid it, and the product slowly fills with things nobody would build today. I\u0026rsquo;ve started counting deletions as delivered results in quarterly reviews. People were suspicious of that at first, and a couple of managers asked if it was a trick to make the numbers look better. It wasn\u0026rsquo;t. A removal that was planned from the start is the slow signal doing its job.\u003c/p\u003e\n\u003cp\u003eWill Larson makes the case that \u003ca href=\"https://lethain.com/revised-rules-of-engineering-leadership/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003equick, good, and durable decisions\u003c/a\u003e are what lets a team cash in on AI\u0026rsquo;s pace. I\u0026rsquo;d push on \u0026ldquo;durable\u0026rdquo;, which most people hear as \u0026ldquo;permanent\u0026rdquo;. A decision with a review date on it lasts longer in practice, because reversing it later is a calendar item, not a political fight.\u003c/p\u003e\n\u003ch2 id=\"what-i-report-upward-now\"\u003eWhat I report upward now\u003c/h2\u003e\n\u003cp\u003eThe version I eventually sent had the same throughput numbers on it. It also had a second column: for each major thing we shipped that half, the date we\u0026rsquo;d know whether it worked and what we\u0026rsquo;d be looking at. Three rows said January. One said \u0026ldquo;we don\u0026rsquo;t yet know how to measure this,\u0026rdquo; which was the most honest line in the deck.\u003c/p\u003e\n\u003cp\u003eMy manager asked about that row more than any other. Good. That\u0026rsquo;s the conversation I wanted to be having.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve kept a few habits from that quarter, and I\u0026rsquo;d push them on anyone in a similar seat:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ePair every fast metric with its slow counterpart and the date it will be known. A throughput number on its own gets turned into a promise by someone two levels up.\u003c/li\u003e\n\u003cli\u003eWhen your managers send caveats up, keep at least one when you summarize. If the template only has room for one line, change the template.\u003c/li\u003e\n\u003cli\u003eArgue against putting AI usage into performance reviews. If the people above you insist, at least make sure they understand they\u0026rsquo;re rewarding the fast signal on purpose.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eA column full of \u0026ldquo;pending\u0026rdquo; is not a comfortable thing to present when every peer in the room is reporting green. The alternative is committing next half\u0026rsquo;s roadmap on the strength of a number that measures typing.\u003c/p\u003e\n\u003ch2 id=\"the-leader-this-needs\"\u003eThe leader this needs\u003c/h2\u003e\n\u003cp\u003ePaulo\u0026rsquo;s closing question was what kind of leader this system needs. My answer is less grand than I\u0026rsquo;d like: someone who can wait for the slow signal without pretending it already arrived.\u003c/p\u003e\n\u003cp\u003eIn practice that\u0026rsquo;s fairly unglamorous. You\u0026rsquo;re the person in planning who keeps asking who owns this in a year, long after people have stopped finding the question charming. Your managers\u0026rsquo; doubts survive your summaries. And when your boss asks whether the big bet worked, you can say \u0026ldquo;we\u0026rsquo;ll know in January\u0026rdquo; and then stop talking, without filling the silence with a projection you don\u0026rsquo;t believe. (That last one is the hardest for me. I\u0026rsquo;m working on it.)\u003c/p\u003e\n\u003cp\u003eThis isn\u0026rsquo;t a case for slower teams, and I\u0026rsquo;d be annoyed if anyone used it as one. I want the speed. I just don\u0026rsquo;t want an org that takes how fast it builds as proof of how fast it learns, and then makes promises on the difference.\u003c/p\u003e\n\u003cp\u003eWe got dramatically faster at building this year, and I can\u0026rsquo;t point to a single week we saved in finding out whether any of it mattered. That gap is most of the job now.\u003c/p\u003e\n","date_modified":"2026-10-17T11:03:00Z","date_published":"2026-10-17T11:03:00Z","id":"https://leadership.garden/you-ll-know-in-two-quarters/","summary":"Why \"just ship faster\" stops working when feedback takes months, and what engineering directors should measure instead.","tags":["ai"],"title":"You'll Know in Two Quarters","url":"https://leadership.garden/you-ll-know-in-two-quarters/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eEvery few months someone on one of my teams asks me how I keep up. It usually comes the week a new model drops, or the week a reorg gets announced, and lately those have been the same week. I don\u0026rsquo;t keep up. I stopped trying a while ago.\u003c/p\u003e\n\u003cp\u003eWhat I tell them instead is to get really good at navigating change. (The version I say out loud has a swear word in it.) In practice that means reacting less, learning principles instead of tools, and shipping more than you read. This is for engineers and engineering leaders who feel like they lose ground every time the ground moves.\u003c/p\u003e\n\u003cp\u003eI think most of them are tracking the wrong number. They count how current they are: which launch threads they\u0026rsquo;ve read, which agent framework they tried last weekend, whether they recognized the thing someone mentioned in standup that everyone nodded at. Knowing about a change feels like adapting to it. Those are two separate skills, and the people I\u0026rsquo;ve seen handle change well are mostly good at the second one.\u003c/p\u003e\n\u003ch2 id=\"react-less\"\u003eReact less\u003c/h2\u003e\n\u003cp\u003eA \u003ca href=\"/tags/culture/\"\u003eReddit post in r/AI_Agents\u003c/a\u003e stuck with me last year. An AI engineer described taking in close to twelve hours of AI content a day: lectures, papers, newsletters, podcasts on the train. Most of the post was in capital letters. He still couldn\u0026rsquo;t keep up, and judging by the replies, nobody else could either.\u003c/p\u003e\n\u003cp\u003eLeaders do a quieter version of the same thing. A reorg gets announced and a manager rewrites the team roadmap that afternoon, before anyone knows what the reorg means for that team. A VP mentions a metric in an all-hands, and by Friday two teams have dashboards for it. I\u0026rsquo;ve done both. Each reaction looked responsible at the time.\u003c/p\u003e\n\u003cp\u003eThe cost shows up a quarter later. A team whose roadmap changes every two weeks learns that roadmaps are suggestions and stops arguing about them, which is worse than arguing. Your team sets its alarm level by yours. Most of those announcements didn\u0026rsquo;t change what anyone should do on Monday, and the ones that did were still there two weeks later, easier to read.\u003c/p\u003e\n\u003cp\u003eThe filter I use is a single question: what does this change about a decision in front of me this month? Usually the honest answer is nothing, so I note it and move on. Sometimes it\u0026rsquo;s \u0026ldquo;I don\u0026rsquo;t know yet\u0026rdquo;, and then I wait until I do. Only an answer that names a specific decision gets action.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Keep up or get left behind\u0026rdquo; is the pitch behind most of the AI courses being sold right now, and it has a grain of truth. If your company moves clouds or your biggest customer leaves, you don\u0026rsquo;t get to wait it out. Nobody needed a newsletter to notice either of those, though. The changes that demand speed are almost always the ones you can\u0026rsquo;t miss.\u003c/p\u003e\n\u003ch2 id=\"master-principles-not-tools\"\u003eMaster principles, not tools\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve written production code in Python, Ruby, OCaml, Clojure, C#, Go, Rust, TypeScript, PHP, Java, and Haskell. Today I\u0026rsquo;d need a reference open for half of them. What carried over between them was everything that wasn\u0026rsquo;t syntax: how to model state, where to draw a boundary, how a failure travels through a system, why the boring option usually wins.\u003c/p\u003e\n\u003cp\u003eTools have always expired. What\u0026rsquo;s new is how fast. Sean Goedecke \u003ca href=\"https://www.seangoedecke.com/you-have-to-beat-the-models-at-something/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003epointed out in August\u003c/a\u003e that \u0026ldquo;make working changes to large codebases\u0026rdquo; was on his list of things models couldn\u0026rsquo;t do at the start of 2026, and had dropped off it by the time he wrote the post. If your edge is knowing the gaps in this quarter\u0026rsquo;s tools, your edge has a shelf life of about a quarter.\u003c/p\u003e\n\u003cp\u003eGoedecke would push back on part of this. His short-term advice is to squeeze every advantage out of the tools, and he\u0026rsquo;s right that refusing them is a losing position. I\u0026rsquo;d go one step further. Fluency in this month\u0026rsquo;s agent doesn\u0026rsquo;t compound. The two durable skills he names, knowing your own system deeply and explaining it clearly, don\u0026rsquo;t live inside any tool, and they\u0026rsquo;re exactly what makes the next tool cheap to pick up.\u003c/p\u003e\n\u003cp\u003ePrinciples are also what make reacting less safe. If you understand why a queue decouples a producer from its consumers, a new streaming product is a variation you can judge in an afternoon. If all you know is the old product\u0026rsquo;s config file, every release is a new world, and you\u0026rsquo;re back to reading everything.\u003c/p\u003e\n\u003cp\u003eThe same holds one level up. Every reorg I\u0026rsquo;ve been through felt new, and none of them changed what people needed from me during it: to know who decides what, and to hear the truth from someone when the answer is bad. Knowing that, I can skip the change-management framework and spend the hour writing to my team instead.\u003c/p\u003e\n\u003ch2 id=\"ship-more-than-you-read\"\u003eShip more than you read\u003c/h2\u003e\n\u003cp\u003eReading is the comfortable way to feel current. You can do it on the couch and it never fails. It also gives you plenty to say in meetings, which is the trap. I\u0026rsquo;ve sat in rooms where everyone could describe the new thing fluently and nobody had used it past the demo. This is also what you can see in most AI hype Youtube videos.\u003c/p\u003e\n\u003cp\u003eMost of what I actually know about coding agents I learned on weekends, building things nobody asked for: a process supervisor in Rust, a self-hosted analytics tool that does what Plausible does, and a weather app that pulls several forecasts and shows where they disagree. None of these will make money, and that was never the point. Each one hit walls no launch post mentions. I learned how often I\u0026rsquo;d throw the agent\u0026rsquo;s output away, and how often my own taste was the only thing between the codebase and a pile of defensive code nobody needed.\u003c/p\u003e\n\u003cp\u003eMy rough rule is an hour of building for every hour of reading about a change. When I let that ratio slip, I can talk about the change well and make decisions about it badly.\u003c/p\u003e\n\u003cp\u003eFor a leader, shipping doesn\u0026rsquo;t always mean code. It means a decision written down, or a pilot with an end date. It can be as small as one change to how the team works that you can point at a month later. When a reorg lands, the manager who sends a one-page note on day two, covering what changes for the team and what doesn\u0026rsquo;t, is navigating it. The manager who forwards the announcement with \u0026ldquo;more details soon\u0026rdquo; is still reading about it.\u003c/p\u003e\n\u003ch2 id=\"pick-fewer-changes\"\u003ePick fewer changes\u003c/h2\u003e\n\u003cp\u003eChange will keep arriving faster than anyone can read about it. That\u0026rsquo;s the one forecast in this post I\u0026rsquo;m sure of, and it stopped bothering me once I stopped trying to absorb all of it. Pick fewer changes. Understand the ones you pick well enough that the lesson carries to the next one, then prove it with something you built.\u003c/p\u003e\n\u003cp\u003eEverything else is staying informed. Being informed was never the job.\u003c/p\u003e\n","date_modified":"2026-10-07T14:35:00Z","date_published":"2026-10-07T14:35:00Z","id":"https://leadership.garden/navigating-change/","summary":"Advice for engineering leaders on reorgs, AI churn, and change: respond to fewer things and prove you adapted by shipping.","tags":["process","learning","leadership"],"title":"Get Really Good at Navigating Change","url":"https://leadership.garden/navigating-change/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eEveryone has a recipe now. Write a more detailed spec, settle the design before anyone touches code, keep the thinking separate from the building, and run the tests at the end to confirm it all went to plan. Put an agent in the middle and Bob\u0026rsquo;s your uncle.\u003c/p\u003e\n\u003cp\u003eThis post is for engineering leaders who keep receiving these recipes. They usually arrive as a link from a founder, a product lead, or their own boss, with a one-line note asking whether we should be doing this too. I want to explain why the recipes sound right, where their evidence comes from, and what I think we should be doing with AI instead.\u003c/p\u003e\n\u003cp\u003eFirst, the part I\u0026rsquo;m glad about. AI has opened software engineering to a much wider audience. People who have never had to design, evolve, or maintain a large system can now describe what they want and get something that runs. That matters, and I have no interest in standing at the door checking credentials.\u003c/p\u003e\n\u003cp\u003eBut the tool lowered the barrier to creating software. It didn\u0026rsquo;t hand anyone the knowledge, experience, and judgment needed to draw sound conclusions about engineering it. \u003cem\u003eA lot of the current methodology talk comes from people who haven\u0026rsquo;t noticed that those are two separate things.\u003c/em\u003e\u003c/p\u003e\n\u003ch2 id=\"why-the-recipes-sound-right\"\u003eWhy the recipes sound right\u003c/h2\u003e\n\u003cp\u003eTaken on their own terms, the recipes make sense, and the people pushing them aren\u0026rsquo;t fools. Most things outside software get built this way. You finish the drawings before you pour the foundation, and nobody calls the architect naive for it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThen again, nobody asks the architect to add three floors every quarter to a building people already live in, while keeping the lifts running.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThey also answer a real frustration. Anyone who has watched an agent wander off, rename half a module, and call an API that doesn\u0026rsquo;t exist wants to pin it down. More text in the prompt feels like more control, and a spec feels like a contract the agent has to honor.\u003c/p\u003e\n\u003cp\u003eSpec Kit, Kiro and their cousins turn this into a pipeline. An agent drafts a requirements document, then a design document, then a task list, and only then the code, followed by tests that check the code against the list. Every stage exists to remove uncertainty before the next one starts.\u003c/p\u003e\n\u003cp\u003eFollow that logic without a brake and you get what François Zaninotto at Marmelab \u003ca href=\"https://marmelab.com/blog/2025/11/12/spec-driven-development-waterfall-strikes-back.html?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003edescribed\u003c/a\u003e when a developer used Spec Kit to show the current date in a time-tracking app. \u003cem\u003eThe output was eight files and roughly 1,300 lines of text.\u003c/em\u003e That\u0026rsquo;s an extreme case, and I wouldn\u0026rsquo;t judge every spec-first workflow by it. It does show where the reasoning ends up. If uncertainty is the enemy, there is always one more paragraph that could reduce it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe trouble is that most of the uncertainty in software doesn\u0026rsquo;t live in the part you can write down in advance.\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"week-one-and-month-nine\"\u003eWeek one and month nine\u003c/h2\u003e\n\u003cp\u003eMost of what we call engineering practice exists because of what happens after the first version works. Small pull requests, tests and observability barely pay off in week one. They start paying with the third requirements change, or the integration that answers 200 with an error in the body. They pay most when someone who has never seen the code has to change it the night before a release.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://en.wikipedia.org/wiki/Manny_Lehman_%28computer_scientist%29?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eManny Lehman\u003c/a\u003e described the forces behind this in the 1970s. A system that people actually use has to keep changing, or it becomes steadily less useful. Each of those changes adds complexity unless someone spends effort removing it. Neither law shows up in a demo. Both show up in next year\u0026rsquo;s roadmap, usually as the reason everything else got slower.\u003c/p\u003e\n\u003cp\u003eI don\u0026rsquo;t think the recipe writers are lying. They report accurately on what they saw, but they saw it at the wrong time. A prototype built over a weekend, or a feature generated from a clean spec in a fresh repository, is a sample that ends just before the expensive part begins. The recipe did work. It just hasn\u0026rsquo;t met the conditions the older practices were built to survive.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAI makes this worse in a specific way. Getting to a working first version used to take weeks, which gave people time to run into at least a few of the later problems. Now it can take an afternoon. Far more people have seen the first week of a system, and far fewer have stayed for month nine. The demo got cheaper, and the evidence behind the conclusions people draw from it got thinner.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eProducing something that works is not the same as showing that we know how to keep it working.\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"the-recipe-is-older-than-its-authors\"\u003eThe recipe is older than its authors\u003c/h2\u003e\n\u003cp\u003eThese ideas are older than most of the people now presenting them as a discovery.\u003c/p\u003e\n\u003cp\u003eThe paper usually cited as the origin of waterfall is Winston Royce\u0026rsquo;s 1970 \u0026ldquo;\u003ca href=\"/tags/culture/\"\u003eManaging the Development of Large Software Systems.\u003c/a\u003e\u0026rdquo; Royce drew the sequential diagram, requirements to design to code to test, and then called that approach \u0026ldquo;risky\u0026rdquo; and said it \u0026ldquo;invites failure.\u0026rdquo; The rest of the paper argues for stepping back to earlier phases, involving the customer throughout, and building a pilot version first so you learn what the real one needs. \u003cem\u003eThe industry kept the diagram and dropped the argument.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eFive years later Fred Brooks told us to plan to throw one away, because we would anyway. Then in 1986, David Parnas and Paul Clements published \u0026ldquo;\u003ca href=\"/tags/culture/\"\u003eA Rational Design Process: How and Why to Fake It.\u003c/a\u003e\u0026rdquo; Their point was blunt. No real project moves cleanly from requirements to design to code, because nobody knows enough at the start to make that possible. They still recommended writing the documents as if it had happened that way, since a clean record helps whoever maintains the system later.\u003c/p\u003e\n\u003cp\u003eThat detail is the one I keep coming back to. The tidy sequence of spec, design, build and verify was always a way to present the work once it was done. The new recipes take that after-the-fact account and run it forwards, as instructions.\u003c/p\u003e\n\u003ch2 id=\"tests-are-how-you-find-out\"\u003eTests are how you find out\u003c/h2\u003e\n\u003cp\u003eThe last step is where the recipe gets testing backwards. It treats tests as the final confirmation that everything was understood correctly up front. Write the spec, generate the code, generate the tests, see green, ship.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIn practice a test is one of the cheapest ways to find out that your understanding was wrong.\u003c/strong\u003e Kent Beck\u0026rsquo;s case for writing the test first was that the test is the first user of your code. If calling the code from a test feels clumsy, you learn that before the design sets. The value lives in the moment the test disagrees with you.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWatch what happens when one agent writes both the code and the tests from the same spec. The tests inherit every assumption the spec got wrong, and so does the code. They agree with each other perfectly and can both disagree with reality. A green build in that setup tells you the agent was consistent. It tells you very little about whether the spec was right.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eSometimes the agent doesn\u0026rsquo;t even get that far. In the same Marmelab write-up, the agent ticked off its \u0026ldquo;verify implementation\u0026rdquo; task without writing a single unit test. It produced manual testing instructions instead, and the checklist still showed done.\u003c/p\u003e\n\u003cp\u003eConfidence is cheap to acquire in this setup. In \u003ca href=\"https://the-decoder.com/ai-coding-can-make-developers-slower-even-if-they-feel-faster/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eMETR\u0026rsquo;s 2025 study\u003c/a\u003e, 16 experienced open source developers took about 19% longer on 246 real tasks when they could use AI tools. Afterwards, they estimated that AI had made them about 20% faster. I don\u0026rsquo;t read that as proof that AI slows people down, since the study was small and the tools have moved on since early 2025.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eI read it as a measurement of how far someone\u0026rsquo;s sense of progress can drift when nothing pushes back.\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"challenging-a-practice-versus-dismissing-it\"\u003eChallenging a practice versus dismissing it\u003c/h2\u003e\n\u003cp\u003eNone of this makes experience infallible. Some practices really were built around constraints that AI removes. Code review designed for a person writing a couple of hundred lines a day may not survive agents producing thousands. Estimation rituals that assume typing is the slow part deserve a hard look. I\u0026rsquo;d worry about any engineering leader who defends every current practice on the grounds that it\u0026rsquo;s current.\u003c/p\u003e\n\u003cp\u003eSo I don\u0026rsquo;t much care whether someone is challenging an old practice. I care whether they know what it was for. A challenge starts from that knowledge and brings evidence that something else does the job better. A dismissal starts from never having hit the problem the practice solves. \u003ca href=\"/tags/culture/\"\u003eChesterton’s Fence much\u003c/a\u003e?\u003c/p\u003e\n\u003cp\u003eThe strongest version of the other side goes like this:\u003c/p\u003e\n\u003cp\u003e\u003cem\u003e\u0026ldquo;The old practices existed because code was expensive to write. Code is now cheap. So the practices can go.\u0026rdquo;\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThat argument is half right. Writing code did get cheaper. \u003cstrong\u003eBeing wrong didn\u0026rsquo;t\u003c/strong\u003e. A bad data model still has to be migrated with live customer data inside it. A public API still carries every behavior someone came to depend on, whether you meant to promise it or not (Hyrum Wright gave that one his name). A wrong assumption about a payment provider still costs real money when it fails in production. None of those costs moved when the typing got faster.\u003c/p\u003e\n\u003cp\u003eWhen a recipe lands in your inbox, three questions separate the two cases quickly:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eWhat problem was the practice you\u0026rsquo;re replacing designed to solve?\u003c/li\u003e\n\u003cli\u003eWhere does that problem go in the new approach? Does it disappear, or does something else absorb it?\u003c/li\u003e\n\u003cli\u003eWhat\u0026rsquo;s the evidence from after the system had to change? The second and the fifth change, not the first build.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSomeone who answers the first question well is usually worth listening to, even when I disagree with where they end up. Someone who can\u0026rsquo;t answer it is guessing, however good the demo looks.\u003c/p\u003e\n\u003cp\u003eIf you\u0026rsquo;re the one deciding whether your organization adopts a recipe, don\u0026rsquo;t settle it in a debate. Run it on a bounded piece of real work and measure past the demo: how long the third change took, how many people other than the author could make it, and what broke in the first month of production. Recipes that survive that are worth adopting. Most of the ones circulating right now have never been asked.\u003c/p\u003e\n\u003ch2 id=\"what-we-could-be-doing-with-it\"\u003eWhat we could be doing with it\u003c/h2\u003e\n\u003cp\u003eThis is the part that frustrates me most. The practices that actually worked, the ones Royce and Brooks and Beck argued for, were mostly limited by cost. We knew we should build a pilot first, try more than one design, test harder, and understand a system before changing it. We usually skipped them because each one cost weeks that nobody would fund. \u003cstrong\u003eAgents took most of that cost away, and so far we\u0026rsquo;re spending the savings on volume.\u003c/strong\u003e\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eTake Brooks\u0026rsquo;s advice about throwing one away. It was hard to follow when a prototype cost a team a month. Today an agent can build two or three rough versions of the risky part of a design in a day, and you can delete all of them by the evening. What broke in each version tells you what the spec needs to say. A spec written after that exercise has something real under it. Written before, it\u0026rsquo;s mostly a guess with good formatting.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eMost teams point their agents at the code. I\u0026rsquo;d point more of them at the spec because \u003cem\u003ethat\u0026rsquo;s where the expensive assumptions live\u003c/em\u003e. Ask the agent for the inputs the spec doesn\u0026rsquo;t handle, the requirements that contradict each other, and the questions a skeptical colleague would raise in review. You don\u0026rsquo;t have to accept any of it. You get the argument earlier, when it costs a paragraph instead of a data migration.\u003c/p\u003e\n\u003cp\u003eVerification can get much stronger. Property-based tests, mutation testing, fuzzing, and contract tests were always valuable and always the first thing cut when a deadline came. \u003cstrong\u003eAgents can write them now, cheaply.\u003c/strong\u003e The rule that matters is independence. Tests should come from a different source than the code: properties a person wrote and an agent expanded, or a separate agent working from the requirements without seeing the implementation. Otherwise you\u0026rsquo;re back to one author agreeing with itself.\u003c/p\u003e\n\u003cp\u003eUnderstanding is where I see the most untapped value. \u003ca href=\"/tags/culture/\"\u003ePeter Naur argued in 1985\u003c/a\u003e that the real product of programming is the programmer\u0026rsquo;s theory of the system, and that the code is only a partial record of it. An agent that traces a request through six services, explains why a module is shaped the way it is, or maps everything that reads from a table is helping someone build that theory faster. Generating code so that nobody has to build the theory at all is a completely different use of the same tool.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.seangoedecke.com/programming-with-ai-agents-as-theory-building/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSean Goedecke describes his own workflow\u003c/a\u003e in almost exactly these terms. He rejects most of what his agents produce, and nearly all his time goes into judging their output against his model of the system. That\u0026rsquo;s what expertise looks like with these tools: plenty of output, most of it thrown away, and the throwing away is the skill.\u003c/p\u003e\n\u003cp\u003eThen there\u0026rsquo;s the complexity Lehman warned about. Every mature codebase has refactors nobody got to and a dependency or two stuck several major versions behind. Most also carry dead code that nobody dares to delete. With good tests around it, an agent can do a lot of that work, and AI ends up slowing the growth of complexity instead of feeding it.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eFor leaders, most of this comes down to what you reward.\u003c/strong\u003e Count the code your agents produced, and you\u0026rsquo;ll get more code. Measure how long the fifth change to a service takes; praise the engineer who threw away four agent attempts before accepting one, and you\u0026rsquo;ll end up with a different kind of team.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThat list needs no new methodology. It needs people who spend the cheap part of the work, the typing, to buy more of the expensive part: finding out what\u0026rsquo;s true before anything depends on it.\u003c/p\u003e\n\u003ch2 id=\"confidently-wrong-at-scale\"\u003eConfidently wrong, at scale\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve \u003ca href=\"/ai-is-an-amplifier/\"\u003ecalled AI an amplifier\u003c/a\u003e before, and I stand by it. The uncomfortable corollary is that a poorly understood idea gets amplified too. It arrives with better prose, a slicker demo, and an audience it could never have reached on its own.\u003c/p\u003e\n\u003cp\u003eMore people building software is good news, and I mean that. What worries me is how many of them take that ability as proof that they understand software engineering. It worries me more when the rest of us let them set the agenda because their demo looked better than our explanation.\u003c/p\u003e\n\u003cp\u003eWe had a real chance to amplify our ability to learn, reason and engineer. So far we\u0026rsquo;re mostly amplifying our ability to be confidently wrong. I don\u0026rsquo;t think that\u0026rsquo;s settled. It won\u0026rsquo;t change on its own, though, and it won\u0026rsquo;t change because somebody writes a better recipe.\u003c/p\u003e\n\u003cp\u003eJudge the next one you\u0026rsquo;re forwarded by what happens on its tenth change. The first demo tells you almost nothing.\u003c/p\u003e\n","date_modified":"2026-09-29T08:54:41Z","date_published":"2026-09-29T08:54:41Z","id":"https://leadership.garden/everyone-has-a-recipe-now/","summary":"AI lowered the barrier to building software, not to understanding it. Why spec-first AI recipes look right in week one and fail by month nine.","tags":["ai","process"],"title":"Everyone Has a Recipe Now","url":"https://leadership.garden/everyone-has-a-recipe-now/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eA staff engineer on my platform team spent the better part of three weeks on a design document. Moving a set of services off a shared Postgres instance in an order that wouldn\u0026rsquo;t take the whole thing down. Careful work. Failure modes were listed out, migration order was argued for rather than asserted, and the parts he wasn\u0026rsquo;t sure about were left standing as open questions.\u003c/p\u003e\n\u003cp\u003eThe first substantive comment came from someone in a different domain entirely. It opened with, \u0026ldquo;I ran this past Claude, and it flagged a few things.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eNine things. Numbered, confidently worded, formatted better than the doc itself. Two were fair. One was a real catch, and I\u0026rsquo;m glad it got raised. The other six were a language model pattern-matching to a generic database migration and missing everything specific to ours, which was the entire content of the document.\u003c/p\u003e\n\u003cp\u003eHe answered all nine. It took him most of a day.\u003c/p\u003e\n\u003cp\u003eThat day is what this post is about.\u003c/p\u003e\n\u003ch2 id=\"what-you-can-do-and-what-you-can-judge\"\u003eWhat you can do, and what you can judge\u003c/h2\u003e\n\u003cp\u003eStart with \u003cem\u003e\u003cstrong\u003etwo\u003c/strong\u003e\u003c/em\u003e measures, not one.\u003c/p\u003e\n\u003cp\u003eYou\u0026rsquo;re good at a few tasks and bad at nearly everything else. Rank yourself across every task your company performs, and your proficiency falls off a cliff. I can run a planning conversation, and I can usually tell you why a team is stuck. I can\u0026rsquo;t design our billing schema, produce a Figma file anyone would want to look at, or close the books for a quarter.\u003c/p\u003e\n\u003cp\u003eNow take a second measure: how well you can judge the output of a task rather than perform it. That one falls off much more slowly. I haven\u0026rsquo;t written production code in our main repository in years, and I can still tell when a design doc is dodging its own hard question or when someone\u0026rsquo;s confidence about a migration isn\u0026rsquo;t supported by anything that has ever happened here.\u003c/p\u003e\n\u003cp\u003eThe reason I can do that has nothing to do with being clever. I have sat through the postmortem for the version of that migration that went badly twice at two different companies. Judging is memory and memory is experience.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/cost-of-objection/capability-bands-stacked-by-task-2_hu_b7c6ae8740d13e60.png\"\n    srcset=\"/cost-of-objection/capability-bands-stacked-by-task-2_hu_deef44abb5f52cae.webp 640w, /cost-of-objection/capability-bands-stacked-by-task-2_hu_839fb0549e4d199f.webp 960w, /cost-of-objection/capability-bands-stacked-by-task-2_hu_bcee9676dc314c4b.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"Performing vs judging\"\n    width=\"1280\"\n    height=\"715\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003eThe band between the two, the work you can assess but not produce, is where management lives. A PM who can\u0026rsquo;t write a line of Go will still catch that the error states are wrong and be right about it. None of that requires being able to do the work. It requires being able to see it.\u003c/p\u003e\n\u003cp\u003eEvery org chart I\u0026rsquo;ve ever drawn assumes that band exists and holds still.\u003c/p\u003e\n\u003cp\u003eThen an agent lifts what you can do across most of that range. Not to expert level anywhere, but to roughly competent on a great many tasks where you used to sit at zero, and over a wide stretch of them producing now runs ahead of assessing.\u003c/p\u003e\n\u003cp\u003eYou know that part. It\u0026rsquo;s been written a dozen times, and I don\u0026rsquo;t have a better version of it.\u003c/p\u003e\n\u003cp\u003eWhat I have is what comes \u003cem\u003e\u003cstrong\u003eafter\u003c/strong\u003e\u003c/em\u003e.\u003c/p\u003e\n\u003ch2 id=\"you-cant-locate-the-edge-of-your-own-judgement\"\u003eYou can\u0026rsquo;t locate the edge of your own judgement\u003c/h2\u003e\n\u003cp\u003eThe comforting response is that sensible people know their limits and ask for help. I believed some version of that for years. The research isn\u0026rsquo;t kind to it.\u003c/p\u003e\n\u003cp\u003eKahneman and Klein spent a long time disagreeing about expert intuition and then wrote \u003ca href=\"https://pubmed.ncbi.nlm.nih.gov/19739881/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ea joint paper in 2009\u003c/a\u003e about where they\u0026rsquo;d converged. Buried in it is something they call fractionation of skill: professionals with real expertise in some tasks get asked to make judgements in adjacent areas where they have none, and the boundary between the two is hard to see. Hard for the professional, and, they add almost in passing, hard for anyone watching. Nothing in the experience of making a judgement tells you which side of the line it came from.\u003c/p\u003e\n\u003cp\u003eThat second half is the one that should bother you if you run performance reviews, because it means I cannot see my engineers\u0026rsquo; boundaries either. I have been rating people on judgement for a decade using a method that amounts to noticing when they sound sure.\u003c/p\u003e\n\u003cp\u003eMost writing on this reaches for Dunning-Kruger about here. I\u0026rsquo;d rather not, for two reasons.\u003c/p\u003e\n\u003cp\u003eThe literature is genuinely contested and has been for twenty years. \u003ca href=\"https://www.sciencedirect.com/science/article/abs/pii/S0160289620300271?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGignac and Zajenkowski\u003c/a\u003e ran the analysis in 2020 using tests designed to rule out regression to the mean and failed to find the effect at all. Later work goes back and forth. The pattern replicates, the mechanism is disputed, and citing it as settled is exactly the sort of borrowed confidence this post is about.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s also the wrong shape. Dunning-Kruger describes people at the bottom of a single domain. What I\u0026rsquo;m describing is people who are genuinely excellent in one domain walking into another without noticing they crossed anything. The engineer who sent those nine comments is excellent at what he does. That was never the issue.\u003c/p\u003e\n\u003cp\u003eThe part of the Kahneman and Klein paper I keep returning to is a smaller observation. \u003cem\u003e\u003cstrong\u003eSubjective confidence\u003c/strong\u003e\u003c/em\u003e, they write, \u003cem\u003e\u003cstrong\u003eis driven by the internal consistency of the evidence a judgement rests on, rather than by the quality of that evidence\u003c/strong\u003e\u003c/em\u003e. Evidence that\u0026rsquo;s flimsy but internally coherent produces judgements held with far too much confidence, stated too assertively, and believed by others more than they deserve to be.\u003c/p\u003e\n\u003cp\u003eRead that again as a description of what comes out of a language model.\u003c/p\u003e\n\u003cp\u003eCoherence is the thing it\u0026rsquo;s optimised for. Coherence is also the only instrument most of us have for gauging our own confidence. So the tool now produces, at industrial volume, exactly the input that defeats the gauge.\u003c/p\u003e\n\u003ch2 id=\"your-judgement-isnt-fixed-it-shrinks\"\u003eYour judgement isn\u0026rsquo;t fixed. It shrinks.\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s the assumption I hadn\u0026rsquo;t examined: that my judgement is a property of me, earned once, sitting there permanently.\u003c/p\u003e\n\u003cp\u003eKahneman and Klein are specific about where skilled judgement comes from, and it takes two conditions. The environment has to be regular enough for valid cues to exist, and you need prolonged practice with feedback that arrives fast and unambiguously. Chess has both. Firefighting mostly has both. Long-range strategy has neither, which is why confident five-year forecasts from senior people are worth approximately nothing.\u003c/p\u003e\n\u003cp\u003eYour ability to judge a code review was built by writing code and then finding out what happened (FAFO, in other words). The \u0026lsquo;finding out\u0026rsquo; is the part that did the work. \u003cstrong\u003eTake it away, and the band narrows.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWe now have a measurement of how fast, and it\u0026rsquo;s worse than I expected.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAnthropic \u003ca href=\"https://www.anthropic.com/engineering/claude-code-auto-mode?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eran a study\u003c/a\u003e on 1,053 paid testers using Claude Code, swapping one ordinary permission prompt partway through each session for an obviously dangerous command. Human reviewers caught it 13.6 percent of the time, against 89 percent for the automated classifier. The number I care about is buried under those two: \u003cem\u003ehuman catch rates ran near 17 percent early in a session and fell to about 5 percent after fifty prompts, while the classifier held flat.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eFifty prompts is one afternoon.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/cost-of-objection/judging-band-shrinks-within-a-session_hu_20d7c479b0019cbe.png\"\n    srcset=\"/cost-of-objection/judging-band-shrinks-within-a-session_hu_16d752ee0eb0aea7.webp 640w, /cost-of-objection/judging-band-shrinks-within-a-session_hu_3066c7f145a5d29a.webp 960w, /cost-of-objection/judging-band-shrinks-within-a-session_hu_4301bc3b8c453dbd.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"Bar chart showing the \u0026ldquo;can judge\u0026rdquo; band shrinking and \u0026ldquo;can produce, can\"\n    width=\"1280\"\n    height=\"579\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003eTreat it with the suspicion it deserves. This is vendor data supporting a vendor\u0026rsquo;s product decision, and Anthropic has published two different figures for how often users approve prompts, 93 percent in one post and 97 percent in another, with no sample size disclosed for either. \u003cem\u003eI would rather have this study run by somebody with no product to ship\u003c/em\u003e. Until then, the direction agrees with everything else available. \u003ca href=\"https://www.sonarsource.com/blog/ai-coding-trust-gap/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u003cstrong\u003eSonar surveyed\u003c/strong\u003e\u003c/a\u003e \u003cstrong\u003eover 1,100 developers and found 96 percent don\u0026rsquo;t fully trust that AI-generated code is functionally correct, while only 48 percent always check it before committing\u003c/strong\u003e. Thirty-eight percent said reviewing AI output takes more effort than reviewing a colleague\u0026rsquo;s.\u003c/p\u003e\n\u003cp\u003eThe reviewing costs more, we do it less, and we get worse at it the more of it we do.\u003c/p\u003e\n\u003ch2 id=\"and-then-it-happens-to-other-peoples-work\"\u003eAnd then it happens to other people\u0026rsquo;s work\u003c/h2\u003e\n\u003cp\u003eEverything above is about judging your own output. The version that cost my engineer a day is second-order, and I think it\u0026rsquo;s the more serious one.\u003c/p\u003e\n\u003cp\u003eThe standard reassurance here is that people distrust machines, so a bot-sourced objection should land softer than a human one. \u003ca href=\"https://escholarship.org/uc/item/9v38k9m6?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLogg, Minson and Moore\u003c/a\u003e tested that in 2019 across six experiments and found close to the opposite. Laypeople shifted their estimates further toward a piece of advice when they believed an algorithm produced it than when they believed a person did. Algorithm appreciation, they called it.\u003c/p\u003e\n\u003cp\u003eThe detail I like best is that the researchers ran their own materials past a mailing list of judgement and decision-making academics, who predicted the opposite result. The people who study this for a living got the direction wrong.\u003c/p\u003e\n\u003cp\u003eThe effect weakened in exactly one group: experienced professionals forecasting in their own field. Those people took less advice from anyone, and the paper is blunt that their accuracy suffered for it.\u003c/p\u003e\n\u003cp\u003eSit with what that combination does to a room. The least qualified person\u0026rsquo;s objection arrives pre-weighted because a machine produced it. The most qualified person is the one least likely to update on anything, including the occasional time the machine is right. As a distribution of who gets listened to, it\u0026rsquo;s close to the worst one available.\u003c/p\u003e\n\u003cp\u003eThen there\u0026rsquo;s volume, and the \u003ca href=\"https://hbr.org/2025/09/ai-generated-workslop-is-destroying-productivity?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eworkslop research\u003c/a\u003e covers that well enough that I won\u0026rsquo;t repeat it: 40 percent of people surveyed had received AI-generated filler in the previous month, costing them roughly two hours each. But that work is about output being dumped on colleagues, and critique is a worse object than output. You can ignore a bad document. A numbered list of objections against your design creates an obligation, and declining to answer it looks like you can\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eThe cost of generating a plausible objection has gone to roughly zero. The cost of answering one hasn\u0026rsquo;t moved at all. Anyone in the company can now open an unbounded line of credit against a specialist\u0026rsquo;s week, and the specialist has no standing to refuse.\u003c/p\u003e\n\u003cp\u003eThat asymmetry is what cost my engineer his day. The quality of the AI output barely mattered.\u003c/p\u003e\n\u003ch2 id=\"what-im-actually-doing-about-it\"\u003eWhat I\u0026rsquo;m actually doing about it\u003c/h2\u003e\n\u003cp\u003eEighteen months in, I\u0026rsquo;m running experiments rather than reporting results. Some have earned their place.\u003c/p\u003e\n\u003ch3 id=\"predict-then-look\"\u003ePredict, then look\u003c/h3\u003e\n\u003cp\u003eThe only way to find out where your judgement actually stops is to make a call and then learn whether it was right. So make the call in writing, before the answer is available.\u003c/p\u003e\n\u003cp\u003eConcretely, on my team: before you open the agent\u0026rsquo;s review of your own diff, write down the two things you think it will flag. Before the incident review, write your one-line causal hypothesis. Before you read the vendor\u0026rsquo;s benchmark, write the number you expect. Keep them in a file with dates on them.\u003c/p\u003e\n\u003cp\u003eLook at the file every few weeks. Your hit rate, split by domain, is your judgement rendered as data instead of as a feeling, and it\u0026rsquo;s the only version of it you\u0026rsquo;ll ever get, because subjective confidence is measuring the wrong thing.\u003c/p\u003e\n\u003cp\u003eThe failures teach more than the hits. If you sit down to write the prediction and find you\u0026rsquo;ve got nothing to write, you\u0026rsquo;ve located the edge of your competence precisely in about fifteen seconds, without needing anyone\u0026rsquo;s permission or a framework or a workshop. That blank line is the entire diagnostic.\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a companion question I now ask before approving anything: what would have made me reject this? When I couldn\u0026rsquo;t answer, what I did was processing rather than review. I\u0026rsquo;ve been on the wrong side of that distinction plenty of times, usually on a Friday.\u003c/p\u003e\n\u003ch3 id=\"calibrate-the-machine-before-trusting-it-as-a-judge\"\u003eCalibrate the machine before trusting it as a judge\u003c/h3\u003e\n\u003cp\u003eUsing AI to review AI is the obvious move, and it isn\u0026rsquo;t automatically wrong. Look again at why Anthropic\u0026rsquo;s classifier beat their humans. It\u0026rsquo;s a different model from the one proposing the action; it evaluates a tool call it didn\u0026rsquo;t generate, and it was measured against 1,053 planted known-bad commands. Independence and ground truth.\u003c/p\u003e\n\u003cp\u003eMost in-house AI reviews have neither. It\u0026rsquo;s the same model family reading its own output, and nobody has ever checked whether it catches anything.\u003c/p\u003e\n\u003cp\u003eThe failure mode there is not that the reviewer misses things. Researchers at Emory and Tokyo \u003ca href=\"https://arxiv.org/pdf/2606.28438?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ewatched code models\u003c/a\u003e gate their own training data using their own confidence signals, and the gate slid into what they call a rubber-stamp regime: acceptance scores climbing while benchmark correctness fell. The reviewer got more satisfied as the work got worse. A metric that improves while the thing it measures degrades is the most expensive kind of instrument to own, and every team I know that has bolted AI review onto their pipeline is currently flying on one without having calibrated it.\u003c/p\u003e\n\u003cp\u003eThe fix is cheap, and almost nobody does it. Once a month, hand your AI reviewer a diff with a known bug in it. Flip a comparison operator. Delete an authorisation check. See whether it says anything at all. If you\u0026rsquo;ve never run that test, what you have isn\u0026rsquo;t a reviewer; it\u0026rsquo;s a reassurance generator. The same test works on your test suite, incidentally, and there it\u0026rsquo;s called mutation testing.\u003c/p\u003e\n\u003ch3 id=\"write-down-who-decides\"\u003eWrite down who decides\u003c/h3\u003e\n\u003cp\u003eThis is the one I resisted longest because it sounds like the sort of process a company adds shortly before it loses the ability to ship anything.\u003c/p\u003e\n\u003cp\u003eFor most of my career, the right to overrule someone was rationed by a friction nobody ever wrote down. You didn\u0026rsquo;t challenge the database expert on index strategy because assembling a credible counter-argument would have cost you a week you didn\u0026rsquo;t have. That friction was doing real organisational work. It allocated decision rights without anyone having to be explicit about them, and because it was invisible, nobody noticed it doing the job or thought to replace it.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s gone. Ninety seconds now buys a credible-looking counter-argument on any topic in the company.\u003c/p\u003e\n\u003cp\u003eSo the allocation has to become explicit, because the mechanism that used to handle it quietly has been removed. Who has the final call on schema changes, on what ships this quarter, on who carries the pager, and on when an incident is over? Written down, in the boring place where such things live.\u003c/p\u003e\n\u003cp\u003eAnd one rule attached to it, which is the part that actually helps: \u003cstrong\u003ean AI-generated critique is an input to the owner, not a claim on the owner\u0026rsquo;s time.\u003c/strong\u003e The owner reads it and decides. No point-by-point rebuttal is owed to anyone, and silence on item seven is not a concession.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThat reads like bureaucracy. In practice, it\u0026rsquo;s permission to not respond, which is currently the scarcest resource your specialists have.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"the-strongest-objection\"\u003eThe strongest objection\u003c/h2\u003e\n\u003cp\u003eA tech lead I work with pushed back on all of this, and her version was sharp enough that I\u0026rsquo;ve changed my mind about part of it.\u003c/p\u003e\n\u003cp\u003eHer argument: this is gatekeeping with better manners. Experts have always deflected challenges with \u0026ldquo;you don\u0026rsquo;t have the context,\u0026rdquo; and a decent fraction of the time the challenge was right and the deflection was self-protection. AI has handed a voice to people who were locked out of technical conversations entirely. And now here\u0026rsquo;s the head of engineering, explaining why their objections should be easier to dismiss.\u003c/p\u003e\n\u003cp\u003eShe\u0026rsquo;s right about the old system. I\u0026rsquo;ve watched it work exactly the way she describes. A principal engineer once killed a proposal from a junior on my team by out-arguing her in a design review. He wasn\u0026rsquo;t right. He was faster and had more standing, and she didn\u0026rsquo;t have the vocabulary to defend a good instinct. I said nothing at the time. I\u0026rsquo;ve thought about it a lot since.\u003c/p\u003e\n\u003cp\u003eThe repair for that was never to make objections free, though. Free objections don\u0026rsquo;t transfer power to the junior engineer with the good instinct. They transfer it to whoever has the most spare time to generate them, and in my experience that isn\u0026rsquo;t the person with the sharpest read on the system. What she was actually asking for was that the decision-maker\u0026rsquo;s reasoning be legible and their record visible. Both of those come from writing predictions down and comparing them to outcomes, which is where this started.\u003c/p\u003e\n\u003ch2 id=\"where-this-leaves-me\"\u003eWhere this leaves me\u003c/h2\u003e\n\u003cp\u003eI don\u0026rsquo;t have a number for how often I\u0026rsquo;m right about work I couldn\u0026rsquo;t do myself. Neither do you. Nobody has ever measured it, partly because until recently the question had no consequences and partly because the answer would be unflattering to a lot of people whose authority rests on the assumption.\u003c/p\u003e\n\u003cp\u003eStart measuring it on yourself. Write the prediction down before you look. You\u0026rsquo;ll find the edge of what you can actually judge inside a month, which is considerably faster than thinking about it will ever get you there.\u003c/p\u003e\n\u003cp\u003eThen hold the same standard outward and stop accepting critique from people who have never checked where their own edge is. Including, on a bad week, me.\u003c/p\u003e\n","date_modified":"2026-09-12T14:50:00Z","date_published":"2026-09-12T14:50:00Z","id":"https://leadership.garden/cost-of-objection/","summary":"AI lets you produce work you can't evaluate. Worse, it lets everyone else critique yours. What engineering leaders should actually do about it.","tags":["ai","judgment"],"title":"The Cost of an Objection Went to Zero","url":"https://leadership.garden/cost-of-objection/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eYou get the behavior you reward. Announcing the behavior you want does approximately nothing, and I say that as someone who has announced it several times.\u003c/p\u003e\n\u003cp\u003eCharlie Munger put it better in 1995: \u0026ldquo;Show me the incentive, and I will show you the outcome.\u0026rdquo; He was warning people about their advisors, and the line survives because it works anywhere people watch each other for signals about what counts. Engineering orgs are one of those places.\u003c/p\u003e\n\u003cp\u003eIt matters most when you are trying to fix something in the culture.\u003c/p\u003e\n\u003ch2 id=\"the-town-hall-does-not-work\"\u003eThe town hall does not work\u003c/h2\u003e\n\u003cp\u003eThe instinct is to address the culture head-on. Quality matters. Slow down and do it right. Own your systems. You say it at an all-hands, then again in Slack, and then you write a doc on engineering standards and pin it in the channel. (I have written that doc. Twice.)\u003c/p\u003e\n\u003cp\u003eNone of it moved anything, and not because anyone disagreed with me.\u003c/p\u003e\n\u003cp\u003eThey agreed. They also knew who got promoted last cycle.\u003c/p\u003e\n\u003cp\u003eAn engineer who stops caring about the fundamentals is usually behaving rationally. If product work is what gets seen, and seen work is what gets rated, then two weeks spent on a flaky test suite is two weeks spent invisible. Nobody sits down and decides to stop caring. They keep making the locally sensible choice over and over, and a year later you have a group of people who ship features quickly and cannot tell you how the system behaves under load.\u003c/p\u003e\n\u003cp\u003eThen somebody calls it a culture problem. Culture is where the problem shows up. Whatever is causing it sits one level down, in what the org actually rewards, and words aimed at the top layer never reach that far.\u003c/p\u003e\n\u003ch2 id=\"what-you-actually-control\"\u003eWhat you actually control\u003c/h2\u003e\n\u003cp\u003eMost writing on this ends at \u0026ldquo;align the incentives,\u0026rdquo; which in practice means redesign the ladder and the compensation plan. If you run a domain rather than a company, you usually own neither.\u003c/p\u003e\n\u003cp\u003eWhat you do own is attention. Attention is an incentive, and because it costs nothing on any budget line, leaders treat it as decoration.\u003c/p\u003e\n\u003cp\u003eSo we started spotlighting deep engineering work the same way we spotlight product wins. Same demo slots, same all-hands, same language about impact, same audience. The main stage, not a side channel that eleven people have muted.\u003c/p\u003e\n\u003cp\u003eOnce that path existed, people walked down it. That is the entire mechanism. There was never a shortage of engineers who wanted to do the harder, less visible work. There was a shortage of evidence that anyone would notice if they did.\u003c/p\u003e\n\u003ch2 id=\"the-test-for-whether-the-path-is-real\"\u003eThe test for whether the path is real\u003c/h2\u003e\n\u003cp\u003eThe fair objection, and I have heard versions of it from my own engineers, is that praise is cheap and everybody knows it. A shoutout costs me nothing. A promotion costs money and takes a slot away from somebody else.\u003c/p\u003e\n\u003cp\u003eThat objection is correct, and it gives you the test.\u003c/p\u003e\n\u003cp\u003eAsk who was last promoted mainly for deep engineering work. If you cannot name the person, the second path is a rumor, and your team figured that out long before you did. Recognition with no promotion behind it is the same town hall with better staging.\u003c/p\u003e\n\u003ch2 id=\"do-not-turn-it-into-a-metric\"\u003eDo not turn it into a metric\u003c/h2\u003e\n\u003cp\u003eThe next instinct is to measure the thing. Put tech health on the scorecard, count refactors, attach a number to reliability, and review it monthly.\u003c/p\u003e\n\u003cp\u003eThen Goodhart arrives, and you get the number without the work. Migrations get declared done at eighty percent. Coverage climbs while the new tests assert nothing in particular.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eKeep recognition a judgment call\u003c/em\u003e. Train your leaders/managers to recognize and celebrate. It is slower, it is harder to defend in a spreadsheet, and it is much more difficult to game, because a person has to look at the actual work and decide it was good.\u003c/p\u003e\n\u003ch2 id=\"read-your-own-signals\"\u003eRead your own signals\u003c/h2\u003e\n\u003cp\u003eIf you do not like what you are seeing in your team, the answer is rarely in what you have been saying.\u003c/p\u003e\n\u003cp\u003eLook at your last three promotions and your last three demo slots, and read them the way your engineers read them. That list is your culture statement. Everything else is commentary.\u003c/p\u003e\n","date_modified":"2026-09-05T14:20:00Z","date_published":"2026-09-05T14:20:00Z","id":"https://leadership.garden/you-get-what-you-reward/","summary":"Telling your team quality matters changes nothing. Here is what actually moves engineering culture, and the test for whether your fix is real.","tags":["culture","leadership"],"title":"You Get What You Reward","url":"https://leadership.garden/you-get-what-you-reward/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eOne of my principal engineers sent me a link to \u003ca href=\"https://github.com/github/spec-kit?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003espec-kit\u003c/a\u003e with the message, \u0026ldquo;Should we standardize on this?\u0026rdquo; I said I\u0026rsquo;d read it properly and get back to him. A few weeks later, \u003ca href=\"https://www.linkedin.com/pulse/specification-driven-development-sdd-build-software-defining-omar-rskqf/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ean article on Specification-Driven Development\u003c/a\u003e came through my feed, and I read the whole thing, waiting to disagree with something.\u003c/p\u003e\n\u003cp\u003eMostly I didn\u0026rsquo;t. Write down what you want before you build it. Review it with product and engineering in the same room. Keep it in version control. Turn acceptance criteria into automated tests. All fine, and all roughly what a careful team already does on a good week.\u003c/p\u003e\n\u003cp\u003eThen I looked at the diagram again. Specification at the top, four arrows down from it: implementation, testing, validation, and maintenance. The spec governs all four.\u003c/p\u003e\n\u003cp\u003eThat is where the word \u0026ldquo;driven\u0026rdquo; is doing work nobody has audited.\u003c/p\u003e\n\u003cp\u003eIf you run an engineering org, someone is going to ask you this quarter whether you\u0026rsquo;re \u0026ldquo;doing SDD.\u0026rdquo; This is what I told my principal engineer, eventually. Part of it is a practice I use every week and would defend to anyone. The rest is a positioning claim in a methodology costume, and telling them apart is worth an afternoon of your attention.\u003c/p\u003e\n\u003ch2 id=\"the-defenders-describe-something-the-diagrams-do-not-show\"\u003eThe defenders describe something the diagrams do not show\u003c/h2\u003e\n\u003cp\u003eStart with the strongest version, because the weak version is easy, and I don\u0026rsquo;t want to spend a post beating up a LinkedIn article.\u003c/p\u003e\n\u003cp\u003eMarc Brooker works on Kiro at AWS and has written \u003ca href=\"https://brooker.co.za/blog/2026/04/09/waterfall-vs-spec.html?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethe best defence of SDD I\u0026rsquo;ve read\u003c/a\u003e. His line is that specs aren\u0026rsquo;t about pulling designs up-front; they\u0026rsquo;re about \u0026ldquo;pulling designs up\u0026rdquo;. You raise the level of abstraction from code to words, keep the artifact versioned and alive, and iterate on the spec rather than on the implementation. He\u0026rsquo;s right, and the sentence I\u0026rsquo;d underline in his piece is that you shouldn\u0026rsquo;t develop the whole specification upfront. Hold onto that one. It\u0026rsquo;s a concession the tools he\u0026rsquo;s defending have not made.\u003c/p\u003e\n\u003cp\u003eBirgitta Böckeler at Thoughtworks did \u003ca href=\"https://martinfowler.com/articles/exploring-gen-ai/sdd-3-tools.html?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethe most careful hands-on evaluation I know of\u003c/a\u003e, and the useful thing she produced is a ladder. Spec-first: write it, use it, throw it away. Spec-anchored: it survives the change and evolves with the feature. Spec-as-source: a human never touches the code at all. I\u0026rsquo;d take the first rung happily, the second with a named maintainer, and the third not at all, for reasons I\u0026rsquo;ll get to. Note that almost everything marketed as SDD is sitting on rung one while quoting the brochure for rung three.\u003c/p\u003e\n\u003cp\u003eYuval Yeret adds \u003ca href=\"https://yuvalyeret.com/blog/spec-driven-development-isnt-waterfall-unless-youre-using-it-that-way/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethe sharpest diagnosis\u003c/a\u003e. The spec is a target for an adaptive loop, and the failure mode isn\u0026rsquo;t sequencing; it\u0026rsquo;s batch size.\u003c/p\u003e\n\u003cp\u003eEvery one of those defenses describes a loop.\u003c/p\u003e\n\u003cp\u003eNow go look at any SDD marketing diagram. Specify, plan, tasks, implement. One direction, and no arrow comes back.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/spec-driven-delusion/sdd-loop_hu_f9a965260600400f.png\"\n    srcset=\"/spec-driven-delusion/sdd-loop_hu_b123819ab75f6845.webp 640w, /spec-driven-delusion/sdd-loop_hu_12be0ef5f2c093c5.webp 960w, /spec-driven-delusion/sdd-loop_hu_fe91d55944f43939.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"904\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003eThe people who understand this best describe a cycle, and the thing being sold draws a pipeline. That gap is the subject of this post, and better diagrams would not close it, because the pipeline is not a bad drawing of the practice. It\u0026rsquo;s an accurate drawing of the claim.\u003c/p\u003e\n\u003cp\u003eBöckeler has the right word for what\u0026rsquo;s happening to the term: it is already \u003ca href=\"https://martinfowler.com/bliki/SemanticDiffusion.html?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003esemantically diffused\u003c/a\u003e, Fowler\u0026rsquo;s name for a phrase that spreads faster than its meaning. Thoughtworks\u0026rsquo; own \u003ca href=\"https://www.thoughtworks.com/en-us/radar?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eTechnology Radar\u003c/a\u003e now cites spec-driven development as a live example and says the hard part is telling a real methodology apart from ordinary use of a coding assistant. When the people who coined the vocabulary can\u0026rsquo;t draw that line, you should be slow to reorganize around it.\u003c/p\u003e\n\u003ch2 id=\"what-driven-is-smuggling\"\u003eWhat \u0026ldquo;driven\u0026rdquo; is smuggling\u003c/h2\u003e\n\u003cp\u003eEvery \u0026ldquo;X-driven development\u0026rdquo; name makes the same kind of assertion. When two artifacts disagree, X wins.\u003c/p\u003e\n\u003cp\u003eTest-driven development gets away with it because the test lives inside the loop. It\u0026rsquo;s written minutes before the code; it fails first, and when it turns out to be wrong, you delete it without ceremony. Nobody escalates a deleted test. It never accumulates enough authority to be worth defending.\u003c/p\u003e\n\u003cp\u003eA specification does. It has been reviewed by product and engineering; it sits in the repo, and somebody\u0026rsquo;s name is on it.\u003c/p\u003e\n\u003cp\u003eSo here\u0026rsquo;s the question I\u0026rsquo;d put to any team proposing this before the tooling conversation starts. When the running system and the spec disagree, which one is wrong?\u003c/p\u003e\n\u003cp\u003eAnswer \u0026ldquo;the code, we regenerate it\u0026rdquo; and you have a governing document, along with every failure mode of the last fifty years of upstream-artifact processes. Answer \u0026ldquo;usually the spec, we go update it\u0026rdquo; and the spec isn\u0026rsquo;t driving anything. It\u0026rsquo;s documentation. Useful documentation is a fine thing to want, and most orgs are bad at it. But then there\u0026rsquo;s no methodology here, just a practice with an overclaiming name.\u003c/p\u003e\n\u003cp\u003eThe best-practice list in that article gives the game away, and I don\u0026rsquo;t think its author noticed. Write specifications before implementation, says one bullet. Update specifications whenever requirements change, says another, two lines later. Both are reasonable advice. Together they concede that requirements will change after the spec is written, which is the fact the opening paragraph treats as a pathology to be engineered away.\u003c/p\u003e\n\u003cp\u003eIf the spec has to chase reality, reality is the source of truth.\u003c/p\u003e\n\u003ch2 id=\"the-spec-doesnt-govern-the-agent-either\"\u003eThe spec doesn\u0026rsquo;t govern the agent either\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a second problem with \u0026ldquo;source of truth,\u0026rdquo; and this one isn\u0026rsquo;t philosophical.\u003c/p\u003e\n\u003cp\u003eA compiler is bound by its input. An LLM is not.\u003c/p\u003e\n\u003cp\u003eBöckeler ran spec-kit on a feature that built on existing code, and the tool did a research step that documented the classes already in the codebase. The agent then read those descriptions as new requirements and generated all of it again as duplicates. She saw the opposite failure too, where the agent followed one article of the constitution so eagerly that it went well past what anyone wanted. Bigger context windows have not fixed this, because putting something in the context is not the same as the model acting on it.\u003c/p\u003e\n\u003cp\u003eSo the spec\u0026rsquo;s authority over the implementation is \u003cstrong\u003ea probability, not a guarantee\u003c/strong\u003e, and it decays as the document grows.\u003c/p\u003e\n\u003cp\u003eThoughtworks put spec-driven development in the Assess ring of the \u003ca href=\"https://www.thoughtworks.com/en-us/radar/techniques/spec-driven-development?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eTechnology Radar\u003c/a\u003e in November 2025, which is roughly \u0026ldquo;interesting, go look at it.\u0026rdquo; What they wrote in the same entry is the part worth your time. The workflows are elaborate, the tools behave very differently depending on the size of the task, some of them produce spec files that are challenging to review, and when they generate PRDs or user stories, it isn\u0026rsquo;t always clear who those are for. Then they land on the actual worry: we may be relearning the \u003ca href=\"https://en.wikipedia.org/wiki/Bitter_lesson?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ebitter lesson\u003c/a\u003e, that \u0026ldquo;handcrafting detailed rules for AI ultimately doesn\u0026rsquo;t scale.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s the sentence I\u0026rsquo;d put in front of anyone proposing an org-wide rollout. Not because it settles the question, but because the pattern it names has beaten every previous attempt to hand-author enough structure to make a model behave.\u003c/p\u003e\n\u003cp\u003eThat matters more than it sounds, because it removes the one thing that would justify the ceremony. If the spec really did compile into the system, reviewing markdown instead of code would be a straight trade. It doesn\u0026rsquo;t, so you review the spec and then review the code anyway to find out whether the spec was honored.\u003c/p\u003e\n\u003cp\u003eBöckeler reaches for the German word: \u003cem\u003e\u003cstrong\u003eVerschlimmbesserung\u003c/strong\u003e\u003c/em\u003e. Making something worse in the attempt to make it better.\u003c/p\u003e\n\u003ch2 id=\"verification-is-not-validation-and-only-one-of-them-has-an-owner\"\u003eVerification is not validation, and only one of them has an owner\u003c/h2\u003e\n\u003cp\u003eThe strongest practical claim for SDD is that acceptance criteria hand you tests almost for free. True, and worth having.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s also verification. Does this software obey the rules we wrote down?\u003c/p\u003e\n\u003cp\u003eValidation is the other question. Were those the right rules? You can have complete automated coverage of a perfectly specified system that nobody wants, and every test in that suite will pass while the product fails.\u003c/p\u003e\n\u003cp\u003eThe objection I get here is that the criteria came from a stakeholder, so checking them is validation by proxy. It isn\u0026rsquo;t. A stakeholder signing off on a rule in February tells you what they believed in February about a system they had not used.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThat\u0026rsquo;s a hypothesis with a signature on it, and treating a signature as evidence is how a good process turns into a bad one.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eMost of what\u0026rsquo;s written about SDD uses those two words interchangeably, including the article I started with, which puts \u0026ldquo;validation\u0026rdquo; in its lifecycle diagram and then describes nothing but verification for three thousand words. Call that pedantry if you like. It\u0026rsquo;s the difference between \u003cstrong\u003ebuilding the thing right and building the right thing\u003c/strong\u003e, and we are blurring the one distinction the discipline most needs to keep sharp.\u003c/p\u003e\n\u003cp\u003eThe reason it matters to you and not just to essayists is that only one of those questions has an owner.\u003c/p\u003e\n\u003cp\u003eVerification does. It has tests, a pipeline, a definition of done, a QA function or a testing guild, and someone whose approval blocks the merge. Validation usually has nobody. It\u0026rsquo;s spread across a PM\u0026rsquo;s judgment, a designer\u0026rsquo;s instinct, and whether anyone remembered to look at the funnel three weeks after launch.\u003c/p\u003e\n\u003cp\u003eThe most expensive quarter I\u0026rsquo;ve been part of ended with a feature that passed everything. Every acceptance criterion met, every test green, a clean launch. Adoption in month two told us what nobody had asked in month zero, and we spent the following quarter unwinding it.\u003c/p\u003e\n\u003cp\u003eAdopt a vocabulary that calls verification \u0026ldquo;validation\u0026rdquo; and you get an organization that believes the second question is handled because the first one is green.\u003c/p\u003e\n\u003cp\u003eTake the example that article uses, chosen to demonstrate the method\u0026rsquo;s strength. \u0026ldquo;Users can upload files\u0026rdquo; becomes a specification: 20 MB limit, PDF and PNG and JPG, virus scan before storage, reject encrypted files, store metadata, return a document ID, 30-second processing timeout. The article says this version leaves very little room for interpretation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eIt leaves enormous room\u003c/strong\u003e. Why 20 MB? Does the customer with a 25 MB PDF get an error, or does a support engineer quietly raise their limit? When the virus scanner is unavailable, do we fail closed, fail open, or queue and retry? What happens at second 31? And what do we do in six weeks when sales finds out that half the pipeline wants to upload DOCX?\u003c/p\u003e\n\u003cp\u003eSomeone defending the example will say a better analyst catches those with more effort. I don\u0026rsquo;t think so. They\u0026rsquo;re questions generated by contact with reality, and contemplation doesn\u0026rsquo;t produce them in advance at any level of diligence.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003ePrecision about the wrong answers is not an improvement over vagueness about them. You don\u0026rsquo;t escape that by specifying harder. You escape it by making the discovery cheap.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"the-economics-moved-and-the-methodology-went-the-wrong-way\"\u003eThe economics moved, and the methodology went the wrong way\u003c/h2\u003e\n\u003cp\u003eEvery development process is an answer to one question. What does it cost to be wrong?\u003c/p\u003e\n\u003cp\u003eBig Design Upfront™ made sense when it was invented, and it annoys me how often that gets treated as a joke. Compiler time was rationed. A change meant a rebuild, a test cycle, and a release train you caught or missed by weeks. Under those numbers, paying six people to argue in a room for a month was cheap insurance against paying two hundred to build the wrong thing. \u003cstrong\u003eCorrect arithmetic, wrong century\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eAI broke that arithmetic, and not slightly.\u003c/p\u003e\n\u003cp\u003eAn agent can produce a working version of a feature in an afternoon. So the cheapest way to find out whether a requirement is right is no longer to argue about it in a document with five reviewers. It\u0026rsquo;s to build it, put it in front of somebody, and watch what they do with it. Prototypes are disposable now. \u003cstrong\u003eBeing wrong is truly cheap now, as long as you find out quickly.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eLook at what SDD does with that. It takes the first change in our field\u0026rsquo;s history that makes feedback loops dramatically cheaper and spends the windfall on making the phase before any feedback exists longer and more ceremonial.\u003c/p\u003e\n\u003cp\u003eThe observation underneath it is correct. Agents produce far better code from precise context than from vague prompts, and I run my own side projects this way and wouldn\u0026rsquo;t go back. The right conclusion is that small specs are an excellent artifact inside a fast loop. Hypothesis, small spec, implementation, contact with reality, revised hypothesis. Not that the spec belongs upstream of the loop governing everything downstream, which is the one position fifty years of evidence warns against.\u003c/p\u003e\n\u003cp\u003eBrooker and Yeret would both broadly agree with that paragraph, which is exactly my point.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe defensible version of this is iterative development with good context hygiene, and that is not what the word \u0026ldquo;driven\u0026rdquo; is claiming.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"what-it-will-cost-your-org\"\u003eWhat it will cost your org\u003c/h2\u003e\n\u003cp\u003eStart with review capacity, which is already your constraint whether or not you\u0026rsquo;ve named it as one. Faros AI spent two years watching telemetry from 22,000 developers across more than 4,000 teams, and their \u003ca href=\"https://www.faros.ai/research/ai-acceleration-whiplash?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e2026 report\u003c/a\u003e is the least comfortable thing I\u0026rsquo;ve read this year. Under heavy AI adoption, median review time rose fivefold. Bugs per developer went up 54%. The incidents-to-PR ratio more than tripled. And the number that should stop you: 31% more pull requests merged with no human review at all, because reviewers could not keep pace and something had to give.\u003c/p\u003e\n\u003cp\u003eBöckeler\u0026rsquo;s account of spec-kit is that it produced a lot of markdown, repetitive with each other and with code that already existed. She\u0026rsquo;d rather review code than review those files. When she pointed Kiro at one small bug, it generated four user stories and sixteen acceptance criteria.\u003c/p\u003e\n\u003cp\u003eIf human attention on the way out is your bottleneck, adding a review stage on the way in doesn\u0026rsquo;t help. It piles more work in front of the constraint. I\u0026rsquo;ve watched a design-doc review stage do precisely this. Genuinely good documents, thoughtful comments, and a median time from ticket to first deploy that got worse every quarter for a year, because nobody asked what the new stage was supposed to be subtracting.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eBrownfield makes it worse, and brownfield is where you live.\u003c/strong\u003e Almost every SDD tutorial builds an application from scratch, because that makes a clean tutorial, and Böckeler found the tools considerably more work to introduce into a codebase and product ecosystem that already exists.\u003c/p\u003e\n\u003cp\u003eThen there\u0026rsquo;s the fact that spec review has no failing state. A code review can say, \u0026ldquo;This doesn\u0026rsquo;t work.\u0026rdquo; You run it, it breaks, the argument is over. A spec review has taste, judgment, and whether the reviewer has the standing to push back on a document a PM wrote and a director already praised. In my experience, people approve specs. There\u0026rsquo;s no principled ground to reject one; rejecting it means the feature slips, and everyone in the room can do that math.\u003c/p\u003e\n\u003cp\u003eThe last cost is ownership. If PMs write the acceptance criteria that agents build against, you\u0026rsquo;ve relocated a lot of technical judgment to people who don\u0026rsquo;t carry the pager. Yeret thinks \u003ca href=\"https://yuvalyeret.com/blog/is-spec-driven-development-a-step-forward-or-back-for-product-development/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eexpecting product managers to write the specs\u003c/a\u003e makes very little sense, and I agree with him. That doesn\u0026rsquo;t mean PMs stay out of it.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eIt means the person accountable for the system being correct has to be the person whose judgment ends up in the artifact the agent obeys.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"what-id-actually-do\"\u003eWhat I\u0026rsquo;d actually do\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;m not against writing things down. I write a spec before I let an agent touch anything nontrivial, and the output is better for it. The disagreement is about where the artifact sits, and that resolves into a handful of concrete choices.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eCap the spec by the thing it describes\u003c/strong\u003e: one change, not one feature. If the spec takes longer to write and review than the change takes to build and try, you\u0026rsquo;ve picked the wrong artifact for the work in front of you. That\u0026rsquo;s a rule you can apply on a Tuesday without running a workshop about it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eMeasure\u003c/strong\u003e \u003cstrong\u003etime to first contradiction\u003c/strong\u003e. Not cycle time, not spec coverage. How long from starting a piece of work to learning something that changes what you thought you were building. If that number lands in weeks, your spec is governing, whatever the diagram says, and if it lands in hours, then the spec is inside the loop, and you\u0026rsquo;re fine. It\u0026rsquo;s the only metric in this post I\u0026rsquo;d put on a dashboard.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eGive validation a name.\u003c/strong\u003e One person per initiative, accountable for the question \u0026ldquo;Was this worth building,\u0026rdquo; with the standing to answer no and kill it. A named individual, not a team or a pod or a triad, because shared accountability for that question has never once produced someone willing to say the word no in a room with a director in it. If you can\u0026rsquo;t name them for your biggest current project, that\u0026rsquo;s the finding, and you can stop reading here.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eKeep the spec after the change only if someone maintains it\u003c/strong\u003e. Böckeler\u0026rsquo;s spec-anchored level is genuinely valuable, and it\u0026rsquo;s also a commitment. An abandoned spec is worse than no spec because it misleads the next engineer with confidence and a git history to back it up. If nobody owns it, delete it when the change ships and write a decision record instead.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAnd stop saying \u0026ldquo;driven\u0026rdquo; internally\u003c/strong\u003e. Say, \u0026ldquo;We write a spec first.\u0026rdquo; Four words longer, accurate, and it doesn\u0026rsquo;t quietly assert that a document outranks a production system.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"the-question-nobody-asked\"\u003eThe question nobody asked\u003c/h2\u003e\n\u003cp\u003eThat article never asks the only question that matters in three thousand words. How much should we specify before building, and when do we stop specifying and start learning?\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s no general answer, which is the problem with selling this as a methodology. Payroll rules, tax logic, a protocol implementation: specify heavily, because \u003cem\u003ethe what\u003c/em\u003e is genuinely knowable in advance and feedback won\u0026rsquo;t catch the mistakes in time. A new onboarding flow: specify almost nothing, ship something ugly on Thursday, watch what people do. Most of your work sits between those, and judging where is the job. It isn\u0026rsquo;t delegable to a process, which is precisely why processes sell so well.\u003c/p\u003e\n\u003cp\u003eRoyce drew the single-pass diagram in \u003ca href=\"https://www.cs.huji.ac.il/w~feit/sem/se09/Waterfall.pdf?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e1970\u003c/a\u003e and warned in the same paper that it invites failure because design flaws only surface through implementation. We took the diagram and left the warning. He had a better platform than I do, and it didn\u0026rsquo;t stick for him either, so I\u0026rsquo;m not expecting much.\u003c/p\u003e\n\u003cp\u003eWrite the spec. Then keep it small enough that reality can overrule it.\u003c/p\u003e\n","date_modified":"2026-08-29T12:45:00Z","date_published":"2026-08-29T12:45:00Z","id":"https://leadership.garden/spec-driven-delusion/","summary":"Spec-driven development's defenders describe a loop. Its diagrams draw a pipeline. An engineering leader on where the spec actually belongs.","tags":["ai","leadership"],"title":"Specs Don't Drive Anything","url":"https://leadership.garden/spec-driven-delusion/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eI watched the same feature get built twice this year.\u003c/p\u003e\n\u003cp\u003eThe first build took a weekend. One engineer wanted to export the data behind a chart as a CSV, described it to an agent, got a working implementation back, and had it running on her laptop by Monday. She showed it around. Everyone agreed it was slightly absurd how fast that had been.\u003c/p\u003e\n\u003cp\u003eThe second build was the same feature inside the actual product. It took most of a quarter.\u003c/p\u003e\n\u003cp\u003eNothing in the second version was harder to write. The code was, if anything, duller. The model was equally good on both occasions, which means the difference had nothing to do with the model.\u003c/p\u003e\n\u003cp\u003eIf you lead an engineering organization, somebody senior is going to ask you why the second number is not collapsing toward the first. You need a better answer than \u0026ldquo;enterprise is complicated,\u0026rdquo; because that answer sounds like an excuse and half the time it is one.\u003c/p\u003e\n\u003ch2 id=\"the-claim-is-smaller-than-the-headline\"\u003eThe claim is smaller than the headline\u003c/h2\u003e\n\u003cp\u003eEvery few weeks someone announces that coding is solved. If they mean that a clearly specified problem can be turned into working code with very little human effort, they are close to right and getting righter. I have stopped arguing with that part. Watching an agent produce a competent implementation of something I described in two sentences still lands somewhere between useful and unnerving.\u003c/p\u003e\n\u003cp\u003eBut look at what got measured. A specified problem went in, and code came out. The specification was the input.\u003c/p\u003e\n\u003cp\u003eSomebody produced that specification. In the weekend version, it was the same person who wrote the prompt, in her head, in about four minutes, answerable to nobody. In the product version, it took eleven weeks and involved most of a department.\u003c/p\u003e\n\u003ch2 id=\"what-actually-happened-to-the-csv-button\"\u003eWhat actually happened to the CSV button\u003c/h2\u003e\n\u003cp\u003eThe second build did not spend eleven weeks writing an exporter. It spent eleven weeks getting to the point where writing the exporter was a decision anyone could make.\u003c/p\u003e\n\u003cp\u003eAn export already existed in an internal admin tool. It was built four years ago by a team that no longer exists in that shape, and it works, and nobody is sure what would break if it were reused.\u003c/p\u003e\n\u003cp\u003eLegal wanted to know whether this data was allowed to leave the product in a downloadable form at all. The answer lived in customer contracts, and the contracts did not agree with each other.\u003c/p\u003e\n\u003cp\u003eThe service holding the data was not the service rendering the chart. The boundary between them was owned by a third team with a roadmap of their own and a strong opinion about what belonged on their side of it.\u003c/p\u003e\n\u003cp\u003eThen someone remembered that this had been shipped in 2023 and rolled back within a month. Nobody could produce the reason. Two people had two different stories, and both were plausible.\u003c/p\u003e\n\u003cp\u003eAn agent could have written all four candidate implementations in an afternoon. What it could not do was tell anyone which one to write, and that was the entire eleven weeks.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/same-feature-twice/four-layers-of-software-engineering-cost-2_hu_1c58b1131ecb249f.png\"\n    srcset=\"/same-feature-twice/four-layers-of-software-engineering-cost-2_hu_7aaeb61d0b69f898.webp 640w, /same-feature-twice/four-layers-of-software-engineering-cost-2_hu_9bb5b98b616274a8.webp 960w, /same-feature-twice/four-layers-of-software-engineering-cost-2_hu_c1863854006974b2.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"Diagram of software development layers where Implementation cost has collapsed while higher-level design and business costs\"\n    width=\"1280\"\n    height=\"888\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"we-named-the-discipline-after-its-most-expensive-part\"\u003eWe named the discipline after its most expensive part\u003c/h2\u003e\n\u003cp\u003eFor most of the history of this profession, producing the code was the slow step. Other steps were hard, but that one reliably dominated a schedule, so the discipline got named after it. We call ourselves software engineers and we mean, mostly, people who write software.\u003c/p\u003e\n\u003cp\u003eThat naming was accurate for a long time and it is now doing damage, because when the expensive step gets cheap, the thing you named after it does not shrink. Everything else it was hiding becomes visible instead.\u003c/p\u003e\n\u003cp\u003eI keep seeing leaders read a productivity number, see that implementation got three times faster, and expect delivery to follow. Delivery moves a little. Then it stops. The tools did not fail. Implementation was never the whole cost, and the arrival of a cheap implementation is what makes that impossible to keep quiet about.\u003c/p\u003e\n\u003ch2 id=\"four-layers-and-one-of-them-got-cheap\"\u003eFour layers, and one of them got cheap\u003c/h2\u003e\n\u003cp\u003eAny change worth shipping has to survive four questions, and they do not all live in the same place.\u003c/p\u003e\n\u003cp\u003eAt the bottom, how do we express this in code? Above it, how should the system produce that behavior, given what already exists? Above that, how should a person experience it? And underneath all of it, the one that decides whether the other three were worth answering: which problem are we solving, and for whom?\u003c/p\u003e\n\u003cp\u003eModels are becoming excellent at the bottom question. They are useful at the second one, if you tell them enough, but they usually can\u0026rsquo;t make up for lacking judgment. They have opinions about the third that are worth roughly what an opinion from someone who has never met your users is worth.\u003c/p\u003e\n\u003cp\u003eThe fourth question has not moved at all.\u003c/p\u003e\n\u003cp\u003eThat is the shape of the thing. The layer that got automated is the layer that was always the most legible because it was the only one written down.\u003c/p\u003e\n\u003ch2 id=\"context-is-everything-that-the-repository-does-not-contain\"\u003eContext is everything that the repository does not contain\u003c/h2\u003e\n\u003cp\u003eWhat separated the weekend build from the product build was not talent, and it was not tooling.\u003c/p\u003e\n\u003cp\u003eAn organization knows things. Which abstractions are load-bearing and which were abandoned in place? The domain language, including the two words that mean the same thing for a historical reason that annoys everyone. Which parts of the system are permitted to fail? Which single customer is the reason for that odd flag in the config? Whether a given architectural decision was a real choice or just something that happened while nobody was watching.\u003c/p\u003e\n\u003cp\u003eAlmost none of that is in the repository. Some of it is in a wiki that was last accurate two directors and reorgs ago. Most of it is distributed across people, unevenly, and reassembled in meetings.\u003c/p\u003e\n\u003cp\u003eA startup grows this as it goes, which is why small companies feel so fast and why that feeling does not survive their first hundred engineers. An enterprise inherits decades of it from people who have left.\u003c/p\u003e\n\u003cp\u003eSo asking a model to build something new is a fundamentally different request from asking it to change something old. The greenfield task has one specification. The brownfield task has one specification plus every decision the system has ever absorbed, and the second list is not written anywhere you can point at.\u003c/p\u003e\n\u003cp\u003eThat is not a complaint about models. It is a description of what we have been asking senior engineers to hold in their heads, unpaid and unacknowledged, for their entire careers.\u003c/p\u003e\n\u003ch2 id=\"what-i-would-actually-do-with-this\"\u003eWhat I would actually do with this\u003c/h2\u003e\n\u003cp\u003eNone of what follows is about tool selection.\u003c/p\u003e\n\u003cp\u003eStop measuring adoption by output. Lines merged and pull requests opened tell you the bottom layer sped up, which you already knew. The number worth watching is how long a change waits between someone asking a question and someone being able to answer it. That gap is where your quarters are going. Measuring that gap is miserable, which is why almost nobody does it and why everyone reports merge counts instead.\u003c/p\u003e\n\u003cp\u003eMove your strongest people up a layer on purpose. This happens by accident anyway, and it happens badly. Your best engineer starts spending her week answering the questions the agents cannot answer, and because that work has no artifact, her next performance review is quieter than it should be. Make the move explicit. Say out loud that the job is now framing problems and adjudicating between plausible designs, and then evaluate her on that rather than on throughput; she is no longer producing.\u003c/p\u003e\n\u003cp\u003eWrite down decisions instead of explanations. Documentation that describes what the code does has never had a shorter shelf life than it does now, since anyone can ask an agent that question and get a better answer than the wiki would have given. Documentation that records why a boundary is where it is, and what was rejected, is the only kind that still pays. Almost nobody writes it, because writing it means admitting a decision was made by a person who could have chosen otherwise.\u003c/p\u003e\n\u003ch2 id=\"so-write-the-context-down\"\u003e\u0026ldquo;So write the context down\u0026rdquo;\u003c/h2\u003e\n\u003cp\u003eThe obvious objection, and I have had it put to me with some force by people who are better at this than I am, is that all of the above is a documentation problem wearing a philosophical hat. Put the conventions in a file the agents read. Record the boundaries. Solved.\u003c/p\u003e\n\u003cp\u003eTry it and watch what surfaces.\u003c/p\u003e\n\u003cp\u003eYou sit down to write the rule about that service boundary, and you find there is no rule. There was a decision made in a hurry in 2022 by someone who has since left, which everyone has been treating as policy because it has survived. You go to record why the export was rolled back, and you get two accounts that cannot both be true. You try to write down which team owns the notification path, and you discover that the honest answer is a sentence with the word \u0026ldquo;basically\u0026rdquo; in it.\u003c/p\u003e\n\u003cp\u003eWriting it down is worth doing. An audit finds things, and that is the whole value of running one. What it is not is a weekend of technical writing, and anyone selling it that way has never tried to write the difficult page. The reason your context is undocumented is rarely that nobody got around to it. More often, documenting it requires somebody to decide something that has never actually been decided.\u003c/p\u003e\n\u003ch2 id=\"every-layer-gets-its-turn\"\u003eEvery layer gets its turn\u003c/h2\u003e\n\u003cp\u003eThere is a comfortable version of all this where the abstraction simply rises, the way it did when compilers took over machine code, and everyone moves up and gets on with their lives.\u003c/p\u003e\n\u003cp\u003eI would be careful with that story. Every previous step made the layer below genuinely invisible. Nobody reads compiler output. Nobody audits the assembly. This step has not done that, and might not for a while. The code is still yours, you still own it at three in the morning, and you still have to understand it well enough to know when the confident thing you were handed is wrong.\u003c/p\u003e\n\u003cp\u003eWhich means the work above implementation did not get lighter. It got more crowded, and it got crowded faster than most organizations have adjusted their structure to handle.\u003c/p\u003e\n\u003ch2 id=\"code-is-the-medium\"\u003eCode is the medium\u003c/h2\u003e\n\u003cp\u003eNobody has ever been paid to produce source code. They have been paid for what the code does once it is running, in front of people, inside a business that needed something to change.\u003c/p\u003e\n\u003cp\u003eWe forgot that for a couple of decades because producing the code was hard enough to feel like the point. Code was never the point. Code was the expensive part, and expense makes a convincing impostor.\u003c/p\u003e\n\u003cp\u003eSo is coding solved? For turning a clear specification into working software, close enough that arguing about it is a waste of a good afternoon. The interesting shortage was never there. It was in the eleven weeks it took to earn a specification worth handing to anything, and no one has automated that yet.\u003c/p\u003e\n\u003cp\u003eGo and look at where your last quarter actually went. If the answer is not \u0026ldquo;writing the code,\u0026rdquo; and I do not think it will be, then you already know which part of the job to get better at.\u003c/p\u003e\n","date_modified":"2026-08-22T15:41:00Z","date_published":"2026-08-22T15:41:00Z","id":"https://leadership.garden/same-feature-twice/","summary":"The same feature took a weekend on a laptop and a quarter in the product. The model was identical both times. Everything around it was not.","tags":["product","ai","leadership"],"title":"The Same Feature, Twice","url":"https://leadership.garden/same-feature-twice/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe product vision landed with three strategic streams in it, each on a multi-year horizon. I had six engineers, two open reqs, and one lead I would trust with a team on a bad week. The team design workshop was already on the calendar for the following week.\u003c/p\u003e\n\u003cp\u003eCovering three streams with eight people was the obvious agenda. I threw it out. Two hours on that question produces an org chart nobody can staff, and everybody leaves the room feeling productive.\u003c/p\u003e\n\u003cp\u003eWhat follows is the sanitized version of what I ran instead. Four scenarios, one number that decided all of them, and a shape you can reuse next week if somebody has just handed you a strategy with more bets in it than you have people.\u003c/p\u003e\n\u003ch2 id=\"the-published-advice-answers-a-different-question\"\u003eThe published advice answers a different question\u003c/h2\u003e\n\u003cp\u003eAlmost everything written about splitting teams answers one question. Is this team too big?\u003c/p\u003e\n\u003cp\u003eChase Seibert states the default position most cleanly, in a post whose title is the whole argument: \u003ca href=\"https://chase-seibert.github.io/blog/2017/12/19/dont-split-the-team.html?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003edon\u0026rsquo;t split the team until you have to\u003c/a\u003e. If communication is straining, a split adds cross-team meetings rather than removing them. If the team is thrashing between products, cut the number of products or funnel the backlog through one owner. If it is simply too large, move an engineer somewhere else. He is right, and I have used his argument on myself twice to talk myself out of a split I would have regretted.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://lethain.com/sizing-engineering-teams/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eWill Larson\u003c/a\u003e supplies the numbers everyone quotes. Six to eight in steady state. Grow a team to eight or ten, then bud it into two teams of four or five. Never create empty teams. His sharpest line is the one people skip past: teams under four are a leaky enough abstraction that they behave like individuals, and he says he has regretted sponsoring one every time.\u003c/p\u003e\n\u003cp\u003eBoth of them are describing a split that happens backwards. Something hurts, and you relieve it.\u003c/p\u003e\n\u003cp\u003eNothing hurt yet in my case. A strategy had arrived with three multi-year bets in it, and the workshop existed to decide which of them I could resource. Size heuristics have nothing to say about that, because size was not the symptom.\u003c/p\u003e\n\u003cp\u003eLarson does have an answer for my situation, and it is the strongest objection to everything below. In \u003ca href=\"https://lethain.com/how-to-evolve-eng-org/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eHow to evolve an engineering organization\u003c/a\u003e he takes my exact case: you need to focus on more projects than you have properly sized teams. He notes that this pulls people toward creating small teams. His answer is to add workstreams to a proper team instead. Two streams, one team of eight, one manager.\u003c/p\u003e\n\u003cp\u003eThat is correct more often than anyone in my workshop wanted it to be, and it is why Scenario 0 below gets a real seat rather than a courtesy mention. Where it stops short is accountability. A workstream has an owner in the planning sense and nobody in the \u0026ldquo;this is your mandate for the next three years\u0026rdquo; sense. When the quarter gets tight, a workstream loses to the team\u0026rsquo;s headline roadmap every time, because it sits inside that roadmap and losing to it is a Tuesday. A multi-year bet parked as somebody\u0026rsquo;s second workstream is not being run. Deferring it quietly is worse than deferring it out loud, because nobody ever has to say the sentence.\u003c/p\u003e\n\u003ch2 id=\"the-constraint-is-leads\"\u003eThe constraint is leads\u003c/h2\u003e\n\u003cp\u003eMy arithmetic fit on one slide. Eight people. A stream needs roughly four engineers to survive on-call, vacation, illness, the person who eventually resigns, and the basic requirement that more than one human understands the code. Eight buys two solid streams, or one solid and one thin. It does not buy three. Three real teams is a twelve to fourteen person destination, twelve to twenty-four months out.\u003c/p\u003e\n\u003cp\u003eThat was uncomfortable, and it was not the interesting number. The interesting number was one, which was how many proven leads I had (product and engineering).\u003c/p\u003e\n\u003cp\u003eEvery new team is a lead decision before it is a headcount decision. You can hire an engineer in a quarter. You cannot hire a lead who already knows the domain, the codebase, and which of your engineers goes quiet when they are overloaded. Growing one internally takes two or three quarters of deliberate work.\u003c/p\u003e\n\u003cp\u003eSo the earliest honest split date is set by lead readiness. Everything after that is scheduling.\u003c/p\u003e\n\u003cp\u003eOnce I said that out loud, the workshop question changed. Instead of covering three streams, the room had to answer which two start now, who leads the second team, and what gets us to three. Same people, same two hours, and a question they could actually finish.\u003c/p\u003e\n\u003ch2 id=\"what-lead-ready-actually-means\"\u003eWhat lead-ready actually means\u003c/h2\u003e\n\u003cp\u003eI have promoted people into first-team roles on the strength of their technical judgement and watched it go badly. Technical judgement is table stakes. It predicts almost nothing about the first six months.\u003c/p\u003e\n\u003cp\u003eWhat I watch for now is narrower.\u003c/p\u003e\n\u003cp\u003eCan they hold a plan they did not write? A lead who can only execute their own design will quietly rewrite the roadmap into something they find more interesting, and you will not notice for a quarter.\u003c/p\u003e\n\u003cp\u003eDo they deliver bad news early? Someone who tells me in week two that the estimate is wrong is ready. Someone who tells me in week nine with a recovery plan attached is not, and the recovery plan is the tell. It means they spent seven weeks managing my perception instead of the problem.\u003c/p\u003e\n\u003cp\u003eConflict is the one I get wrong most often. When two of their engineers disagree in front of everybody, watch for the lead who defers to seniority, or to whoever pushed hardest, and calls that consensus.\u003c/p\u003e\n\u003cp\u003eNone of this shows up in a normal quarter, which is the awkward part of the whole exercise. The evidence you need arrives during the weeks you would rather nobody was having. So I stop waiting for those weeks and manufacture a smaller version. Hand the candidate a workstream with a real deadline and a genuine dependency on another team. Let them run planning, and stay out of the room. Let them own the escalation when the dependency slips. It will.\u003c/p\u003e\n\u003cp\u003eTwo quarters of that tells me more than two years of strong code review.\u003c/p\u003e\n\u003cp\u003eYou can also hire the lead, and sometimes you should. Just cost it honestly. An external lead needs two quarters to build the trust an internal candidate already has, and you are asking them to spend that ramp on a brand new team carrying a multi-year mandate. That is two unknowns multiplied together, and the multiplication is the part that hurts.\u003c/p\u003e\n\u003ch2 id=\"the-rules-i-do-not-negotiate\"\u003eThe rules I do not negotiate\u003c/h2\u003e\n\u003cp\u003eBefore any scenarios, the constraints I bring into every one of these rooms:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eOne team, one area. A team can carry two workstreams if each is staffed to survive on its own. Never three.\u003c/li\u003e\n\u003cli\u003eOnly form a team for work that will still exist in a year. Anything shorter is a project, and projects do not need an org chart.\u003c/li\u003e\n\u003cli\u003eEvery team has a named lead on day one. Acting leads by accident are how you burn a good engineer while congratulating yourself on their growth.\u003c/li\u003e\n\u003cli\u003eEvery new team gets at least one established engineer, ideally two. A team of new hires and good intentions ships nothing for six months.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThose four did most of the filtering before I drew a single box.\u003c/p\u003e\n\u003ch2 id=\"find-the-fault-line-before-you-write-scenarios\"\u003eFind the fault line before you write scenarios\u003c/h2\u003e\n\u003cp\u003eTwo of my three streams were the same kind of work. Operator-facing platform, shared substrate, overlapping users. The product doc had already proposed one designer across both, which told me the product side had reached the same conclusion without writing it down. The third was a specialised data play with different skills and a different failure mode.\u003c/p\u003e\n\u003cp\u003eIf any team was ever going to carry two streams, it had to be those two, and never one of them paired with the data work. That single observation deleted about half the possible org charts before anybody started arguing.\u003c/p\u003e\n\u003cp\u003eDo this part before the workshop. Otherwise you spend two hours debating combinations that were never viable, and the debate feels rigorous while producing nothing.\u003c/p\u003e\n\u003ch2 id=\"scenario-0-stay-one-team-sequence-the-streams\"\u003eScenario 0: stay one team, sequence the streams\u003c/h2\u003e\n\u003cp\u003eOne team of six growing to eight, under the existing lead, working one stream at a time in priority order.\u003c/p\u003e\n\u003cp\u003eMaximum resilience, no lead gap, lowest risk. Two multi-year bets also sit untouched for years, which breaks focus at the strategy level instead of the team level. Nobody on the team feels that pain, which is exactly what makes it dangerous.\u003c/p\u003e\n\u003cp\u003eI put it on the table as a real option with a review date attached, and I would do that again. Most workshops treat \u0026ldquo;not yet\u0026rdquo; as a failure to decide, so it never gets named. The room then drifts toward a split it cannot staff, because the alternative was never given a seat. Naming it, with an expiry, turns avoidance into a choice.\u003c/p\u003e\n\u003ch2 id=\"scenario-1-three-teams-now\"\u003eScenario 1: three teams now\u003c/h2\u003e\n\u003cp\u003eThe org chart the vision implies. One team per stream, everything funded, everybody happy for about ten days.\u003c/p\u003e\n\u003cp\u003eThis is the option everyone wants and nobody can staff. Three teams out of eight people means teams of two and three, which Larson would tell you behave like individuals, and which I would tell you are one resignation away from a stalled stream. Three teams also need three leads. I had one, and two of the three would have been running their first team on their first day of a multi-year mandate.\u003c/p\u003e\n\u003cp\u003eI put it on the slide anyway. Killing the seductive option with arithmetic in front of the room beats killing it privately and spending the next six months being told you never considered it.\u003c/p\u003e\n\u003ch2 id=\"scenario-2-data-plus-platform-defer-the-third-stream\"\u003eScenario 2: data plus platform, defer the third stream\u003c/h2\u003e\n\u003cp\u003eTwo teams of roughly four. The specialised stream and the foundation stream both start now. The most operations-facing stream waits.\u003c/p\u003e\n\u003cp\u003eThis was my recommendation. It funds the visible part of the strategy and the platform work at the same time, and the deferred stream should genuinely be built on top of that platform rather than beside it. The skill split was clean too: backend-heavy on one side, full-stack on the other, nobody cut in half.\u003c/p\u003e\n\u003cp\u003eBoth costs are real and I named them in the room rather than letting them surface later as surprises. I would be holding two quite different domains in my head, which degrades both. The deferred stream keeps hurting operations in the meantime, and the people living with that pain were sitting at the table while I said it.\u003c/p\u003e\n\u003ch2 id=\"scenario-3-platform-plus-the-third-stream-defer-data\"\u003eScenario 3: platform plus the third stream, defer data\u003c/h2\u003e\n\u003cp\u003eSame two-team shape, different pairing. Both teams sit on the same substrate and share infrastructure, design and vocabulary.\u003c/p\u003e\n\u003cp\u003eLowest context-switching cost of anything on the list, and it removes a technical dependency on another team\u0026rsquo;s roadmap. What it delays is the most visible part of the strategy, which is a sponsor problem rather than an engineering one. (Sponsor problems have a way of becoming engineering problems about two quarters later.)\u003c/p\u003e\n\u003cp\u003eI ranked it second and said exactly what would move it to first. If the platform dependency the data stream needed had not been ready, this one flips instantly, because the alternative is a new team spending its first months blocked on somebody else\u0026rsquo;s delivery date.\u003c/p\u003e\n\u003ch2 id=\"the-menu-is-not-there-so-the-room-can-vote\"\u003eThe menu is not there so the room can vote\u003c/h2\u003e\n\u003cp\u003eScenarios exist to force one sentence into the open. Here is the bet we are parking, and here is roughly when we come back to it.\u003c/p\u003e\n\u003cp\u003eIf a team design session ends without that sentence, nothing was decided. You rearranged boxes, everybody kept believing their favourite stream is funded, and three months later a PM asks why nobody has started on their thing. Consensus, it turns out, is what a room produces when it is avoiding a decision.\u003c/p\u003e\n\u003cp\u003eTwo questions could have flipped my recommendation, and I said so in the room rather than presenting the analysis as finished.\u003c/p\u003e\n\u003cp\u003eWho is actually lead-ready. That call is mine, it is the one I am most likely to get wrong, and it decides whether the split happens in three months or nine.\u003c/p\u003e\n\u003cp\u003eWhich stream is genuinely funded as the priority. That one belongs to me and the product sponsor jointly. It is an argument about revenue narrative versus foundation, and engineering does not get to settle it alone.\u003c/p\u003e\n\u003ch2 id=\"watch-where-the-bottleneck-lands\"\u003eWatch where the bottleneck lands\u003c/h2\u003e\n\u003cp\u003eOne thing I nearly missed, and Seibert had already written it down years ago. The product side had a single PM across the whole area.\u003c/p\u003e\n\u003cp\u003eSplit engineering into two teams under one PM and the coordination cost relocates to that person\u0026rsquo;s calendar. You have recreated the focus problem on the product side, where you have no headcount lever at all. Design has the same failure mode and usually gets noticed even later.\u003c/p\u003e\n\u003cp\u003eSeibert lists exactly this as a reason not to split. You would need another product owner and another designer, going without either is not ideal, and neither is splitting one person across two teams. Reading it back after the workshop, I think he treats that as a cost weighing against the split. I treat it as a precondition. The difference matters, because his version leaves the decision inside engineering, and mine forces a conversation with whoever owns product headcount before anything gets announced.\u003c/p\u003e\n\u003cp\u003eSo I made team formation conditional on the product side matching it one to one, and I said that with the PM in the room rather than in a polite follow-up message afterwards. (Say it in writing later and you have not raised it. You have created a paper trail for the argument you are going to lose in November.) A split that only exists in the engineering org chart is a rename with extra meetings.\u003c/p\u003e\n\u003ch2 id=\"before-you-draw-the-boxes\"\u003eBefore you draw the boxes\u003c/h2\u003e\n\u003cp\u003eCount your leads before you count your engineers. Find the fault line before you write scenarios, because half the debate you are dreading is about combinations that were never viable anyway.\u003c/p\u003e\n\u003cp\u003eAnd if the honest answer turns out to be Scenario 0, take Scenario 0 and set the review date. A holding pattern you chose on purpose beats a split you cannot staff, and your engineers can tell the difference long before you admit it to yourself.\u003c/p\u003e\n","date_modified":"2026-08-15T14:29:00Z","date_published":"2026-08-15T14:29:00Z","id":"https://leadership.garden/splitting-teams/","summary":"Most advice on splitting teams answers \"is this team too big?\" That's the wrong question when you're splitting into a strategy.","tags":["teams","leadership","management"],"title":"How I Decide Whether to Split a Team","url":"https://leadership.garden/splitting-teams/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eA team of mine shipped clean for four months. Every sprint closed, nothing slipped, on-call stayed quiet. I wrote the update to my SVP with real pride.\u003c/p\u003e\n\u003cp\u003eThen somebody outside the domain asked what had changed for the business, and I did not have an answer worth saying out loud.\u003c/p\u003e\n\u003cp\u003eThat team worked hard. They worked hard on something any competent team at any competent company could have worked hard on.\u003c/p\u003e\n\u003ch2 id=\"the-test\"\u003eThe test\u003c/h2\u003e\n\u003cp\u003eJustin Jackson published a post in June called \u003ca href=\"https://justinjackson.ca/hard-thing?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDo the hardest thing\u003c/a\u003e. His phrase for the mistake is a hard job attached to an easy idea. He opened a snowboard shop in 2003, worked harder than he has at almost any time since, and closed it in debt by 2006. Inventory, theft, scheduling, stock turnover. All of the difficulty lived in the operating, and anyone could have had the idea. Plenty did.\u003c/p\u003e\n\u003cp\u003eHe is writing for founders. The distinction transfers to anyone running an engineering org, and I think it bites harder here, because we have built an operating culture that can only see the job.\u003c/p\u003e\n\u003cp\u003eThe test I use now: if I disappeared for six months, would the difficulty go away?\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eHard-job\u003c/em\u003e difficulty is made of my effort and my team\u0026rsquo;s. Pull us out and it evaporates, because a replacement drops in and grinds the same grind. \u003cem\u003eHard-problem\u003c/em\u003e difficulty belongs to the problem. It survives reorgs and roadmap changes and both the managers who owned it leaving, and it is still sitting there when you get back.\u003c/p\u003e\n\u003ch2 id=\"we-measure-the-job\"\u003eWe measure the job\u003c/h2\u003e\n\u003cp\u003eSprint commitments, cycle time, DORA, the weekly delivery update. All of it answers one question: are these people working, and are they working in an orderly way?\u003c/p\u003e\n\u003cp\u003eNothing in that stack asks whether the work was worth choosing.\u003c/p\u003e\n\u003cp\u003e(I have written a performance review praising someone for a heroic quarter on a project I now think should have been killed in week two. The review was accurate. That is the part that bothers me.)\u003c/p\u003e\n\u003cp\u003eWill Larson\u0026rsquo;s \u003ca href=\"https://lethain.com/work-on-what-matters/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eWork on what matters\u003c/a\u003e is the standard reference here, and it is good, but it aims at your calendar. Hunter Walk\u0026rsquo;s \u003ca href=\"https://www.intercom.com/blog/first-rule-prioritization-no-snacking/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003esnacking\u003c/a\u003e, the easy low-impact work that feels productive when you are busy, describes how you spend your own hours. At forty-five people my hours are a rounding error. The portfolio that counts is what forty-five people are pointed at, and an org can run a well-instrumented grind at high morale on a problem nobody ever chose on purpose.\u003c/p\u003e\n\u003ch2 id=\"your-hardest-problem-is-not-technical\"\u003eYour hardest problem is not technical\u003c/h2\u003e\n\u003cp\u003eAsk an engineering leader at a scale-up to name the hardest problem in their org and most will reach for something technical. The monolith. The vendor migration. The test suite that fails twice a week.\u003c/p\u003e\n\u003cp\u003eThose are \u003cem\u003ehard jobs\u003c/em\u003e. Well understood, well documented, and a few hundred teams have already done them. You can hire someone who has done it before, which is close to a definition of a job.\u003c/p\u003e\n\u003cp\u003eThe problems that actually resist look more like this:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eA team that made sense two reorgs ago and now exists because dissolving it would embarrass the person who built it.\u003c/li\u003e\n\u003cli\u003eThe senior engineer everyone routes around, whose net output has been negative for a year, who is well liked.\u003c/li\u003e\n\u003cli\u003eTwo domains with a dependency that both leaders have agreed not to raise, because raising it means somebody loses headcount.\u003c/li\u003e\n\u003cli\u003eA product surface nobody owns that generates a third of your support load.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNotice you did not have to go looking. You knew which one was yours before you finished the list.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://mostlytechnical.com/episodes/133-do-the-hardest-thing-with-jesse-hanley?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eJesse Hanley\u003c/a\u003e, quoted in Justin\u0026rsquo;s post, says hard things attract little competition because most people do not want to do them. Inside a company that holds even more strongly, for a specific reason.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe cost of touching an org\u0026rsquo;s hard problem lands on whoever touches it, and the benefit spreads across everyone. So it sits there, year after year, getting more valuable to whoever finally picks it up.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"you-do-not-get-to-just-pick-it\"\u003eYou do not get to just pick it\u003c/h2\u003e\n\u003cp\u003eThis is where founder advice stops being portable, and where most attempts to translate it fall over.\u003c/p\u003e\n\u003cp\u003eJustin can decide to build podcast hosting. Nobody has to approve it. \u003cem\u003eI cannot decide that my domain spends two quarters unwinding a team that reports to a peer.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eSo the real work sits one level above the problem. You have to buy the right to own it, and I have never seen anyone name that as work, which is strange, because for most Heads/Directors of Engineering \u003cstrong\u003eit is the work\u003c/strong\u003e.\u003c/p\u003e\n\u003cp\u003eSay it out loud, early, in a room with the person who could kill it. These problems survive on being discussed in pairs, in kitchens, after the meeting ends. Naming it in front of leadership costs you something and permanently changes its status. \u003cem\u003eIt becomes a thing that was said.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eTurn it into a bet with a date and a number. \u0026ldquo;Operator onboarding is bad\u0026rdquo; gets nodded at and forgotten. \u0026ldquo;We take time to first value from eleven days to three by the end of Q3\u0026rdquo; gets argued with, which is what you want. The argument is how you find out who is actually opposed, and it is rarely who you expected.\u003c/p\u003e\n\u003cp\u003eGive something up in public. Nobody believes you are serious until they watch you stop doing something else to make room. It is also the fastest way to learn whether your leadership agrees with you or was just being polite.\u003c/p\u003e\n\u003cp\u003eGet one executive \u003cem\u003eon the hook\u003c/em\u003e for the downside. \u003cem\u003eApproval is not the same thing\u003c/em\u003e. I mean somebody senior whose name is attached to the failure case, because on your own you are a person with an opinion who might not be here next year, and everyone in the room knows it.\u003c/p\u003e\n\u003ch2 id=\"where-this-gets-people-hurt\"\u003eWhere this gets people hurt\u003c/h2\u003e\n\u003cp\u003eHanley spent seven years on \u003ca href=\"https://bentonow.com/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eBento\u003c/a\u003e before it paid off. He could afford to, because he owned it.\u003c/p\u003e\n\u003cp\u003eYou have a performance cycle. Maybe eighteen months of runway with your current VP, less if they leave. Commit your org to a hard problem that does not resolve inside that window and you carry the cost while your successor collects the return. That asymmetry is real, and I am not going to pretend otherwise for the sake of a cleaner argument.\u003c/p\u003e\n\u003cp\u003eSo pick hard problems that pay out in visible pieces. A bet that returns nothing until month twenty belongs to a founder. And \u003cem\u003eaccept that some hard problems are not worth your career\u003c/em\u003e. (I have walked past one I still think about. I would walk past it again.)\u003c/p\u003e\n\u003cp\u003eWalking past one is still a choice. What I am arguing against is the drift: falling into a hard job by default and then reading the exhaustion as evidence that you picked the right thing.\u003c/p\u003e\n\u003ch2 id=\"ask-who-else-could-do-it\"\u003eAsk who else could do it\u003c/h2\u003e\n\u003cp\u003eLook at what your org is grinding on this quarter and ask who else could grind on it. If the answer is any competent team anywhere, you are running a hard job. It will still be difficult, and it will still tire everyone out. It just will not be worth much.\u003c/p\u003e\n\u003cp\u003eYou already know what the hard problem is. Everyone does. The question is whether you will be the one who says it in a room where saying it costs you something.\u003c/p\u003e\n","date_modified":"2026-08-08T08:11:25Z","date_published":"2026-08-08T08:11:25Z","id":"https://leadership.garden/the-hardest-thing/","summary":"Most engineering orgs run a hard job attached to an easy idea. How to tell the difference, and what to do about it.","tags":["leadership"],"title":"A hard job attached to an easy idea","url":"https://leadership.garden/the-hardest-thing/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eI was sitting in a quarterly review when an engineering director looked at a slide saying a migration was 72 percent complete and asked, \u0026ldquo;Which of the assumptions behind this are still true?\u0026rdquo; We had spent eighteen months moving a large product to a new platform. At the time, the decision rested on a coming end-of-support date, a plan to double the engineering group, and a customer certification that appeared to require capabilities only the new platform provided.\u003c/p\u003e\n\u003cp\u003eBy the day of the review, the vendor had extended support, hiring had stopped, and the certification team had found another route six months earlier. The program still had fourteen people assigned to it and a green status on the portfolio dashboard. Once the question was out in the room, however, the discussion moved away from customers and technology. We talked about the work already completed, what we had told the board, and how cancellation might land with the teams. One executive said that changing course would damage our credibility, and I wrote the sentence in the margin because it explained the meeting better than the slide did.\u003c/p\u003e\n\u003cp\u003eIf you lead engineering, product, or a company, you will eventually inherit a decision like this. It may concern a platform migration, a reorganization, an acquisition, a pricing model, or a product that has never found a market. In each case, the original reasoning has weakened while the work created by the decision has become a substantial fact of organizational life. Asking whether the choice still makes sense can then sound less like routine management and more like an accusation.\u003c/p\u003e\n\u003ch2 id=\"decisions-become-part-of-the-organization\"\u003eDecisions become part of the organization\u003c/h2\u003e\n\u003cp\u003eA decision starts as a choice among alternatives, but it quickly produces consequences that are harder to move. Budgets shift, teams form, contracts get signed, and roadmaps absorb dependencies. Someone may get promoted for leading the work while another group is asked to wait because the organization has committed elsewhere. Within a few quarters, the choice has become part of the structure surrounding it, with employees and commercial obligations that remain even if the original argument weakens.\u003c/p\u003e\n\u003cp\u003eThe reasoning rarely survives that process intact. A decision document may record what was approved and who approved it, followed by a few broad paragraphs about benefits, risks, and strategic fit. \u0026ldquo;Improves scalability\u0026rdquo; tells a future reader almost nothing about the scale problem that mattered, the growth forecast used, or the evidence that would have disproved it. People who join later therefore learn the decision as a settled fact: we are moving to the new platform, centralizing this function, or building for enterprise customers. They inherit an implementation plan without the uncertainty that surrounded the original choice.\u003c/p\u003e\n\u003cp\u003eThat lost uncertainty matters because markets, regulations, customer preferences, and internal constraints continue to change. A decision that made sense two years ago may have little value now without having been foolish at the time. Leaders often feel pushed toward defending it because the apparent alternative is to confess a mistake, which is both inaccurate and personally costly when the old reasoning was sound. They may be right about the quality of the decision they made and still be wrong to keep funding it today.\u003c/p\u003e\n\u003ch2 id=\"why-organizations-keep-going\"\u003eWhy organizations keep going\u003c/h2\u003e\n\u003cp\u003eThe usual diagnosis is the sunk cost fallacy: we continue because we have already spent the money, time, and political capital. Barry Staw\u0026rsquo;s work on escalation of commitment showed that people often increase their support after receiving negative feedback, especially when they were responsible for the initial choice. Self-justification, loss aversion, confirmation bias, and the urge to complete what we started all contribute. Inside an organization, however, persistence can also look like evidence that a leader is steady and dependable, which gives people another reason to prefer it.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://thedecisionlab.com/biases/commitment-bias?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eThe Decision Lab\u003c/a\u003e describes research in which participants trusted CEOs more when those CEOs kept funding product development after learning that a competitor had a better product. I understand why. Nobody wants a leader who rewrites strategy every time a metric dips, and most worthwhile efforts pass through periods when the evidence looks bad. The difficulty is that organizations are poor at distinguishing steadiness from attachment, particularly once the person interpreting the evidence also sponsored the original choice.\u003c/p\u003e\n\u003cp\u003eA public decision changes the social cost of information. Before approval, a troubling fact helps the group choose well. After approval, it can threaten the sponsor\u0026rsquo;s judgment and undermine months of work by the team. People notice the difference, so status updates start to emphasize progress while risks become matters of execution. Another quarter, feature, customer segment, or enablement effort may be defensible on its own, but a series of those small extensions can convert evidence against the decision into a recurring request for more investment.\u003c/p\u003e\n\u003cp\u003eStopping also creates costs that are immediate and easy to name: a write-off, a revised roadmap, a difficult board conversation, and a team that needs new work. The costs of continuing arrive gradually through missed opportunities, delayed hiring, added operational work, and capable people spending another year on a problem whose value has fallen. We rarely account for the product that was never built or the customer problem that waited because the team was occupied elsewhere. The leader proposing a stop must therefore own a visible disruption now, while the leader proposing continuation can spread the cost across several teams and future quarters.\u003c/p\u003e\n\u003cp\u003eOrdinary execution reporting reinforces the imbalance. Portfolio reviews tend to ask whether a program is on schedule, within budget, and delivering milestones, which tells you whether the team is carrying out the plan but says little about whether the plan remains worthwhile. A migration can hit every milestone after the vendor risk that justified it has vanished. A sales team can complete its hiring plan while acquisition costs ruin the business case. A reorganization can move every employee into the intended box even though it never resolves the ownership problem behind the change.\u003c/p\u003e\n\u003cp\u003eFreek Vermeulen and Niro Sivanathan describe this as escalation of commitment to a once successful strategy. Their \u003ca href=\"https://hbr.org/2017/11/stop-doubling-down-on-your-failing-strategy?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eHBR article\u003c/a\u003e uses HMV, whose store model had produced years of success before the market moved online. That history made contrary evidence easier to dismiss because leaders could point to a long period in which the same judgment had been correct. I have made a smaller version of this mistake myself by pushing a team harder because I trusted a pattern that worked in another company, at another scale, for a different customer. The team executed well, but my assumption did not travel with me, and extra effort merely made the mismatch more expensive.\u003c/p\u003e\n\u003ch2 id=\"record-what-must-remain-true\"\u003eRecord what must remain true\u003c/h2\u003e\n\u003cp\u003eMost decision records tell us what was approved, who owns the work, and what happens next. They are much less likely to state what must remain true for the decision to keep its authority, even though that is the part a later team will need when circumstances change. Adding the question forces broad claims into a form that people can examine. \u0026ldquo;We need a new platform for scale,\u0026rdquo; for example, becomes \u0026ldquo;The current platform will exceed its tested transaction limit within eighteen months, based on the approved growth forecast.\u0026rdquo; An enterprise strategy can specify how many qualified prospects must accept the proposed security model and price. The language is less polished, but a future reader can see what evidence supported the choice.\u003c/p\u003e\n\u003cp\u003eMark Hollingworth\u0026rsquo;s \u003ca href=\"https://iveybusinessjournal.com/revisiting-strategic-assumptions/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003earticle on revisiting strategic assumptions\u003c/a\u003e describes field research in which startups identified hypotheses, selected evidence thresholds, and changed course when the thresholds were not met. One company continued with its proposed business model only if four customer assumptions held, while another changed its target customer and its vehicle after testing exposed weaknesses in the original idea. The founders remained committed to building their companies. What changed was the precision with which they decided whether a particular model deserved more time.\u003c/p\u003e\n\u003cp\u003eI now want six things in a decision record:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eThe outcome we want, stated in terms a customer or operator would recognize.\u003c/li\u003e\n\u003cli\u003eThe assumptions that connect the decision to that outcome.\u003c/li\u003e\n\u003cli\u003eThe evidence available when we made the choice.\u003c/li\u003e\n\u003cli\u003eThe signals that would require us to review it.\u003c/li\u003e\n\u003cli\u003eThe expected cost of continuing, changing, or stopping.\u003c/li\u003e\n\u003cli\u003eThe person who can call for a review, especially if the original sponsor disagrees.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThis takes more effort than writing \u0026ldquo;approved\u0026rdquo; in a meeting note, although considerably less than funding obsolete work for several years. The record does not need to pretend that every uncertainty can be reduced to a clean metric. A qualitative assumption can be useful if people can describe the evidence that would weaken it. \u0026ldquo;Customers will tolerate the migration\u0026rdquo; is too vague, while \u0026ldquo;our ten largest customers will accept one scheduled outage and no more than two required integration changes\u0026rdquo; gives a team something it can investigate before memory reshapes the original reasoning.\u003c/p\u003e\n\u003ch2 id=\"review-current-evidence-without-retrying-the-past\"\u003eReview current evidence without retrying the past\u003c/h2\u003e\n\u003cp\u003eAsking \u0026ldquo;Was this a bad decision?\u0026rdquo; is a poor way to open a review because the meeting immediately becomes a trial of the original participants. People reconstruct old information, defend their intentions, and debate whether somebody should have predicted an event that looked unlikely at the time. A more useful sequence begins with the intended outcome, then examines each original assumption against current evidence before comparing the options available now.\u003c/p\u003e\n\u003cp\u003eThis separates the quality of the old reasoning from the present value of the choice. A decision may have been sensible then and sensible now, sensible then but weak now, or poorly reasoned from the start and either lucky or costly in its results. The current evidence should determine what happens next, while the quality of the original process belongs in a later learning review. Keeping those conversations apart makes accountability more accurate because leaders can still answer for hidden risks and ignored evidence without being punished whenever a reasonable forecast fails. If every change of course requires a confession, most leaders will wait until the evidence becomes overwhelming.\u003c/p\u003e\n\u003cp\u003eIsabelle Royer, writing about \u003ca href=\"https://hbr.org/2003/02/why-bad-projects-are-so-hard-to-kill?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eprojects that organizations could not kill\u003c/a\u003e, argued for an \u0026ldquo;exit champion\u0026rdquo; with enough standing to assemble the case for stopping. The original sponsor should remain involved because that person usually knows more about the decision than anyone else, but sole ownership makes an impartial review unlikely. I have found that a second credible leader can provide enough independence to test the current case without reducing the discussion to criticism from someone who lacks context.\u003c/p\u003e\n\u003ch2 id=\"decide-in-advance-what-will-trigger-a-review\"\u003eDecide in advance what will trigger a review\u003c/h2\u003e\n\u003cp\u003eScheduled reviews help, but a calendar alone is a blunt instrument because the passage of six months does not necessarily make a decision questionable. A material change in one of its supporting conditions does. \u003ca href=\"https://knowledge.wharton.upenn.edu/article/its-not-you-its-your-goals-knowing-when-to-quit/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eAnnie Duke calls the more decisive versions of these conditions kill criteria\u003c/a\u003e: signals chosen while judgment is relatively clear that will cause you to modify or abandon a goal. A review trigger can be gentler. It does not dictate the outcome, but it obliges somebody to gather current evidence and recommend whether to continue, change, or stop.\u003c/p\u003e\n\u003cp\u003eThe useful triggers depend on the decision. A product team might reopen its plan when adoption falls below an agreed threshold or acquisition cost changes substantially. A technical program could use a shift in vendor support, traffic forecasts, regulatory requirements, or the relative cost of migration and continued operation. After a reorganization, unchanged decision time or work continuing across the same boundaries may reveal that the structure did not address the problem it was designed to solve.\u003c/p\u003e\n\u003cp\u003eI would give material decisions both a review date and a small number of evidence-based triggers rather than an automatic expiry. Automatic expiry invites churn and encourages teams to wait out a direction they dislike, while an optional review is easily skipped when it becomes uncomfortable. Reaching a date or trigger should produce a recorded choice. If no one acts, the old decision should not renew itself by default.\u003c/p\u003e\n\u003ch2 id=\"make-the-cost-comparison-honest\"\u003eMake the cost comparison honest\u003c/h2\u003e\n\u003cp\u003eWhen a review finally happens, teams often compare the immediate cost of stopping with the total value they once expected from finishing. That comparison favors continuation because it mixes money already spent with benefits that may never arrive. Past spending can teach you about the original estimate and process, but it cannot improve the return on the next dollar. The current comparison should include:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ethe remaining cost and likely value of continuing\u003c/li\u003e\n\u003cli\u003ethe switching cost and likely value of the best alternative\u003c/li\u003e\n\u003cli\u003ethe operating cost of delay\u003c/li\u003e\n\u003cli\u003eobligations to customers, employees, and partners\u003c/li\u003e\n\u003cli\u003ewhat the organization could do with the people, time, and attention released\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSwitching costs are real. Contracts have termination clauses, migrations leave systems in awkward intermediate states, teams lose momentum, and customers may have planned around a promise. A review that ignores those facts becomes an abstract lesson in rationality rather than a management decision. Sometimes continuing remains the best available choice because a change would now cost too much, but leaders should reach that conclusion by comparing future options from the present instead of asking past investment to justify another round.\u003c/p\u003e\n\u003cp\u003eOpportunity cost deserves similar care because an imagined alternative has no defects yet. When somebody says, \u0026ldquo;We could use the team elsewhere,\u0026rdquo; I ask for a named piece of work, an owner, and a plausible first ninety days. The alternative should face the same scrutiny as the program under review rather than benefiting from its lack of history.\u003c/p\u003e\n\u003ch2 id=\"the-leader-sets-the-price-of-changing-course\"\u003eThe leader sets the price of changing course\u003c/h2\u003e\n\u003cp\u003eEvery organization says it wants people to surface bad news, but employees learn what that means by watching the first person who tries. If a director brings evidence that an executive\u0026rsquo;s decision has aged badly, the executive\u0026rsquo;s first response sets the price of candor for everyone else. Asking why the risk was not found earlier may sound like due diligence, yet it often turns the messenger into the subject before the group has considered the evidence.\u003c/p\u003e\n\u003cp\u003eI try to begin with \u0026ldquo;What changed?\u0026rdquo; and \u0026ldquo;What do you recommend now?\u0026rdquo; The first question distinguishes changed conditions from blame, while the second makes the person raising the issue responsible for a better choice rather than giving them permission to criticize from the sidelines. When revising my own decisions, I prefer a plain account of what happened: \u0026ldquo;I approved this based on the evidence we had. Two assumptions no longer hold, so I am reopening it.\u0026rdquo; That sentence names the decision maker without forcing an apology unless one is actually due.\u003c/p\u003e\n\u003cp\u003eSome leaders worry that revisiting a choice makes them look indecisive, and frequent changes without clear criteria certainly do erode trust. Teams usually react differently when they can see that the evidence crossed a threshold set in advance. Engineers know when a migration no longer solves its stated problem, product managers notice when every customer conversation requires a new justification, and frontline managers can tell when a reorganization moved names without changing decisions. They may continue doing the work, but they will no longer believe the status report if leadership refuses to acknowledge what they see.\u003c/p\u003e\n\u003ch2 id=\"a-review-needs-a-threshold\"\u003eA review needs a threshold\u003c/h2\u003e\n\u003cp\u003eThere is a corresponding risk in making every decision easy to reopen. Teams can spend months repeating old debates, treat ordinary execution difficulty as evidence that the choice was wrong, and pull senior leaders into matters that were already settled. New evidence should connect to an assumption that materially influenced the decision, and the person asking for a review should propose a current alternative that includes the cost of switching.\u003c/p\u003e\n\u003cp\u003eA disappointing result may not meet that standard. A product can miss its first adoption target while the customer problem remains real, and a new architecture can take longer than planned while the old system still faces a firm end-of-life date. The early months after a reorganization are often awkward because people are learning new responsibilities. Leaders still have to judge whether the team is struggling with hard execution or working from a premise that has broken, which no process can do on their behalf.\u003c/p\u003e\n\u003cp\u003eThe decision owner remains responsible for the final choice, and a review does not require consensus. It requires a good-faith examination of the current evidence and a recorded conclusion. Once the group decides, the team should understand what changed, what remained true, and which future trigger would warrant another discussion so that people can commit to the work again.\u003c/p\u003e\n\u003ch2 id=\"a-practical-decision-review\"\u003eA practical decision review\u003c/h2\u003e\n\u003cp\u003eI use a short written review before the meeting because it prevents the loudest person in the room from defining the history. The author answers five questions:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eWhat outcome did we intend, and what did we decide?\u003c/li\u003e\n\u003cli\u003eWhich original assumptions still hold?\u003c/li\u003e\n\u003cli\u003eWhat material evidence has changed?\u003c/li\u003e\n\u003cli\u003eWhat options are available now, including the cost of switching?\u003c/li\u003e\n\u003cli\u003eWhat is the recommendation, owner, and next review trigger?\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe meeting can usually fit into forty-five minutes, with the first ten spent on the original objective and assumptions, the next fifteen on current evidence, and the rest on options and a decision. If people disagree about what the original assumption was, I record that as a flaw in the earlier process and work with the best evidence available instead of letting the meeting become an attempt to edit history. I also ask someone who was not involved in the original choice to read the review. They do not need veto power, only enough standing to ask the question that insiders have stopped noticing.\u003c/p\u003e\n\u003cp\u003eThe final note should state whether the organization will continue, modify, or stop, along with the evidence, owner, and next trigger. The roadmap, budget, and team goals should change soon afterward. Otherwise the review becomes another document that everyone politely acknowledges and then ignores.\u003c/p\u003e\n\u003ch2 id=\"what-happened-to-the-migration\"\u003eWhat happened to the migration\u003c/h2\u003e\n\u003cp\u003eWe did not cancel the platform migration during that quarterly review. Instead, the engineering director and a finance partner reconstructed the original case, compared the remaining work with two years of operating cost on the old platform, and spoke with both the certification team and the vendor. A week later, they recommended stopping most of the program while keeping a smaller part that still addressed a real reliability problem.\u003c/p\u003e\n\u003cp\u003eThe announcement was uncomfortable. One team had just finished planning the next quarter and discarded much of its work, while the company wrote off contractor time and training. Several people said we had wasted eighteen months, and in part they were right. We had also learned enough about the new platform to make a more informed choice, and some components found uses elsewhere, but that did not make the disruption disappear.\u003c/p\u003e\n\u003cp\u003eSix months later, the board had asked its difficult questions and moved on. Most of the engineers were working on reliability and customer problems we had deferred. Looking back, I think our credibility had suffered more from continuing to report the program as healthy after its rationale had weakened than it did from changing course.\u003c/p\u003e\n\u003cp\u003eSince then, before approving a material decision, I have tried to ask what would have to change for us to revisit it. An inability to answer usually means the choice will become harder to undo than it deserves, while an answer that threatens the sponsor teaches the organization to hide evidence. Leaders who signed yesterday\u0026rsquo;s decision have an added responsibility to review it honestly today.\u003c/p\u003e\n","date_modified":"2026-08-05T12:14:00Z","date_published":"2026-08-05T12:14:00Z","id":"https://leadership.garden/failing-decisions/","summary":"Why do organizations defend failing decisions? Learn how to record assumptions, set review triggers, and change course without turning to blame.","tags":["decisions","leadership"],"title":"Why Organizations Defend Failing Decisions","url":"https://leadership.garden/failing-decisions/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eEngineering management careers often begin through accumulation. You know the roadmap, so you take on hiring. You know the new hires, so you handle onboarding. You understand the team, so people ask you to coach them.\u003c/p\u003e\n\u003cp\u003eWhat interests me is how ordinary each request sounds. None feels like a career change on its own, but together they move your work somewhere else.\u003c/p\u003e\n\u003cp\u003eMost advice for new managers focuses on delegation: hand off tickets, leave critical work to the team, and make sure it can operate without you. That advice is sound. It also stops one step early. A team can keep shipping without its manager and still depend on judgment the manager never taught.\u003c/p\u003e\n\u003cp\u003eThe harder job is to make that judgment transferable.\u003c/p\u003e\n\u003cp\u003eEvery useful intervention should leave someone better able to understand the customer, weigh risk, or communicate a recommendation. Over time, they should make the next decision without waiting for permission. The work changes with the company and the team. That standard holds.\u003c/p\u003e\n\u003ch2 id=\"the-role-moves\"\u003eThe role moves\u003c/h2\u003e\n\u003cp\u003eEngineering management moves across product, process, people, and programming. The balance changes constantly. A small team may need its manager in the code. A team without a product manager may need its engineering manager in customer calls. A large team may consume every available hour with hiring, coaching, and coordination.\u003c/p\u003e\n\u003cp\u003eI think this is why a universal job description for engineering managers tends to disappoint. The useful question is local: where is this team currently unable to make a sound decision?\u003c/p\u003e\n\u003cp\u003eSometimes the answer is technical. More often, the team lacks context, authority, or confidence. A manager who responds to every gap by taking over may get a good result this week. The team learns to wait for the same rescue next week.\u003c/p\u003e\n\u003cp\u003eNew managers often retreat toward technical work because they already know how to succeed there. Management remains the awkward work they do between coding sessions.\u003c/p\u003e\n\u003cp\u003eThree months later, I would ask one question: can more people make sound decisions without the manager stepping in?\u003c/p\u003e\n\u003ch2 id=\"context-is-the-first-handoff\"\u003eContext is the first handoff\u003c/h2\u003e\n\u003cp\u003eManagers often delegate work while keeping the reason for the work to themselves. The engineer receives a ticket, a deadline, and perhaps a mock-up. The manager keeps the customer complaint, the commercial pressure, the rejected alternatives, and the reason the deadline matters.\u003c/p\u003e\n\u003cp\u003eThat is task distribution. It creates activity, though it does little for judgment.\u003c/p\u003e\n\u003cp\u003eProduct context changes the quality of delegation. An engineer who understands the user and constraints can question a weak spec, choose a cheaper approach, or decide that no new code is needed. An engineer with only the ticket can deliver exactly what was requested, including its mistakes.\u003c/p\u003e\n\u003cp\u003eBefore handing off meaningful work, I would want the person taking it to know:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ewho has the problem and what they are trying to accomplish\u003c/li\u003e\n\u003cli\u003ewhich constraints are real and which ones are habits\u003c/li\u003e\n\u003cli\u003ewhat a poor outcome would cost\u003c/li\u003e\n\u003cli\u003ewhich decisions are reversible\u003c/li\u003e\n\u003cli\u003ewhen they should ask for help\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThis takes longer than assigning a ticket because you are handing over the material someone needs to exercise judgment. That material rarely fits in a status update.\u003c/p\u003e\n\u003ch2 id=\"process-can-preserve-fear\"\u003eProcess can preserve fear\u003c/h2\u003e\n\u003cp\u003eConsider a familiar example of process bloat. An engineer ships a broken interface, everyone reacts, and designer approval becomes mandatory for every pull request. One failure produces a permanent tax for the entire team.\u003c/p\u003e\n\u003cp\u003eManagers add controls because controls feel responsible. The cost arrives later, spread across enough people that nobody can point to it. The extra review becomes normal. Six months on, the team remembers the rule and forgets the incident. (The rule rarely comes with an expiry date.)\u003c/p\u003e\n\u003cp\u003eBefore adding a process, write down the failure it is meant to prevent. Estimate how often that failure occurs, what recurrence would cost, and what the new control will cost every week. Set a date to review the trade. A control without a review date has a good chance of outliving the problem.\u003c/p\u003e\n\u003cp\u003eProcess can transfer judgment when it records a lesson people can apply. A short release checklist may remind an engineer to inspect the failure modes that previously hurt users. Requiring another person to approve every routine choice sends a different message: judgment lives elsewhere.\u003c/p\u003e\n\u003cp\u003eMature teams need useful constraints, with old controls removed once their purpose has passed.\u003c/p\u003e\n\u003ch2 id=\"communication-teaches-people-how-to-think\"\u003eCommunication teaches people how to think\u003c/h2\u003e\n\u003cp\u003eCommunicating down and communicating up require different kinds of discipline.\u003c/p\u003e\n\u003cp\u003eWhen speaking with the team, the manager owes people enough truth to understand their situation. If customers are unhappy or a project may be cancelled, hiding that information makes sensible planning impossible. People fill unexplained gaps with guesses, and their guesses are often worse than the facts.\u003c/p\u003e\n\u003cp\u003eTransparency does not require forwarding every anxious message from an executive. Share what is known, what remains uncertain, what decision has been made, and what the team can do next. That gives people a usable picture of reality.\u003c/p\u003e\n\u003cp\u003eCommunication upward requires compression and a point of view. Managers sometimes present two half-formed options to executives, then leave with a third option nobody wanted. The executive made a decision because the manager brought a problem without a recommendation.\u003c/p\u003e\n\u003cp\u003eA useful upward brief contains the context, the problem, your recommendation, the alternatives you rejected, and the support you need. Writing it forces you to decide what you think. Sharing that reasoning with the team lets other people practice the same discipline.\u003c/p\u003e\n\u003cp\u003eAfter a few of these briefs, someone else on the team should be able to write one without you.\u003c/p\u003e\n\u003ch2 id=\"follow-up-is-part-of-trust\"\u003eFollow-up is part of trust\u003c/h2\u003e\n\u003cp\u003eTrust becomes vague advice surprisingly quickly. Managers hear that they should grant autonomy, so they step back. Then a project drifts for three weeks, and the same manager returns with daily status checks.\u003c/p\u003e\n\u003cp\u003eTrust and follow-up belong together when follow-up helps someone recover early. The purpose is to notice a missing dependency, a misunderstood goal, or an engineer who has been stuck too long to admit it comfortably.\u003c/p\u003e\n\u003cp\u003eNumbers can help, but they see a narrow part of the work. Pull requests and completed tickets will miss the engineer who catches weak requirements before implementation. They will miss the person who helps three teammates finish, or explains a difficult system well enough that another team can finally use it.\u003c/p\u003e\n\u003cp\u003eQualitative judgment is slower. It requires being present in planning, reading the awkward thread, and noticing who people call when the work becomes confusing. This is one reason automated management dashboards promise more than they can deliver. They count visible artifacts while much of a team\u0026rsquo;s value appears between them.\u003c/p\u003e\n\u003cp\u003eGood follow-up asks about the next decision, the evidence behind it, and where confidence is low. It gives the manager a chance to coach without taking the work back.\u003c/p\u003e\n\u003ch2 id=\"give-away-the-next-decision\"\u003eGive away the next decision\u003c/h2\u003e\n\u003cp\u003eManagers rarely set out to become bottlenecks. They keep a critical tool because they built it. They remain the contact for another team because they already know everyone. Technical decisions reach them because answering takes five minutes and teaching may take an hour.\u003c/p\u003e\n\u003cp\u003eThat hour is the work.\u003c/p\u003e\n\u003cp\u003eEach recurring intervention should leave something behind: an owner, a written constraint, a decision rule, or a direct relationship between two people. Those people may have previously communicated through the manager. The immediate exchange may be slower. The fifth exchange should no longer require you.\u003c/p\u003e\n\u003cp\u003eA month away is often used as the test of a healthy team. I like the test, with one addition. A team can continue moving while its manager is absent and still make poor decisions. Continuity is useful. Independent judgment is better.\u003c/p\u003e\n\u003cp\u003eLook at the ordinary week instead. Do engineers make small, reversible choices without asking permission? Can they explain the customer problem behind their work? Do they know when a risk deserves escalation? Can they disagree by comparing tradeoffs instead of defending positions?\u003c/p\u003e\n\u003cp\u003eListen to how the team argues when you stay quiet. If people compare customer impact, reversibility, and cost, the team has learned how you weigh a decision.\u003c/p\u003e\n\u003cp\u003eManagers will always retain obligations that cannot be delegated: performance decisions, staffing, organizational commitments, and some difficult conversations. Their reasoning should not remain trapped in their calendars.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eIf every answer still lives with you, you have collected work rather than built leadership. Teach the reasoning, give away the decision, and stay close enough to see what people learn. Then give away the next one.\u003c/p\u003e\n\u003c/blockquote\u003e\n","date_modified":"2026-07-29T20:11:00Z","date_published":"2026-07-29T20:11:00Z","id":"https://leadership.garden/transferable-judgment/","summary":"Learn how managers can transfer context, judgment, and decision-making ability so their teams operate independently without losing direction.","tags":["leadership"],"title":"Make Your Judgment Transferable","url":"https://leadership.garden/transferable-judgment/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eI caught myself feeling good about a dashboard last quarter.\u003c/p\u003e\n\u003cp\u003eDeploy frequency up. Cycle time down. Every tile is green. I sat in the review and felt that small clean hit of satisfaction, the kind that tells you the work is going well. Then it occurred to me that I had no idea whether any of it was true. I knew the numbers were up. I didn\u0026rsquo;t know if the engineering was good.\u003c/p\u003e\n\u003cp\u003eA writer who goes by german s. recently named the thing I was doing to myself. He calls it \u003ca href=\"https://igerman.cc/blog/dopamine-fracking/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003edopamine fracking\u003c/a\u003e: pumping disproportionate resources into something layered and complex to forcefully extract the purest, most concentrated hit, with no regard for anything but the hit. Like oil fracking, the short-term yield is intense, and the long-term damage is the whole point you\u0026rsquo;re ignoring. He wrote it as a piece about culture, hobbies, music, and the flattening of things people used to love. I read it as a description of my job.\u003c/p\u003e\n\u003cp\u003eThis is for engineering leaders who measure teams for a living. Which is most of us. I want to make the case that the dashboards aren\u0026rsquo;t the real risk, and that the thing actually at stake is something you won\u0026rsquo;t see on any chart until it\u0026rsquo;s already gone.\u003c/p\u003e\n\u003ch2 id=\"goodharts-law-with-a-body\"\u003eGoodhart\u0026rsquo;s Law with a body\u003c/h2\u003e\n\u003cp\u003eWe already have a sterile name for half of this. \u003ca href=\"https://en.wikipedia.org/wiki/Goodhart%27s_law?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGoodhart\u0026rsquo;s Law\u003c/a\u003e: when a measure becomes a target, it stops being a good measure. Every engineering blog has covered it (\u003ca href=\"/tags/learning/\"\u003eincluding me, from a different angle\u003c/a\u003e). Lines of code get padded. Velocity gets inflated. Coverage hits ninety percent with tests that assert nothing.\u003c/p\u003e\n\u003cp\u003eAll true, all known. The DORA team themselves \u003ca href=\"https://dora.dev/guides/dora-metrics/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003etell you not to use their metrics for league tables\u003c/a\u003e. If gaming were the whole story we\u0026rsquo;d have solved this years ago, because gaming is the easy part to catch. You can see padded commits. You can feel a sprint that hit its points and shipped nothing.\u003c/p\u003e\n\u003cp\u003eWhat \u0026ldquo;dopamine fracking\u0026rdquo; adds is the part Goodhart leaves out. Goodhart describes the mechanism. It doesn\u0026rsquo;t describe what the mechanism does to you after years of standing next to it.\u003c/p\u003e\n\u003ch2 id=\"the-part-everyone-skips\"\u003eThe part everyone skips\u003c/h2\u003e\n\u003cp\u003egerman\u0026rsquo;s strawberry example is the one that stuck with me, so I\u0026rsquo;ll borrow it.\u003c/p\u003e\n\u003cp\u003eA real strawberry is absurdly complex. Hundreds of compounds, thousands of strains, every single one slightly different. You can isolate the one molecule that smells most like strawberry, synthesize it, and put it in everything from cheap candy to expensive dessert. Cheaper, more concentrated, and most people can\u0026rsquo;t tell. That\u0026rsquo;s the food industry. It\u0026rsquo;s also your metrics program.\u003c/p\u003e\n\u003cp\u003eThe move that matters here isn\u0026rsquo;t the gaming. It\u0026rsquo;s what the synthetic version does to your palate over time.\u003c/p\u003e\n\u003cp\u003eFirst you stop noticing the difference. Then you start to prefer the concentrated hit because it\u0026rsquo;s cleaner and louder than the real thing. Then, eventually, you can\u0026rsquo;t find the real thing at all, because nobody grew it. The market filled up with the cheap version, and the actual strawberries quietly went extinct.\u003c/p\u003e\n\u003cp\u003eRun that forward in an engineering org. You optimize for the legible signal long enough, and you lose the ability to tell good engineering apart from the performance of good engineering. A green board and a healthy team produce the same dopamine, so you stop distinguishing them. You promote the people who generate clean numbers over the people doing the quiet work that never charts, because the numbers are what you can see. After a few cycles of that, you\u0026rsquo;ve selected an entire organization for how well it grows in synthetic soil. The people who knew how to grow the real thing left, or never got hired, or learned to stop bothering.\u003c/p\u003e\n\u003cp\u003eNobody games their way there. They taste their way there, one reasonable quarter at a time.\u003c/p\u003e\n\u003ch2 id=\"your-judgment-is-the-most-frackable-thing-you-own\"\u003eYour judgment is the most frackable thing you own\u003c/h2\u003e\n\u003cp\u003eThis is where I think the existing writing stops too early. It aims all of this at engineers: how we measure them, how we accidentally train them to pad and inflate.\u003c/p\u003e\n\u003cp\u003eTurn the rig around. Point it at yourself.\u003c/p\u003e\n\u003cp\u003eThe least measurable substance in the entire building is leadership judgment. It has no dashboard. There\u0026rsquo;s no tile for \u0026ldquo;made a hard call that looks wrong for two quarters and right in year three,\u0026rdquo; or \u0026ldquo;spent six months developing someone\u0026rsquo;s taste,\u0026rdquo; or \u0026ldquo;killed a project everyone wanted.\u0026rdquo; So those are the things that get fracked hardest, precisely because they\u0026rsquo;re illegible. They can\u0026rsquo;t defend themselves with a number.\u003c/p\u003e\n\u003cp\u003eWhat you reach for instead is the concentrated hit. The status that goes green. The reorg you can announce. The \u0026ldquo;we shipped\u0026rdquo; post in the company channel. Each one is a real, clean shot of looking effective, and each one is far easier to feel good about than the actual work of leadership, which is slow and quiet and rarely legible in the moment.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m not above this. I reach for the hit constantly. The Slack post feels better than the conversation. The dashboard feels better than the doubt.\u003c/p\u003e\n\u003ch2 id=\"running-the-rig-and-standing-under-it\"\u003eRunning the rig and standing under it\u003c/h2\u003e\n\u003cp\u003eThe trap is that you\u0026rsquo;re doing both jobs at once.\u003c/p\u003e\n\u003cp\u003eYou\u0026rsquo;re the operator. Every metric you choose to elevate is a drill you\u0026rsquo;re sinking into your own teams, training them toward the signal you reward. You\u0026rsquo;re also standing under someone else\u0026rsquo;s rig, reporting up, getting fracked by the dashboards your own leadership stares at. You optimize your teams for legibility because you\u0026rsquo;re being optimized for legibility. It runs all the way up.\u003c/p\u003e\n\u003cp\u003eSome people will say the answer is better metrics. \u003ca href=\"https://queue.acm.org/detail.cfm?id=3454124\u0026amp;ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSPACE\u003c/a\u003e instead of velocity. DORA done properly, three dimensions, qualitative balanced against quantitative. That\u0026rsquo;s true, and I use all of it. But it isn\u0026rsquo;t the interesting part, and on its own it won\u0026rsquo;t save you. A better proxy is still a proxy. It still trains your palate toward what\u0026rsquo;s countable. You can build the most balanced scorecard in the industry and still slowly forget what a real strawberry tastes like, because the whole apparatus is pointed at the legible by design.\u003c/p\u003e\n\u003cp\u003eThe fix isn\u0026rsquo;t a cleaner dashboard. It\u0026rsquo;s keeping your palate alive on purpose, against the constant pull of the convenient version.\u003c/p\u003e\n\u003ch2 id=\"what-i-actually-do-now\"\u003eWhat I actually do now\u003c/h2\u003e\n\u003cp\u003eAwareness is most of it, and I want to be honest that I haven\u0026rsquo;t got this solved. But a few things have helped.\u003c/p\u003e\n\u003cp\u003eI write down what I believe before I look at the numbers. Ahead of a review, I jot what I actually think is true about a team. Then I open the dashboard. The gap between the two is the real signal, and it\u0026rsquo;s the one nobody charts. When the numbers and my gut agree, fine. When they disagree, that\u0026rsquo;s the most useful thing I\u0026rsquo;ll learn all week.\u003c/p\u003e\n\u003cp\u003eI name the illegible work out loud. In promotion cases, in calibration, in 1:1s, I force myself to articulate the mentoring, the glue work, and the well-judged no, even though none of it shows up on a board. If I won\u0026rsquo;t say it, the org won\u0026rsquo;t value it, and the people doing it will stop.\u003c/p\u003e\n\u003cp\u003eI treat the clean hit as suspect. This is the habit I took straight from german\u0026rsquo;s piece. When a number gives me a pure, frictionless jolt of satisfaction, I now read that jolt as a warning rather than a reward. Real engineering health is rarely that smooth or that loud. The frictionless hit usually means I\u0026rsquo;m tasting the synthetic version.\u003c/p\u003e\n\u003cp\u003eAnd I make myself eat real strawberries. I read the actual code sometimes. I sit in the actual incident. I talk to the actual customer instead of the summary of the customer. Not to micromanage, but to keep my own palate calibrated, because a leader who only ever consumes the dashboard is the first person in the building to lose the taste.\u003c/p\u003e\n\u003cp\u003eThe synthetic version always wins on cost and convenience. That\u0026rsquo;s the whole problem. So if you want the real thing to survive in your org, you have to protect it on purpose, and you have to start while you can still tell the two apart. That\u0026rsquo;s the part that gets me. The window doesn\u0026rsquo;t slam shut. It closes quietly, one good quarter at a time, and one day you go looking for a real strawberry and there just aren\u0026rsquo;t any left.\u003c/p\u003e\n","date_modified":"2026-06-27T13:15:00Z","date_published":"2026-06-27T13:15:00Z","id":"https://leadership.garden/dopamine-fracking/","summary":"Goodhart's law is only half the story. The real risk in engineering metrics isn't gaming, it's losing the palate to tell good work from the look of it.","tags":["judgment"],"title":"Dopamine Fracking Comes for Your Judgment","url":"https://leadership.garden/dopamine-fracking/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003ch2 id=\"stay-in-the-room\"\u003eStay in the Room\u003c/h2\u003e\n\u003cp\u003eThe first time I had to end someone\u0026rsquo;s job, I rehearsed the sentence in the elevator.\u003c/p\u003e\n\u003cp\u003eThree lines, agreed with HR the day before. Clear, kind, final. I had the words. What I didn\u0026rsquo;t have was any idea what to do with my hands, or where to look when his face changed, or how to walk back to my desk afterward and sit among the people who still had theirs.\u003c/p\u003e\n\u003cp\u003eSo I did the thing. Stared at my screen, clicked around, pretended to work. Left early. It sat with me for months.\u003c/p\u003e\n\u003cp\u003eHere is what that experience did to me, and it\u0026rsquo;s the only reason I\u0026rsquo;m writing this. It made me a much better hiring manager. Not in a vague, inspirational way. Specifically: the next time I was in a room with five people talking themselves into a candidate who was \u0026ldquo;probably fine,\u0026rdquo; I was the one who said no. Because I knew, in my body, what \u0026ldquo;probably fine\u0026rdquo; costs twelve months later.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s the real subject here. Not pain. Proximity to the consequences.\u003c/p\u003e\n\u003ch2 id=\"pain-is-a-proxy\"\u003ePain is a proxy\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a popular version of this argument that I want to take apart before I make my own, because it\u0026rsquo;s half right in a way that\u0026rsquo;s worse than being wrong. The version goes like this: people need to suffer to learn, big companies have made work too soft, real growth comes from feeling the full weight of your mistakes. No pain, no gain.\u003c/p\u003e\n\u003cp\u003eI get the appeal. I\u0026rsquo;ve felt the thing it\u0026rsquo;s pointing at. But \u0026ldquo;you need pain\u0026rdquo; is a sloppy stand-in for something more precise, and the sloppiness gives cover to managers who do real damage in the name of toughness.\u003c/p\u003e\n\u003cp\u003eThe thing that taught me wasn\u0026rsquo;t the suffering. The suffering was incidental. What taught me was the short distance between my decision and its result. I hired carelessly, I had to be the one to undo it, and the loop closed fast enough and close enough that I couldn\u0026rsquo;t look away.\u003c/p\u003e\n\u003cp\u003ePlenty of pain teaches nothing at all. Getting humiliated in front of your peers teaches you to hide. A 60-hour crunch teaches you to resent the people who imposed it. Anxiety just teaches you to avoid. None of that is learning. It\u0026rsquo;s cost with no lesson attached.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eSo here\u0026rsquo;s the precise claim. People learn from proximity to the consequences of their decisions. Pain is sometimes a side effect of that proximity. It is not the active ingredient, and optimizing for it is a mistake.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"blame-and-distance-are-different-dials\"\u003eBlame and distance are different dials\u003c/h2\u003e\n\u003cp\u003eAlmost every conversation our industry has about this collapses onto one axis: blame versus blameless. We argue about whether to name the engineer in the postmortem, whether someone should get fired for the outage, whether psychological safety has made everyone soft.\u003c/p\u003e\n\u003cp\u003eWrong argument. There are two dials here, not one.\u003c/p\u003e\n\u003cp\u003eThe first dial is blame: how much individual fault and punishment we attach to a failure. The second is distance: how far someone sits from the consequences of what they did. We\u0026rsquo;ve welded these together in our heads, as if turning blame down requires turning distance up. It doesn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eYou can run a completely blameless postmortem in which the engineer who shipped the bug is in the room, hears exactly what it did to a real customer, walks through their own reasoning out loud, and owns the follow-up. No fault assigned. Full proximity. That\u0026rsquo;s the good quadrant, and it\u0026rsquo;s available to anyone who wants it.\u003c/p\u003e\n\u003cp\u003eWhat actually happens in a lot of \u0026ldquo;mature\u0026rdquo; orgs is the other thing. We turn blame down and distance up at the same time, then congratulate ourselves on the first and never mention the second. The bug becomes \u0026ldquo;an incident.\u0026rdquo; The incident becomes \u0026ldquo;a learning.\u0026rdquo; The learning becomes a ticket. By the time it\u0026rsquo;s written up it has the emotional texture of a weather report. Nobody got blamed. Nobody got changed either.\u003c/p\u003e\n\u003cp\u003eOpt in to a \u003ca href=\"https://dora.dev/capabilities/generative-organizational-culture/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003egenerative organizational culture\u003c/a\u003e instead.\u003c/p\u003e\n\u003cp\u003e(The original blameless idea, the \u003ca href=\"https://www.etsy.com/codeascraft/blameless-postmortems?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eEtsy\u003c/a\u003e and \u003ca href=\"https://sre.google/sre-book/postmortem-culture/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGoogle SRE\u003c/a\u003e version, never argued for any of this. It said: don\u0026rsquo;t punish people for honest mistakes, because punishment makes them hide the information you need. That part is correct. It said nothing about insulating people from what their mistakes actually did. We added that part ourselves, because it\u0026rsquo;s comfortable.)\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/pain-is-a-proxy/blame-vs-distance-2x2-matrix_hu_f40dafabea25dbe7.png\"\n    srcset=\"/pain-is-a-proxy/blame-vs-distance-2x2-matrix_hu_6e78638afa411fc5.webp 640w, /pain-is-a-proxy/blame-vs-distance-2x2-matrix_hu_f0c98a11a041d57.webp 960w, /pain-is-a-proxy/blame-vs-distance-2x2-matrix_hu_43f226f871336d13.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"A 2x2 grid of blame versus distance from consequences, highlighting \u0026ldquo;Blameless and\"\n    width=\"1200\"\n    height=\"988\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"keep-people-close-to-the-consequences\"\u003eKeep people close to the consequences\u003c/h2\u003e\n\u003cp\u003eIf proximity is the active ingredient, then the manager\u0026rsquo;s job is not to inflict pain and not to remove it. It\u0026rsquo;s to protect the signal. Keep people close to what their decisions do, and clear away the noise that makes them hide.\u003c/p\u003e\n\u003cp\u003eStart with the hard conversation. When you have to tell someone their performance isn\u0026rsquo;t working, or that the behavior in the last standup can\u0026rsquo;t continue, or that their role is gone, be the one in the room. The pull to outsource this is strong and getting stronger. There\u0026rsquo;s an HR partner who will \u0026ldquo;lead the conversation.\u0026rdquo; There\u0026rsquo;s a script. Increasingly there\u0026rsquo;s a video call, which I\u0026rsquo;ve never had to do and hope I never do, because I\u0026rsquo;ve watched enough of them happen to other people to know that talking into a webcam strips out the exact part that teaches you. \u003cem\u003e\u003cstrong\u003eThe discomfort of doing it in person is not a defect to be engineered away. It is the feedback.\u003c/strong\u003e\u003c/em\u003e It\u0026rsquo;s the thing that makes you hire more carefully and give feedback earlier next time. Remove it and you get a manager who keeps making the same hire and feels nothing when it ends.\u003c/p\u003e\n\u003cp\u003eI want to be careful here, because this is where the \u0026ldquo;no pain no gain\u0026rdquo; crowd goes wrong. The goal is not to make these conversations traumatic. It is not to make you good at them through repetition until you go numb. The opposite. The managers I trust most have done this many times and feel it less now, not because they\u0026rsquo;ve hardened, but because they know they did everything they could upstream. They hired well. They gave the hard feedback early, when it could still change something. They didn\u0026rsquo;t let it rot for a year. The proximity made them better, and being better is what eventually lowers the pain. Numbness from avoidance and calm from competence can look identical from the outside. They are not the same thing, and you can usually tell which one you\u0026rsquo;re looking at by checking whether the person did the upstream work.\u003c/p\u003e\n\u003cp\u003eThe same logic runs straight through engineering. \u003cstrong\u003eThe best thing I\u0026rsquo;ve seen for code quality is not a process.\u003c/strong\u003e It\u0026rsquo;s a customer on a call, describing in their own words and their own frustration the weekend they spent cleaning up data because of a bug someone on the team shipped. You cannot get that feeling from a Sentry alert. The phrase \u0026ldquo;some customers were impacted\u0026rdquo; is built, almost perfectly, to protect you from learning anything. Real names, real voices, real fallout. That\u0026rsquo;s what makes a team hold the line on quality past the point where holding it is convenient.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOn-call\u003c/strong\u003e is the cleanest version of this we have, and plenty of orgs quietly defang it. You build it, you carry the pager. When the people writing the code are the people getting paged at 3am by the code, the loop closes on its own. No values poster required. Split those two groups apart, one team shipping and another holding the pager, and you\u0026rsquo;ve built a machine for producing things nobody has to live with.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe last one is about you, not your team\u003c/strong\u003e. When a project starts to wobble, the tempting move is to swoop in and fix it yourself. Feels like leadership. It\u0026rsquo;s actually the surest way to keep your team distant from their own consequences, permanently. They never feel the wobble, so they never learn to steer. I\u0026rsquo;ve done this more than once. It always feels generous in the moment, and it always looks, a year later, like a team that can\u0026rsquo;t operate when I\u0026rsquo;m not in the room.\u003c/p\u003e\n\u003ch2 id=\"the-machinery-of-distance-is-mostly-invisible\"\u003eThe machinery of distance is mostly invisible\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what makes this genuinely hard. Almost none of the distance in a modern org was added on purpose, and almost all of it was added for a good reason.\u003c/p\u003e\n\u003cp\u003eFeature flags are good. They are also a layer between you and the blast radius of a bad change. Staged rollouts are good. They also mean the thing you broke gets caught by a system instead of by a furious email landing in your inbox with your name on it. Blameless culture is good. Done lazily, it becomes a ritual whose actual function is making sure nobody feels anything. Remote work is good for a hundred reasons. It also turns the hardest human moments of the job into something you do through a screen, which is to say, badly.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m not arguing to rip any of this out. That would be its own kind of toughness theater. The point is only to notice that distance accumulates by default, quietly, one reasonable decision at a time, and that it is nobody\u0026rsquo;s job to notice it. So it becomes yours.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhen you find a spot where your team is fully insulated from the results of their own work, that is not a sign of a healthy system. It\u0026rsquo;s a leak in the feedback loop. You should at least know the leak is there.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"one-open-question\"\u003eOne open question\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ll leave this one as a question, because I don\u0026rsquo;t think I have the answer yet.\u003c/p\u003e\n\u003cp\u003eThe biggest distancing machine I have ever watched get installed is the one we\u0026rsquo;re all installing right now. When an engineer writes a function, they own it, and when it breaks they feel the tug of that ownership. When they accept a function an AI wrote, something shifts that I don\u0026rsquo;t think we\u0026rsquo;ve named well. The code passed review. It compiled. It was never really theirs. If proximity to consequences is what turns experience into judgment over a career, what happens to a generation whose relationship to most of their code is approval rather than authorship? Maybe nothing. Maybe judgment routes around it. But I\u0026rsquo;d want every leader rolling this out at speed to at least sit with the question, because the distance is being added the same way it always is: for good reasons, by default, with nobody assigned to watch it.\u003c/p\u003e\n\u003cp\u003eFind the places your people are protected from what they do. Some of that protection is mercy, and you should keep it. Some of it is just \u003ca href=\"https://itrevolution.com/articles/westrums-organizational-model-in-tech-orgs/?ref=leadership.garden\" target=\"_blank\" rel=\"noopener noreferrer\"\u003edistance wearing mercy\u0026rsquo;s clothes\u003c/a\u003e. Learn to tell the two apart, and then stay in the room.\u003c/p\u003e\n","date_modified":"2026-06-20T12:14:00Z","date_published":"2026-06-20T12:14:00Z","id":"https://leadership.garden/pain-is-a-proxy/","summary":"Pain is a side effect, not the active ingredient. Proximity to consequences is what teaches.","tags":["feedback","leadership","growth","learning"],"title":"Pain Is a Proxy","url":"https://leadership.garden/pain-is-a-proxy/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe hard parts of software engineering are still hard. The forcing functions moved. The work did not.\u003c/p\u003e\n\u003cp\u003eI have been trying to make this argument to colleagues for months. Most of the popular framings of the AI shift get it wrong in the same way. They focus on the visible surface changes: a new orchestrator role here, the death of the typing bottleneck over there, prompt engineering as its own specialty alongside the older disciplines, agent-fleet management starting to look like a real job. The underlying work, the part of engineering that distinguishes one practitioner from another, looks the same as it did three years ago. We just used to do most of it for free, by accident, as a side effect of typing.\u003c/p\u003e\n\u003cp\u003eThe \u0026ldquo;we are all orchestrators now\u0026rdquo; framing has something real underneath it, but the framing itself is incomplete in a way that matters. The angle I want to argue is narrower and more useful than \u0026ldquo;your job is now to manage agents.\u0026rdquo; Your job is to recreate, on purpose, the safety pass that typing used to do for you for free.\u003c/p\u003e\n\u003cp\u003eTyping code was doing load-bearing work that nobody invoiced for, an implicit in-line form of design review and quality assurance. We removed it, and most teams haven\u0026rsquo;t realized they still need it.\u003c/p\u003e\n\u003ch2 id=\"the-bottleneck-was-never-typing\"\u003eThe bottleneck was never typing\u003c/h2\u003e\n\u003cp\u003eThis is the uncontroversial part. If you can type 80 words a minute and you ship a few thousand lines on a great week, the math says typing was never the bottleneck. Maybe four hundred lines on a focused day. Out of six hours of deep work, the actual finger-on-keyboard time is small. The rest is something else.\u003c/p\u003e\n\u003cp\u003eMost people would call the something else \u0026ldquo;thinking.\u0026rdquo; That is true but vague. The something else is a stack of activities that happen while you are writing code, that happen \u003cem\u003ebecause\u003c/em\u003e you are writing code, and that you do not do at any other time.\u003c/p\u003e\n\u003cp\u003eYou notice when the shape of the problem is wrong.\u003c/p\u003e\n\u003cp\u003eYou realize the boundary between two modules is in the wrong place because filling in the second module makes the first one\u0026rsquo;s interface look stupid.\u003c/p\u003e\n\u003cp\u003eYou fight with three lines of code for an hour and at the end of the hour you understand that the data model is broken, not the code.\u003c/p\u003e\n\u003cp\u003eYou write a function signature and find that the inputs you thought you needed are wrong. Fixing the upstream call site forces you to fix the type definition, and the type definition surfaces a subtle assumption nobody had written down.\u003c/p\u003e\n\u003cp\u003eYou read the previous engineer\u0026rsquo;s code while you are touching it and fix the bug you spot, the one nobody filed a ticket for.\u003c/p\u003e\n\u003cp\u003eYou write a test and discover, while writing the assertion, that the function you just wrote actually has three exit conditions instead of two, and one of them silently swallows errors.\u003c/p\u003e\n\u003cp\u003eNone of this is typing. But it was happening \u003cem\u003eduring\u003c/em\u003e typing, which is why we never separated the two, and which is why we are mostly surprised now that the work didn\u0026rsquo;t come along when the typing left.\u003c/p\u003e\n\u003cp\u003eThe conventional split for software engineering used to be something like fifty percent writing code, fifty percent testing. That split was already wrong. In my experience watching senior engineers work, the writing is more like five or ten percent of the actual time spent, and the rest is the noticing. The noticing is what we are losing.\u003c/p\u003e\n\u003ch2 id=\"slowness-was-load-bearing\"\u003eSlowness was load-bearing\u003c/h2\u003e\n\u003cp\u003eThe slowness of writing code was doing a kind of work we never named. It forced you to think carefully about each line, and when the slowness left, the thinking left with it.\u003c/p\u003e\n\u003cp\u003eTake a concrete comparison. In the old workflow, you sat down to write a small data model. Halfway through, you realized one field needed to be a discriminated union instead of an optional. You changed it. You moved on. The change cost you maybe ninety seconds of thinking and two lines of code. Nobody filed a ticket. Nobody wrote a design doc. The fix happened because you were the one writing the code and you noticed.\u003c/p\u003e\n\u003cp\u003eIn the new workflow, you write a prompt that produces the data model. The model uses an optional. You scan the output, think \u0026ldquo;looks fine,\u0026rdquo; and move to the next thing. The bug ships. Or, worse, the model passes through a code review where the reviewer is also scanning at the same level of attention, because the volume of agent output has made deep review economically impossible. Two weeks later somebody hits a state the optional can\u0026rsquo;t represent. Now you are debugging it as a runtime issue instead of catching it as a design issue.\u003c/p\u003e\n\u003cp\u003eSame bug, both workflows. The difference is when it surfaced. The old way caught it during writing, at the cheapest possible point in its lifecycle. The new way catches it in production, under load, with state already in the wrong shape on disk.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eSlowness was a free QA pass we ran on every line of code, paid for in our time. We never called it QA because it looked like writing.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"we-have-always-done-stochastic-engineering\"\u003eWe have always done stochastic engineering\u003c/h2\u003e\n\u003cp\u003eOne of the recurring complaints about agent-driven coding is that it makes software engineering stochastic. The same prompt produces different code on different days. You don\u0026rsquo;t know what you\u0026rsquo;re going to get.\u003c/p\u003e\n\u003cp\u003eThat complaint is fine as far as it goes, but the framing is wrong. Software engineering, at any scale that matters, has always been stochastic. If you have ever run a project with three interns, or staffed a team mostly with new grads, you know this. You can write the most lovingly detailed ticket in the world, attach the cleanest mock, link the right design doc, and the code you get back will surprise you. Not because the engineer is bad. The engineer is fine. They just don\u0026rsquo;t have your model of the system in their head. Their version of \u0026ldquo;the right answer\u0026rdquo; is shaped by their experience, which is not yours. So you get something close to what you asked for, with a few decisions you wouldn\u0026rsquo;t have made, and you correct course in review.\u003c/p\u003e\n\u003cp\u003eThis is not a degraded form of engineering. It is engineering. The way real systems get built at scale is by senior engineers specifying constraints, defining interfaces, owning the architecture, and accepting that the people filling in the boxes will sometimes color outside the lines. Code review exists for this reason. Type systems exist for this reason. Integration tests exist for this reason. The whole apparatus of professional software engineering, the part of it that isn\u0026rsquo;t about typing, is a response to the stochastic nature of code produced by humans of varying experience working on the same system.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhen you accept that engineering has always been stochastic, the agents stop looking like a category change. They look like a new kind of contributor. The contributor is faster and cheaper than a human, and more willing to commit to a bad decision and stay committed to it.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThe job of the senior engineer is the same as it was. You specify constraints. You define interfaces. You own architecture. You run code review. What changed is the contributor on the other side of the contract.\u003c/p\u003e\n\u003ch2 id=\"the-shape-an-agent-reaches-for-when-nobody-is-watching\"\u003eThe shape an agent reaches for when nobody is watching\u003c/h2\u003e\n\u003cp\u003eHere is the failure mode that does not show up in most of the writing on this topic. The cost of doing the wrong thing for ten thousand more lines is the same, for an agent, as the cost of doing the right thing for ten thousand lines. The agent doesn\u0026rsquo;t feel the difference. The human used to.\u003c/p\u003e\n\u003cp\u003eWhat this means in practice is that agents will commit to architecturally absurd decisions and stay committed to them. The failure mode is real, even if it does not show up every time, and once you start seeing it you can\u0026rsquo;t unsee it. I have watched agents pile every entity in a domain into one giant union type because that was the shape that satisfied the first few test cases. I have watched them build a manifest-of-manifests-of-manifests structure for a problem that wanted a flat list. I have watched them invent a parallel identifier scheme to track relationships the database was already tracking, then stack thirty features on top of that scheme before anyone noticed. A human engineer would not write any of these things, because the slowness of typing the wrong shape would have made the human stop, look around, and notice. The agent had no such forcing function. It produced text at a speed where the wrongness of the shape never became expensive enough to interrupt the production of more text.\u003c/p\u003e\n\u003cp\u003eI think about this every time I open a pull request from someone who has been heavily relying on an agent. The code is often fine at the line level. The bugs worth catching live one floor up. A data model with one too many concepts. A service boundary in the wrong place. An enum that swallows half its cases without comment, or an identifier scheme that conflates three different things into one type. The bugs that survived to PR did so because they happened at a level the human reviewer was no longer being forced to think about.\u003c/p\u003e\n\u003cp\u003eThis is the same pattern I wrote about in \u003ca href=\"https://leadership.garden/ai-didnt-break-prs/\"\u003eNo, AI didn\u0026rsquo;t break PRs\u003c/a\u003e. \u003ca href=\"https://leadership.garden/ai-is-an-amplifier/\"\u003eAI did not invent these failure modes. It amplified them\u003c/a\u003e and the speed at which they reach you.\u003c/p\u003e\n\u003ch2 id=\"the-qa-was-hidden-in-the-writing\"\u003eThe QA was hidden in the writing\u003c/h2\u003e\n\u003cp\u003eI am not the first person to notice that \u0026ldquo;writing code\u0026rdquo; was doing more than producing characters. Rubber-duck debugging is the cleanest version of the same idea. You talk through code to a rubber duck and the bug surfaces, not because the duck contributes anything but because the act of articulating the problem to something outside your head forces you to model the system carefully. Pair programming and design docs are doing related work. We have always sort of known that the medium of typing forced a kind of slow, careful thought we couldn\u0026rsquo;t get any other way. We just never had to defend the practice, because the alternative wasn\u0026rsquo;t available.\u003c/p\u003e\n\u003cp\u003eNow the alternative is available, and the defense matters.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe QA that used to live in typing has to live somewhere now. If you don\u0026rsquo;t put it somewhere, you don\u0026rsquo;t have it.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThis is the \u003ca href=\"https://leadership.garden/verification-debt/\"\u003everification debt\u003c/a\u003e I\u0026rsquo;ve written about before, viewed from a different angle. Most teams are discovering it in production, six months after they handed coding to agents, when they start tripping over architectural decisions nobody remembers making.\u003c/p\u003e\n\u003cp\u003eIn my experience, this work goes into a small number of artifacts and rituals that you have to be willing to do by hand. I have come around to a set of practices that look, from the outside, like the kind of work a tech lead does. The naming convention \u0026ldquo;everyone is a tech lead now\u0026rdquo; is fine. The more useful framing is that the forcing functions that used to be implicit have to be made explicit, and the explicit version is more work in some ways and less work in others.\u003c/p\u003e\n\u003cp\u003eHere is what I have landed on, partly through my own work and partly through watching engineers I respect figure out their own version of the same thing.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWrite your schemas by hand\u003c/strong\u003e, every one of them. If it lives at a system boundary and other people will rely on its shape, you should be the one typing it. This applies to database schemas, but also to protobuf definitions, OpenAPI specs, and GraphQL types. Even small schemas. I have spent days on schemas only a few hundred lines long, because the schema needed to be correct in a load-bearing way and I refused to let the agent touch it. Agents can write schemas. That is not the issue. The issue is that you want the slow QA to happen at the schema level, because every downstream bug worth debugging at 2 AM is traceable to a wrong shape in a load-bearing place. Get the schema right and you have fenced off the territory where the worst bugs live.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWrite your interface and API contracts by hand\u003c/strong\u003e, for the same reason. Function signatures and request shapes. Error types, retry semantics, and idempotency guarantees on top of that. These are the artifacts that constrain everything downstream. If the contract is wrong, the implementation can be perfect and the system will still be broken.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eWrite the tests in a separate context from the implementation\u003c/strong\u003e. This one is non-obvious. If you ask an agent to write code and then ask the same agent to write tests for the code, the agent has the code in its context, and the tests will reify whatever the code already does. What you get is a hypothesis-free assertion of current behavior dressed up to look like coverage. So write the tests in a fresh session, against the API contract you have already pinned down. Then let an agent fill in the implementation against the tests. If the agent tries to modify the tests, push back hard. The tests are the contract for what the implementation has to do, and the moment the implementation is allowed to rewrite the contract you have lost the whole point.\u003c/p\u003e\n\u003cp\u003eThe full pattern, in shorthand, is this. Schemas by hand. Interfaces by hand. Tests in isolation. Implementation by agent. Real correctness checks at the system boundary, not at the line level. The work that used to happen during typing now happens in a small number of artifacts that constrain everything downstream.\u003c/p\u003e\n\u003cp\u003eSome engineers go further and write all their tests by hand. They are probably right. Tests written by a careful human catch the bugs that tests written by an agent ratify. I find writing tests by hand miserable, so I split the difference and write them in an isolated context. The point is that \u003cem\u003esomewhere\u003c/em\u003e, a human has to do the slow careful thinking, and the schemas-and-interfaces-and-tests triangle is where most engineers I trust have landed.\u003c/p\u003e\n\u003ch2 id=\"the-shallow-systems-are-not-safer\"\u003eThe shallow systems are not safer\u003c/h2\u003e\n\u003cp\u003eIt is tempting to read everything I have written so far as \u0026ldquo;this only applies to deep systems like databases and infra.\u0026rdquo; A common version of the argument from people who think the agent revolution is mostly fine goes: the failure modes only matter in narrow, deep systems with high implementation complexity. Broad shallow apps, where each feature has limited blast radius on the rest of the architecture, are different.\u003c/p\u003e\n\u003cp\u003eI want to push back on this, because the assumption that shallow systems are safer hasn\u0026rsquo;t matched what I see when I review code. If anything, shallow systems are where this pattern is most insidious, because each individual mistake looks too small to be worth fixing.\u003c/p\u003e\n\u003cp\u003eI review code for friends building side projects. Practice trackers, recipe apps, personal finance dashboards, the small weekend kind of thing where the domain is familiar and the surface area is modest. What I see, in repo after repo, is the same shape of drift. The first few features are clean, because the human cared. By feature ten, the agent has introduced a parallel identifier system that shadows the one the database already provides. By feature twenty, the validation logic exists in three places, each subtly different. By feature thirty, the data model has accumulated enough redundancy that some operations work and others crash, depending on whether two redundant fields happen to be in sync.\u003c/p\u003e\n\u003cp\u003eNone of this gets caught in code review, because each individual diff looks fine. The drift is cumulative. The human is waving things through, one ugly choice at a time, and after thirty waves the system is unrecoverable.\u003c/p\u003e\n\u003cp\u003eThe lesson is that shallowness of feature surface is not the same as shallowness of data model. The data model is always deep, even in a small app. And the data model is exactly the thing that gets mangled when you stop doing the slow QA pass on every piece of code that touches it. Watch your data models. Hand-roll them. Don\u0026rsquo;t let the agent touch them. This advice holds whether you are building a database or a hobby app, and it holds harder for the small projects, because nobody is watching small projects closely enough to catch the drift.\u003c/p\u003e\n\u003ch2 id=\"how-the-noticing-gets-learned\"\u003eHow the noticing gets learned\u003c/h2\u003e\n\u003cp\u003eThe honest question I get whenever I talk about any of this, usually from someone in their first or second job, is some version of: how is anyone supposed to learn it? The senior engineers in this conversation grew up typing. The noticing got built into their hands across years of unforgiving practice. If the typing has been outsourced to an agent, and the noticing was a side effect of typing, what does an engineer with three years of experience do? What does an engineer with zero years of experience do? This is, in a real way, \u003ca href=\"https://leadership.garden/the-senior-engineer-crisis/\"\u003ethe senior engineer crisis arriving early\u003c/a\u003e and from an angle nobody planned for.\u003c/p\u003e\n\u003cp\u003eMy answer is partial. Here it is.\u003c/p\u003e\n\u003cp\u003eThe first part is that the noticing can still be practiced directly. The way is the way I described above. Write the schema by hand. Write the interface by hand. Write the tests by hand or in a fresh context. Read what the agent produces and check the data model against the cases it has to support. Sit with the ugliness of a thing that looks like it works and ask whether it could be wrong. None of these require six years of typing experience. They require attention. The skill is the skill of \u003cem\u003enot waving things through\u003c/em\u003e, of being willing to slow down at the artifacts that matter even when the agent is offering to skip them.\u003c/p\u003e\n\u003cp\u003eThe second part is that we should be honest about what is lost. Some of the noticing came from spending years filling in code, day after day, and seeing the shapes of the bugs that recur. An engineer who has hand-written ten implementations of a key-value store knows in their bones that one-key implementations don\u0026rsquo;t work. An engineer who has only read agent output of key-value stores might not. We need to find ways to give people this grounding without the slow apprenticeship of typing, and I don\u0026rsquo;t think any of us has worked out a complete answer. Reading code carefully helps. Postmortems help. Putting people on call early helps. Asking junior engineers to design the schema before any code is generated helps. None of these on their own replace the kind of accumulated pattern-matching that years of typing produced.\u003c/p\u003e\n\u003cp\u003eWhat I am confident about is this. The temptation for less experienced engineers will be to lean harder on the agent because the agent is faster than they are. The agent is faster at producing characters, not at being right. If you outsource the noticing, you get further from the answer in less time. The engineers I have watched grow the most over the last year are the ones who use agents heavily but who refuse to outsource the parts of the work that look load-bearing, even when it would be cheaper in the short term to do so. They write their schemas. They review their own code before anyone else does. They stay in the loop on the architecture even when they could ask the model to draft it for them. It is more work, and it is also the only way I know to build the kind of judgment the work requires.\u003c/p\u003e\n\u003ch2 id=\"what-changed-is-the-price-of-one-input\"\u003eWhat changed is the price of one input\u003c/h2\u003e\n\u003cp\u003eWhat is changing is not the difficulty of software engineering. What is changing is the price of one specific input. Code production used to be expensive, and most of what we did as engineers was structured around that constraint. We wrote design docs because writing code to validate a design was costly. We did code review because writing buggy code was costly. We had architects because rewriting a system was costly.\u003c/p\u003e\n\u003cp\u003eNow code production is cheap. The other costs haven\u0026rsquo;t moved at all. Designing the right data model still takes the same amount of careful thought it always did. Defining the right interface still requires the same number of arguments in a conference room. Knowing what to test for still requires you to have models of the system in your head. Operating the system in production is, if anything, more expensive than it used to be, because the systems are more complicated and the cost of getting paged at 3 AM has not dropped. The bottleneck has moved from where the code is produced to everywhere the code is produced \u003cem\u003etoward\u003c/em\u003e: the shape of the answer, the contract of the interface, the test that proves it works.\u003c/p\u003e\n\u003cp\u003eWhich means the job has not changed. The interesting part of the job, the part that distinguished a senior engineer from a junior one, was never the typing. It was the noticing. It was the catching the wrong shape in the wrong place at the wrong time. We got that for free, mixed in with the typing, and we never had to name it.\u003c/p\u003e\n\u003cp\u003eNow we have to name it. We have to put it somewhere. We have to do it on purpose.\u003c/p\u003e\n\u003cp\u003eIf you take one thing from this, take this. The engineers who will look like wizards over the next two years are not the ones who prompt best. They are the ones who notice that typing was doing real work, who can recreate that work in artifacts the team can see, and who will hand-roll a schema or an interface even when the agent is right there offering to do it faster. The discipline has to come from somewhere. If you don\u0026rsquo;t build it in deliberately, the system doesn\u0026rsquo;t have it.\u003c/p\u003e\n\u003cp\u003eI have started insisting on this on every project I touch, including the small ones, including the ones where it feels like overkill. It is more work in some ways. It is less work in others, because the bugs that used to be caught in implementation now get caught at design, where they cost almost nothing. The trade is worth it. The work is mostly the same as it ever was. We just have to do it on purpose now.\u003c/p\u003e\n\u003cp\u003eCode is cheap. Being right is what is expensive, and that has always been the job.\u003c/p\u003e\n","date_modified":"2026-06-13T00:00:00Z","date_published":"2026-06-13T00:00:00Z","id":"https://leadership.garden/typing-was-the-safety-harness/","summary":"Typing code was doing load-bearing QA work nobody invoiced for. Agents removed the slowness, and now the work has to live somewhere on purpose.","tags":["ai","engineering","quality"],"title":"The Typing Was the Safety Harness","url":"https://leadership.garden/typing-was-the-safety-harness/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eI once sat through a quarterly review where engineering looked, on paper, excellent.\u003c/p\u003e\n\u003cp\u003eCycle time was down. PRs were moving. The team had closed more tickets than the previous quarter, with no massaging of numbers. The dashboard looked better than it had in a year.\u003c/p\u003e\n\u003cp\u003eThen the product lead asked what had changed for customers.\u003c/p\u003e\n\u003cp\u003eThe answer was embarrassingly thin. A few fixes. A few features in partial rollout. A dashboard cleanup nobody outside the company would ever notice. The team had been moving faster, and I had let myself feel good about it, because the alternative was admitting that a lot of energy had turned into little progress.\u003c/p\u003e\n\u003cp\u003eI have been suspicious of speed ever since.\u003c/p\u003e\n\u003cp\u003eSpeed is seductive because it is visible. Managers get something to point at. Executives get a line for the update. Teams get the relief of feeling that the system is working.\u003c/p\u003e\n\u003cp\u003eSometimes the system is working. More often, it is only moving.\u003c/p\u003e\n\u003ch2 id=\"the-number-was-true\"\u003eThe number was true\u003c/h2\u003e\n\u003cp\u003eThe annoying thing about bad productivity measures is that they are often accurate.\u003c/p\u003e\n\u003cp\u003eThe team did merge more pull requests, move tickets faster, shrink the review queue, and tune the deployment pipeline. I am not interested in pretending those things do not matter.\u003c/p\u003e\n\u003cp\u003eThey matter. They do not settle the question.\u003c/p\u003e\n\u003cp\u003eIf the checkout flow gets slower, if support volume goes up, if the codebase becomes harder to change, if engineers spend the next two months cleaning up decisions nobody remembers making, then the speed was only one part of the story. Maybe the trade was deliberate. Maybe it was still worth it. But you cannot call that productivity just because the middle of the process got faster.\u003c/p\u003e\n\u003cp\u003eThis is why I still respect the \u003ca href=\"https://queue.acm.org/detail.cfm?id=3454124\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSPACE framework\u003c/a\u003e, even though frameworks usually make me itchy. It refuses to collapse developer productivity into one number. It puts activity next to performance, satisfaction, collaboration, and flow. That is the part people skip. They take the easiest column to instrument and let it stand in for the whole thing.\u003c/p\u003e\n\u003cp\u003eActivity is comforting because it looks like evidence. It only proves that activity happened.\u003c/p\u003e\n\u003ch2 id=\"the-local-optimum-problem\"\u003eThe local optimum problem\u003c/h2\u003e\n\u003cp\u003eMost speed improvements are local.\u003c/p\u003e\n\u003cp\u003eCode generation gets faster. Reviews get faster. Builds get faster. Deployments get faster. Each improvement can help. I have spent a lot of time pushing on exactly those things.\u003c/p\u003e\n\u003cp\u003eLocal speed has a habit of dumping work somewhere else.\u003c/p\u003e\n\u003cp\u003eA team shortens implementation time and finds review has become the bottleneck. It shortens review time and finds QA cannot keep up. It automates QA and discovers nobody knows whether the feature solved the original problem. Each layer celebrates its own improvement while the work waits somewhere else.\u003c/p\u003e\n\u003cp\u003eThe first time I learned this properly was not from a book. It was from watching a team keep everyone busy and still miss every meaningful date. Each person had a plausible explanation. Design was waiting for product. Backend was waiting for architecture. Frontend was waiting for API shape. QA was waiting for anything stable enough to test. Nobody was idle. Nothing was flowing.\u003c/p\u003e\n\u003cp\u003eThat is what most managers get wrong about productivity. They look for idle people. They should look for idle work.\u003c/p\u003e\n\u003cp\u003eThe work is what matters. Find where it waits and who has to touch it next. Find the missing decision, the reopened ticket, the blocked handoff, the gap between \u0026ldquo;done enough\u0026rdquo; and \u0026ldquo;actually useful.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThose checks are less pleasant than \u0026ldquo;how fast are we moving?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThey are also harder to game.\u003c/p\u003e\n\u003ch2 id=\"ai-made-the-old-mistake-cheaper\"\u003eAI made the old mistake cheaper\u003c/h2\u003e\n\u003cp\u003eAI has made this conversation more urgent. I do not think it changed the underlying mistake.\u003c/p\u003e\n\u003cp\u003eWe already confused output with progress. AI just made output cheaper.\u003c/p\u003e\n\u003cp\u003eIf your organization believes productivity means \u0026ldquo;more implementation in less time,\u0026rdquo; then AI looks like an easy win. I use these tools and would not go back. They are useful for scaffolding, exploration, test drafts, annoying transformations, and all the small bits of work that used to consume attention without deserving much of it.\u003c/p\u003e\n\u003cp\u003eI do not trust any productivity claim that stops at generation speed.\u003c/p\u003e\n\u003cp\u003eGoogle\u0026rsquo;s \u003ca href=\"https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e2025 DORA report\u003c/a\u003e has the tension I care about. AI adoption is widespread. Most respondents say it improves their productivity. DORA also says the benefit depends heavily on workflow clarity, internal platforms, fast feedback, and team alignment, while reporting a negative relationship with delivery stability.\u003c/p\u003e\n\u003cp\u003eThat sounds right to me.\u003c/p\u003e\n\u003cp\u003eAI helps more when the surrounding system is already good. When the surrounding system is sloppy, it creates more material for the sloppy system to process.\u003c/p\u003e\n\u003cp\u003eI do not read \u003ca href=\"https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eMETR\u0026rsquo;s early-2025 study\u003c/a\u003e as \u0026ldquo;AI makes developers slower.\u0026rdquo; That would be too easy, and probably wrong as the tools improve. I take a narrower lesson from it. Experienced developers working in familiar, mature repositories lost time to prompting, waiting, reviewing, and cleaning up generated work. METR later \u003ca href=\"https://metr.org/blog/2026-02-24-uplift-update/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003echanged its experiment design\u003c/a\u003e because measuring task-level productivity had itself become messy.\u003c/p\u003e\n\u003cp\u003eThat revision feels like progress. The work is messy.\u003c/p\u003e\n\u003cp\u003eIf an AI tool saves three hours of typing and creates five hours of review, debugging, and second-guessing, the typing number is still true. It is also irrelevant by itself.\u003c/p\u003e\n\u003ch2 id=\"where-the-time-went\"\u003eWhere the time went\u003c/h2\u003e\n\u003cp\u003eWhen a team tells me they are fast but frustrated, I look at the edges of the work. The visible part (code written, PRs reviewed, deployments through CI) is rarely the whole problem. The expensive time is quieter.\u003c/p\u003e\n\u003cp\u003eIt lives in the two days before implementation when nobody has forced the product question. It lives in the Slack thread where three senior people nearly agree and still leave the decision unresolved. After release, it shows up when support learns the new behavior before the team does. Months later, it shows up in the rewrite that happens because the original work was correct against the ticket and wrong against the user.\u003c/p\u003e\n\u003cp\u003eI have made this mistake as a manager. More than once.\u003c/p\u003e\n\u003cp\u003eI pushed a team to make the visible part faster because the visible part was where I felt I had control. The real delay was upstream, in decision quality. We were feeding unclear work into a better machine and then acting surprised when the machine produced clearer versions of the wrong thing.\u003c/p\u003e\n\u003cp\u003eThis is why DORA\u0026rsquo;s own \u003ca href=\"https://dora.dev/guides/dora-metrics/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003esoftware delivery metrics\u003c/a\u003e pair throughput with instability. Deployment frequency and change lead time are useful only when read alongside failure, rework, and recovery. Speed without that counterweight flatters you. It should not.\u003c/p\u003e\n\u003ch2 id=\"the-dashboard-i-want-to-see\"\u003eThe dashboard I want to see\u003c/h2\u003e\n\u003cp\u003eI do not want fewer metrics. I want less self-deception.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://queue.acm.org/detail.cfm?id=3595878\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDevEx research\u003c/a\u003e is useful here because it talks about feedback loops, cognitive load, and flow state. Those words sound soft until you watch a team lose a week to a test suite nobody trusts or a service boundary nobody understands. Then they stop sounding soft.\u003c/p\u003e\n\u003cp\u003eA good dashboard should make the real delays harder to hide.\u003c/p\u003e\n\u003cp\u003eShow me how long work sits after it is \u0026ldquo;done\u0026rdquo; but before anyone can use it. Show me how much rework came from unclear intent. Tell me which active projects have no named decision-maker, how often a shipped feature gets changed after evidence arrives, and which handoffs keep stopping the same kind of work.\u003c/p\u003e\n\u003cp\u003eNone of those numbers is perfect. Some are barely numbers.\u003c/p\u003e\n\u003cp\u003eThat is fine. The point is to start a better conversation.\u003c/p\u003e\n\u003cp\u003eAfter a project lands, I like asking what got easier.\u003c/p\u003e\n\u003cp\u003eIf nothing got easier, be careful.\u003c/p\u003e\n\u003cp\u003eThe work may still have been necessary. Compliance work often looks like that. Some migrations are mostly defensive. Some reliability work prevents pain instead of creating delight. Fine. Say that plainly. Be honest about the kind of value you produced.\u003c/p\u003e\n\u003cp\u003eBut if every project ships and nothing gets easier for users, operators, support, future engineers, or future decisions, you are not looking at productivity. You are looking at organizational digestion.\u003c/p\u003e\n\u003cp\u003eThe team is consuming work and producing artifacts.\u003c/p\u003e\n\u003cp\u003eThat is not the same as progress.\u003c/p\u003e\n\u003ch2 id=\"what-i-would-change-as-a-leader\"\u003eWhat I would change as a leader\u003c/h2\u003e\n\u003cp\u003eI would start smaller than most productivity programs start.\u003c/p\u003e\n\u003cp\u003eI would stop asking teams to explain why they are not faster until I had a better answer for why the current work matters. This alone would improve many organizations. Half the pressure to move faster is discomfort with unclear priorities wearing a delivery costume.\u003c/p\u003e\n\u003cp\u003eI would make active work painfully visible. Not a beautiful portfolio dashboard. A plain list that a director can read and feel slightly embarrassed by. Too many teams carry work because nobody wants the social cost of stopping it.\u003c/p\u003e\n\u003cp\u003eI would ask for a real outcome review after delivery. No ceremony, no slide deck. The people who sponsored, built, supported, and operated the thing, looking at what actually happened. Did it help? What did it break? Did users care? What would you stop doing if you believed the evidence?\u003c/p\u003e\n\u003cp\u003eI would treat deletion as delivery. Removing a confusing feature, killing a stale project, simplifying a workflow, deleting code nobody understands. These are productivity moves. They rarely look like speed because the artifact gets smaller.\u003c/p\u003e\n\u003cp\u003eI would watch senior engineers for signs that speed is being bought with their attention. This is one of the more common hidden costs now. A team appears faster because the strongest engineers are silently absorbing more review, more cleanup, more architectural correction, more \u0026ldquo;quick question\u0026rdquo; interrupts. The dashboard says throughput improved. The senior engineer\u0026rsquo;s calendar says otherwise.\u003c/p\u003e\n\u003cp\u003eYou can run a team that way for a while. The cost eventually shows up in attrition, brittle architecture, or a senior engineer who suddenly has no patience left.\u003c/p\u003e\n\u003ch2 id=\"what-to-say-out-loud\"\u003eWhat to say out loud\u003c/h2\u003e\n\u003cp\u003eThere is a sentence I wish more leaders would say in public:\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;We are moving faster. I do not know yet whether we are more productive.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat sentence creates the right kind of discomfort.\u003c/p\u003e\n\u003cp\u003eIt respects the work that happened while keeping the standard honest. The team is not being insulted. The leader is refusing to confuse motion with value.\u003c/p\u003e\n\u003cp\u003eMost engineering teams are not full of people avoiding work. They are full of people spending too much effort on work that entered the system too casually, waited in the wrong places, or never got checked against reality after it shipped.\u003c/p\u003e\n\u003cp\u003eTelling that team to go faster is lazy management.\u003c/p\u003e\n\u003cp\u003eThe harder job is making more of the effort count. Clearer intent before work starts. Smaller batches. Faster feedback. Less work in progress. Better tests. A little more willingness to stop work that no longer deserves the team\u0026rsquo;s attention.\u003c/p\u003e\n\u003cp\u003eNone of this is new. That is part of why it is annoying.\u003c/p\u003e\n\u003cp\u003eProductivity is not speed. It is what remains after the movement has been tested against something real.\u003c/p\u003e\n","date_modified":"2026-06-06T00:00:00Z","date_published":"2026-06-06T00:00:00Z","id":"https://leadership.garden/productivity-is-not-speed/","summary":"A fast engineering team is not automatically a productive one. The real test is whether the work changes anything that matters.","tags":["productivity","leadership","engineering","process"],"title":"Productivity Is Not Speed","url":"https://leadership.garden/productivity-is-not-speed/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe debrief was going sideways.\u003c/p\u003e\n\u003cp\u003eFive interviewers had spent four hours that day with the same Senior Engineer candidate. Now we were sitting around a meeting room arguing about whether to make the offer, and nobody had a single useful piece of paper between them.\u003c/p\u003e\n\u003cp\u003eTwo said yes. They liked her. She was sharp, the conversation flowed, she \u0026ldquo;got it.\u0026rdquo; Two said no, with a vague unease about the depth of her answers. The fifth interviewer was quietly trying to remember which moments had been with this candidate and which had been with someone he had interviewed two days earlier.\u003c/p\u003e\n\u003cp\u003eI asked what each of them had seen, specifically, that pointed at the level we were hiring for. The room went quiet in the particular way rooms go quiet when everyone realises they have been working from impressions and hoping the impressions would line up.\u003c/p\u003e\n\u003cp\u003eI have run that meeting more times than I would like. So have you, probably.\u003c/p\u003e\n\u003cp\u003eThis post is about why that meeting keeps happening, even at companies that have done the work of writing a serious career framework. It is for hiring managers, senior interviewers, and anyone who has ever sat in a debrief and realised that \u0026ldquo;she seemed strong\u0026rdquo; was the strongest argument anyone in the room could muster.\u003c/p\u003e\n\u003cp\u003eThere are two layers to the problem. Most posts about interviewing fix one and ignore the other. You need both.\u003c/p\u003e\n\u003ch2 id=\"the-wrong-layer-of-detail\"\u003eThe wrong layer of detail\u003c/h2\u003e\n\u003cp\u003eBy the time a company reaches any meaningful size, it has a career framework. There are rows for each level: Junior, Mid, Senior, Staff, Principal. There are columns: Technical Skills, Scope, Communication, Impact, Ownership. Inside each cell there is a sentence.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Works independently on complex tasks.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Drives improvement in team processes and tools.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Influences technical direction across multiple teams.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThese sentences are correct. They are also useless to the person trying to design an interview around them.\u003c/p\u003e\n\u003cp\u003eThe framework is written for the wrong audience. It is written for promotion committees, performance review calibration, and HR systems. It describes outcomes you can measure if you have already worked with someone for two years. It does not describe behaviours you can observe in 45 minutes with someone you have never met.\u003c/p\u003e\n\u003cp\u003eA framework tells you \u003cem\u003ewhat\u003c/em\u003e a Senior Engineer should be capable of. It is silent on \u003cem\u003ehow\u003c/em\u003e to find out whether the person sitting across from you actually is one.\u003c/p\u003e\n\u003cp\u003eThis is the first half of the problem. Even good interviewers, given a vague level descriptor, will drift towards their own internal model of seniority. Their model is mostly an averaged memory of the last three Senior Engineers they liked. Two of them ask about system design because that is what the last good Senior was good at. Another asks behavioural questions because that is where the last bad Senior failed. None of them are testing the framework. They are testing their personal heuristic.\u003c/p\u003e\n\u003cp\u003eThe result, predictably, is that whether someone gets hired at level depends mostly on which of your interviewers happen to be on the schedule that day.\u003c/p\u003e\n\u003ch2 id=\"from-statement-to-behaviour-to-question\"\u003eFrom statement to behaviour to question\u003c/h2\u003e\n\u003cp\u003eThe fix for this half of the problem is a translation step that almost no company does explicitly.\u003c/p\u003e\n\u003cp\u003eI picked up a version of this from a recruiter I worked with years ago. I have since seen it reposted under various names in slide decks, but the method is the same and it is dead simple.\u003c/p\u003e\n\u003cp\u003eThree steps:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003ePick one statement from the framework at the level you are hiring for.\u003c/li\u003e\n\u003cli\u003eAsk: what does that look like as observable behaviour, in daily work, for this specific role?\u003c/li\u003e\n\u003cli\u003eWrite a question that surfaces that behaviour.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eSounds obvious. Almost nobody actually does it.\u003c/p\u003e\n\u003cp\u003eTake the Senior Engineer line: \u0026ldquo;Drives improvement in team processes and tools.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eStep two forces you to get concrete. What does \u0026ldquo;driving improvement\u0026rdquo; actually look like in the wild for someone on a backend platform team? It might look like this. Someone notices a deployment is taking longer than it should. They do not file a ticket and forget about it. They dig into why. They write up a one-page proposal. They get the team to try it in a sprint. They measure the difference. They share what they learned.\u003c/p\u003e\n\u003cp\u003eThat is observable. You can ask about it.\u003c/p\u003e\n\u003cp\u003eStep three is then almost mechanical. \u0026ldquo;Tell me about a piece of work you did that changed how your team or another team operates. How did that come about?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eNotice what the question does. It is open enough that the candidate has room to tell their actual story. It is specific enough that they cannot just answer with a hypothetical or a slogan. And it directly probes the behaviour the framework cell is trying to capture.\u003c/p\u003e\n\u003cp\u003eCompare it with the question most interviewers actually ask, which is some variant of: \u0026ldquo;Tell me about a time you showed leadership.\u0026rdquo; Sure. The candidate will produce a story. The story might be about leadership. It might be about being on a team where someone else showed leadership. It might be a project they slightly oversold. You will not know which, because the question never asked the framework question in the first place.\u003c/p\u003e\n\u003cp\u003eYou can do this exercise for every cell in your framework that matters for the role. It is tedious work. It pays for itself the first time you have a calibrated debrief.\u003c/p\u003e\n\u003ch2 id=\"impressions-are-not-evidence\"\u003eImpressions are not evidence\u003c/h2\u003e\n\u003cp\u003eSolving the first half only gets you so far.\u003c/p\u003e\n\u003cp\u003eEven if every interviewer walked into the room with the right questions tied to the right framework cells, most debriefs would still be a mess. The questions are only half of it. The other half is what the interviewer brings out of the room.\u003c/p\u003e\n\u003cp\u003eI think this is where most interview discourse gets stuck. We argue about question types, about whether take-homes are fair, about whether system design is a good filter. (I have written my own version of that argument in \u003ca href=\"https://leadership.garden/dump-leetcode-interviews/\"\u003eWhy I Dumped LeetCode Interviews\u003c/a\u003e, so I am not innocent.) We almost never argue about how interviewers \u003cem\u003erecord\u003c/em\u003e what they hear. And that is where the wheels come off.\u003c/p\u003e\n\u003cp\u003eHere is the test. Pick up your last three interview write-ups. How much of what is on the page is something the candidate actually did or said? How much of it is your interpretation of what they did or said?\u003c/p\u003e\n\u003cp\u003eIn my experience, even thoughtful interviewers come back with notes that are 80% interpretation and 20% direct observation. Sentences like:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u0026ldquo;She seemed nervous in the system design round.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u0026ldquo;He really knew his stuff on Postgres.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u0026ldquo;They had a strong opinion on testing.\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNone of these are evidence. They are summaries of impressions. A different interviewer in the same room might write the opposite sentence and be just as confident in it.\u003c/p\u003e\n\u003cp\u003eI came across a post by Dan North a while back called \u003ca href=\"https://dannorth.net/blog/interviewing-for-evidence/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eInterviewing for Evidence\u003c/a\u003e. It is the cleanest articulation I have seen of how to fix this side of the problem, and I have been quietly stealing from it ever since.\u003c/p\u003e\n\u003cp\u003eThe core idea is exactly what it sounds like. Stop writing impressions. Start writing evidence. Things the candidate said. Things they did. Decisions they made out loud. Numbers they cited. Trade-offs they named. Questions they asked you.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;She seemed nervous\u0026rdquo; is not evidence.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;She paused for almost twenty seconds before answering, then said she was not sure how she would approach it\u0026rdquo; is evidence. The first is your interpretation. The second is something a video camera would have captured. The video camera version is what you want in your notes.\u003c/p\u003e\n\u003cp\u003eOnce you start writing notes that way, two things happen. The first is that your debriefs get faster, because everyone is arguing from the same kind of material. The second, more important thing, is that you find out which of your interviewers were not actually paying attention. The ones who can only produce vague summaries usually were not capturing anything in real time. They were being polite for forty-five minutes and then writing down their general vibe afterwards.\u003c/p\u003e\n\u003cp\u003eThat is a lot of decisions being made on vibes.\u003c/p\u003e\n\u003ch2 id=\"four-kinds-of-evidence\"\u003eFour kinds of evidence\u003c/h2\u003e\n\u003cp\u003eDan\u0026rsquo;s post unpacks this further. There are four kinds of evidence you can collect in an interview, and each tells you something different.\u003c/p\u003e\n\u003cp\u003eIn rough order of weight:\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/framework-cant-run-interviews/four-kinds-of-evidence_hu_da4c32d5d7d6f87e.jpg\"\n    srcset=\"/framework-cant-run-interviews/four-kinds-of-evidence_hu_2a34f4ce677be0cb.webp 640w, /framework-cant-run-interviews/four-kinds-of-evidence_hu_8eb84835bc02ed18.webp 960w, /framework-cant-run-interviews/four-kinds-of-evidence_hu_864950116caa4695.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"Four evidence quadrants: experiential, hypothetical, opinion, and credential evidence\"\n    width=\"1280\"\n    height=\"841\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eExperiential evidence.\u003c/strong\u003e Things the candidate has actually done. \u0026ldquo;Tell me about a time when\u0026hellip;\u0026rdquo; \u0026ldquo;Can you give me an example of\u0026hellip;\u0026rdquo; \u0026ldquo;Then what happened?\u0026rdquo; This is the most valuable kind. It is also the easiest to push on, because real stories have specific details and contradictions and ambiguities. Polished stories that survive multiple follow-up questions are usually real.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHypothetical evidence.\u003c/strong\u003e What the candidate thinks they would do. \u0026ldquo;What would you do if\u0026hellip;\u0026rdquo; \u0026ldquo;If you had to do that project again, what would you change?\u0026rdquo; You cannot prove a hypothetical, but you can learn how someone reasons. How do they decompose the problem? What do they ask for? What trade-offs do they name without prompting? Hypotheticals are especially useful for more junior candidates who do not yet have the experience for a strong experiential answer.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eOpinion evidence.\u003c/strong\u003e What the candidate thinks about things. \u0026ldquo;What is your view on testing?\u0026rdquo; \u0026ldquo;What do you think makes a good code review?\u0026rdquo; Opinion evidence is interesting in two layers. The first is the opinion itself, which tells you about taste and exposure. The second, often more telling, is what happens when you push back on it. Do they hold their ground with new arguments? Do they collapse and agree with whatever you said? Do they get defensive? I have learned more about candidates from the way they handled disagreement than from the opinion itself.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCredential evidence.\u003c/strong\u003e What they are formally qualified to do. Degrees, certifications, languages, tooling. Useful, sometimes load-bearing in regulated work, but the lightest of the four for most engineering hiring.\u003c/p\u003e\n\u003cp\u003eMost of the worst interviews I have run or watched were heavy on opinion and credential, light on experiential, and almost never explicitly hypothetical. That ratio is backwards. Opinion and credential are the easiest to fake. Experiential is the hardest, especially when you keep asking \u0026ldquo;and then what did you do?\u0026rdquo; until the story either holds together or does not.\u003c/p\u003e\n\u003cp\u003eA small thing that helps me: I keep a sheet of paper divided into four quadrants, labelled with the four evidence types. As I take notes during the interview, I drop each note into the relevant quadrant. Halfway through, I can glance down and see where I am thin. If I have nothing in the experiential quadrant, my next question should not be \u0026ldquo;and what is your view on microservices?\u0026rdquo; My next question should be \u0026ldquo;give me an example of a service migration you led.\u0026rdquo;\u003c/p\u003e\n\u003ch2 id=\"the-calibrated-interview\"\u003eThe calibrated interview\u003c/h2\u003e\n\u003cp\u003eNow stitch the two halves together, because that is where the actual fix lives.\u003c/p\u003e\n\u003cp\u003eA calibrated interview is one where each question is doing two jobs at once. It is mapped to a specific cell in the framework. And it is structured to produce one of the four kinds of evidence.\u003c/p\u003e\n\u003cp\u003eIf your framework says, for Senior level, \u0026ldquo;Influences technical direction across multiple teams\u0026rdquo;, you can build a small set of questions for that cell:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cem\u003eExperiential\u003c/em\u003e: \u0026ldquo;Tell me about a technical decision you made or shaped that affected at least one team outside your own. Walk me through how it actually played out.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eHypothetical\u003c/em\u003e: \u0026ldquo;Suppose you joined our platform team and noticed two product teams had quietly built different solutions to the same problem. What would you do?\u0026rdquo;\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eOpinion\u003c/em\u003e: \u0026ldquo;How do you think technical direction should be set in an org with multiple engineering teams? What is the role of an individual senior engineer in that?\u0026rdquo;\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThree different angles on the same framework line. Each surfacing a different kind of evidence. Each grounded in something observable.\u003c/p\u003e\n\u003cp\u003eNow compare what your debrief looks like with this setup versus without it.\u003c/p\u003e\n\u003cp\u003eWithout it: \u0026ldquo;I think she was a strong Senior. She seemed to get it.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eWith it: \u0026ldquo;On the framework line for cross-team influence, here is what I have. Experiential: she described a database migration involving two teams, named the political tension explicitly, told me how she handled the principal engineer who initially blocked it, and walked through what she would do differently now. Hypothetical: when I gave her the parallel-implementation scenario, she immediately asked who owned the platform charter and whether there was an existing forum for technical alignment. Opinion: she pushed back when I argued that staff engineers should make these calls unilaterally, and articulated a view about distributed decision-making with named trade-offs. I am ready to recommend hire at level on this dimension.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThose two paragraphs lead to different organisational outcomes over a year of hiring. The first one hires whoever the loudest interviewer in the room liked. The second one hires people whose evidence matches the level you said you wanted.\u003c/p\u003e\n\u003ch2 id=\"worked-example-a-senior-engineer-loop\"\u003eWorked example: a Senior Engineer loop\u003c/h2\u003e\n\u003cp\u003eLet me make this less abstract.\u003c/p\u003e\n\u003cp\u003eSuppose you are hiring a Senior Software Engineer for a backend team. Your framework, summarised, says they should be able to:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eOwn a non-trivial system end to end.\u003c/li\u003e\n\u003cli\u003eDrive improvement in team processes and tools.\u003c/li\u003e\n\u003cli\u003eMentor and grow more junior engineers.\u003c/li\u003e\n\u003cli\u003eInfluence technical direction within the team and occasionally beyond.\u003c/li\u003e\n\u003cli\u003eCommunicate clearly with non-engineering stakeholders.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eYou have a four-stage loop: hiring manager screen, technical deep-dive, system design, and a behavioural round.\u003c/p\u003e\n\u003cp\u003eWithout translation, each interviewer picks up the framework, reads it, and goes \u0026ldquo;I will ask about ownership somehow.\u0026rdquo; The behavioural round becomes a wandering conversation. The technical deep-dive turns into trivia. The system design defaults to whatever pet question the interviewer has been asking for years.\u003c/p\u003e\n\u003cp\u003eWith translation, the loop looks different. Each stage owns specific framework cells, and each question in that stage is mapped to an evidence type.\u003c/p\u003e\n\u003cp\u003eThe hiring manager screen takes \u003cem\u003eOwnership\u003c/em\u003e and \u003cem\u003eCommunication\u003c/em\u003e. The questions are mostly experiential and opinion. \u0026ldquo;Tell me about the last system you genuinely owned, end to end. Who else was involved? What did \u0026lsquo;owning\u0026rsquo; actually mean day to day?\u0026rdquo; \u0026ldquo;How do you usually communicate technical risk to a product manager who is pushing for a deadline?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe technical deep-dive takes \u003cem\u003eDrive improvement\u003c/em\u003e and \u003cem\u003eMentoring\u003c/em\u003e. Hypothetical and experiential, mostly. \u0026ldquo;Walk me through a time you noticed something the team should change and made it happen.\u0026rdquo; \u0026ldquo;If you joined our team and saw a junior engineer repeatedly making the same mistake in their pull requests, what would you do?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe system design takes \u003cem\u003eInfluence technical direction\u003c/em\u003e. Mostly hypothetical, with experiential pull-ins. \u0026ldquo;Design a service that does X. As you go, tell me which decisions you would actually escalate to your team or other teams, and which you would just make yourself.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe behavioural round takes \u003cem\u003eMentoring\u003c/em\u003e, \u003cem\u003eCommunication\u003c/em\u003e, and \u003cem\u003eDrive improvement\u003c/em\u003e, with deliberate cross-checks against earlier rounds. \u0026ldquo;Earlier you mentioned a refactor you led. Tell me how you brought your team along on it.\u0026rdquo; Cross-check signals from the technical deep-dive against the behavioural framing. Look for inconsistencies between hypothetical and experiential answers. Most candidates are not lying when they are inconsistent. They are revealing that the experience they described was actually shaped more by someone else than they let on.\u003c/p\u003e\n\u003cp\u003eThe debrief at the end has structure. Every cell has been touched by at least two interviewers. Every interviewer has notes that mostly look like quotes and decisions, not summaries. Disagreement still happens. But disagreement happens over interpretation of evidence, not over whose vibes win.\u003c/p\u003e\n\u003ch2 id=\"where-this-fails-most-often\"\u003eWhere this fails most often\u003c/h2\u003e\n\u003cp\u003eA few things will break this if you let them.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eThe framework itself is terrible.\u003c/em\u003e If your framework is genuinely vague at every level, no amount of translation will save you. Some companies copy their levels from a cached version of an older framework, never tuned to their actual product or tech context. If you cannot pick a single sentence and turn it into a real behaviour for your engineers, the problem is the framework, not the interview. Fix that first. (I have written about a related version of this in \u003ca href=\"https://leadership.garden/there-is-no-standard-em-role/\"\u003eThere Is No Standard EM Role\u003c/a\u003e, and the same logic applies to engineers: if you have not defined the role for \u003cem\u003eyour\u003c/em\u003e context, you cannot interview for it.)\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eOne interviewer trying to cover everything.\u003c/em\u003e I have seen loops where a single 60-minute round was supposed to test ownership, communication, mentoring, technical depth, and cultural fit. That is not an interview. That is an opportunity to collect impressions across five things and be confident in none of them. Pick two or three framework cells per round. Cover the rest somewhere else in the loop.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eTreating \u0026ldquo;passes the bar\u0026rdquo; as the unit.\u003c/em\u003e The most common failure I see in evidence-based interviewing is the moment an interviewer realises they have evidence on three of the four cells they were supposed to cover and silently rounds up. The right move is the one that feels uncomfortable. Say \u0026ldquo;I do not have evidence on cell X\u0026rdquo; out loud in the debrief. Either someone else does, or you go back. Hiring at level when you have evidence on most cells but not the one that matters is how you end up with engineers who carry the title but not the responsibilities.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eSenior interviewers who refuse to write evidence.\u003c/em\u003e The ones who have been doing this for a decade sometimes treat the move from impressions to evidence as bureaucratic. \u0026ldquo;I just \u003cem\u003eknow\u003c/em\u003e when someone is a Senior.\u0026rdquo; Maybe they do. The problem is nobody else can audit that. And if their model is wrong, you will not find out for two years, by which point a lot of damage has compounded. If you are running interviews, you owe the rest of your hiring system written evidence. Your gut is welcome to weigh in. It does not get to vote alone.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eConfusing the candidate\u0026rsquo;s smoothness with their level.\u003c/em\u003e A candidate who interviews well is not the same thing as a candidate who works well at the level you are hiring for. Smoothness is one signal. Evidence is the test. I have hired smooth candidates who did not have the experience. I have, more than once, almost passed on excellent engineers because they were nervous and inarticulate in a stressful conversation. If your loop only rewards smoothness, you will keep getting candidates who interview better than they perform. (I wrote a separate piece on the candidate-side mirror of this in \u003ca href=\"https://leadership.garden/technical-interview-myths/\"\u003eThe Top 11 Technical Interview Myths\u003c/a\u003e, if any of you are on that side of the table right now.)\u003c/p\u003e\n\u003ch2 id=\"the-standard\"\u003eThe standard\u003c/h2\u003e\n\u003cp\u003eIf I had to compress this into one rule, it would be: a hiring decision is only as good as the evidence you can put behind it.\u003c/p\u003e\n\u003cp\u003eFrameworks are necessary. They tell you what level you are aiming at and what that level should look like once someone is in the role. They are not sufficient. They do not tell you how to find out whether this candidate, in this conversation, is at that level.\u003c/p\u003e\n\u003cp\u003eYou bridge the gap with two disciplines. You translate framework statements into observable behaviours, and then into questions. You collect evidence, by which I mean things you actually heard or saw, not generalised impressions. Then you debrief from the evidence and the framework, not from the vibe.\u003c/p\u003e\n\u003cp\u003eThis sounds like more work, and it is. The first time you do it for a role, you will spend an extra hour on prep. The first calibrated debrief will take longer than your usual one. The second one will already be faster. Within a quarter, you will look back at how you used to run interviews and feel a quiet kind of horror.\u003c/p\u003e\n\u003cp\u003eI do not think hiring gets better when it gets more confident. I think it gets better when it gets more honest about the difference between what you saw and what you concluded.\u003c/p\u003e\n\u003cp\u003eMost interviews test the wrong things. The fix is not better instincts. The fix is better evidence, mapped to a framework that actually means something at your company.\u003c/p\u003e\n\u003cp\u003eThat is the standard. Refuse to lower it.\u003c/p\u003e\n","date_modified":"2026-05-30T00:00:00Z","date_published":"2026-05-30T00:00:00Z","id":"https://leadership.garden/framework-cant-run-interviews/","summary":"Career frameworks describe outcomes, not behaviors; interviewers collect impressions, not evidence. Here's how to fix both.","tags":["hiring","interview","career"],"title":"Your Career Framework Can't Run Your Interviews","url":"https://leadership.garden/framework-cant-run-interviews/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003e\u0026hellip; they were already broken\u0026hellip;\u003c/p\u003e\n\u003cp\u003eLinkedIn is full of engineers who have just discovered that pull requests are impossible to review at the pace AI agents produce code.\u003c/p\u003e\n\u003cp\u003ePull requests as a bottleneck. Imagine that.\u003c/p\u003e\n\u003cp\u003eNow they are searching for new ways of working to solve this brand new problem. New frameworks. New tools. New triage agents. New rituals.\u003c/p\u003e\n\u003cp\u003eThere is nothing new about it.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://leadership.garden/ai-is-an-amplifier/\"\u003eI keep writing this argument in different shapes\u003c/a\u003e, so let me just say it plainly here. AI is an amplifier. It amplifies what you already do. If what you already do is slow and broken, you now have fast and broken. The queue was always there. Slow input was hiding the cost. Speed up the input, and the cost becomes visible overnight.\u003c/p\u003e\n\u003cp\u003eThat is most of the story. Everything below is about why teams keep refusing to see it.\u003c/p\u003e\n\u003ch2 id=\"the-cost-was-always-there\"\u003eThe cost was always there\u003c/h2\u003e\n\u003cp\u003eA batch of work sitting in a review queue for three days at best, two weeks at worst, was never healthy. Some of us have been saying this for almost twenty years. The teams that listened are now watching the AI surge with mild interest. The teams that did not are panicking and reaching for tools.\u003c/p\u003e\n\u003cp\u003eI want to be careful here, because pull requests are not the villain. They were a perfectly good answer to a different question.\u003c/p\u003e\n\u003cp\u003eGitHub-style PRs were designed for a specific situation: a contributor I have never met, who does not share my Slack, my standup, or my goal, sends me a patch over the internet. I do not know their intent. I cannot ask them a question and get an answer in the next ten seconds. I need a structured artifact, an audit trail, and a place to write my comments down. The pull request is excellent at all of that. It is one of the most successful pieces of social engineering in the history of software.\u003c/p\u003e\n\u003cp\u003eThe problem is not the tool. The problem is that teams who do share a Slack channel, a standup, and a goal decided to behave like strangers throwing patches over a wall.\u003c/p\u003e\n\u003cp\u003eOnce you operate that way, the dynamics are predictable. The reviewer either skims and stamps, because the queue is full and trust is high, or they go deep and become a martyr, because the queue is full and trust is not high enough. Neither outcome is good engineering. The PR was working as designed; the design was imported into a context where it does not pay rent.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://martinfowler.com/bliki/PullRequest.html\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eMartin Fowler made this argument long before AI showed up.\u003c/a\u003e Pre-integration review has real cost: bigger batches, slower integration, deferred merges, more painful refactors. He cites a client who spent 130,000 hours in 2020 waiting on pull requests that received zero comments. Zero. Not \u0026ldquo;few\u0026rdquo;. Zero. The review never happened. The wait did.\u003c/p\u003e\n\u003ch2 id=\"why-the-new-tools-cannot-fix-it\"\u003eWhy the new tools cannot fix it\u003c/h2\u003e\n\u003cp\u003eI am not against tooling. I have spent most of my career building it. But the current wave of \u0026ldquo;AI code review at scale\u0026rdquo; pieces are largely answers to the wrong question.\u003c/p\u003e\n\u003cp\u003eLook at where the energy is going. \u003ca href=\"https://blog.cloudflare.com/ai-code-review/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCloudflare deploys seven specialized reviewer agents per merge request.\u003c/a\u003e \u003ca href=\"https://techcrunch.com/2026/03/09/anthropic-launches-code-review-tool-to-check-flood-of-ai-generated-code/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eAnthropic estimates roughly twenty-five dollars per AI review.\u003c/a\u003e Vendors compete on agent count, prompt sophistication, and policy coverage. None of this is unreasonable on its own terms.\u003c/p\u003e\n\u003cp\u003eIt is also a remarkable amount of effort spent paving over an architectural choice that was already wrong before AI showed up.\u003c/p\u003e\n\u003cp\u003eYou are not solving a review problem. You are managing a queue you should not have. And the bottleneck moves, it does not vanish. If your humans cannot review fifty PRs a day, you bring in an AI reviewer. The AI reviewer flags fifteen of them as needing human attention. Now your humans are the bottleneck on a smaller batch with less context. Congratulations.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://leadership.garden/ai-the-work-moved/\"\u003eI wrote earlier that the bottleneck moved.\u003c/a\u003e This is what that actually looks like in the wild. And if you have read \u003ca href=\"https://leadership.garden/theory-of-constraints/\"\u003ethe post on Theory of Constraints\u003c/a\u003e, you already know the punchline: improving anything that is not the real constraint produces no real improvement at all. The real constraint here is not review throughput. It is the design choice that put a queue between writing code and integrating it.\u003c/p\u003e\n\u003ch2 id=\"the-objections-are-real-and-they-are-not-arguments-for-prs\"\u003eThe objections are real, and they are not arguments for PRs\u003c/h2\u003e\n\u003cp\u003eWhen I make this case, four objections come back, every time. They are real. I am not waving them away. They are arguments for \u003ca href=\"https://leadership.garden/chaos-vs-bureaucracy/\"\u003edesigned collaboration\u003c/a\u003e, not for shipping work over a wall.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eCompliance and four-eyes.\u003c/em\u003e The audit requirement is that two pairs of eyes touch the change. Two engineers writing the code together, with commit history showing both authors and CI logs showing the test runs, satisfies that just as cleanly. A signed pair commit is a stronger audit trail than a tired \u0026ldquo;LGTM\u0026rdquo; left at 6:47 pm by someone who scrolled to the bottom. (I know which one would hold up better in a postmortem.)\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eDistributed teams.\u003c/em\u003e This deserves nuance. If your team has two or three hours of overlap, pair in that overlap and use the rest for solo deep work. Short-lived branches that integrate daily, plus recorded async pairing, beat a week-long review thread on most measures. If your team has zero overlap, you have a deeper problem PRs cannot fix. The honest answer is to fix the team topology, not to industrialize the queue around an awkward split.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eJunior engineers need room to attempt things on their own.\u003c/em\u003e They do. I agree. Pairing is not surveillance. Let the junior drive. Let them struggle out loud with someone who can coach in the moment, instead of writing a thousand lines that get rejected in a comment thread three days later. A correction in real time builds independence. A delayed comment on a variable name builds delay.\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eAudit trails.\u003c/em\u003e Already covered, but worth restating: trunk-based development with pair commits and CI logs produces a richer audit trail than a stamped PR. The audit is in the work, not in the wrapper around it.\u003c/p\u003e\n\u003cp\u003eNone of this is anti-PR. It is anti using PRs as a substitute for talking to each other.\u003c/p\u003e\n\u003ch2 id=\"what-hasnt-changed-in-twenty-years\"\u003eWhat hasn\u0026rsquo;t changed in twenty years\u003c/h2\u003e\n\u003cp\u003eThe advice is not new. That is the entire point.\u003c/p\u003e\n\u003cp\u003ePair, mob, ensemble. Whatever you want to call it. Produce code and review it while you produce it. Adopt test-driven development so the code arrives with its own evidence. Integrate continuously into trunk in small steps. \u003ca href=\"https://trunkbaseddevelopment.com/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eTrunk-based development has a perfectly good handbook\u003c/a\u003e and has had one for years.\u003c/p\u003e\n\u003cp\u003eWhat changes when you do this is not subtle.\u003c/p\u003e\n\u003cp\u003eAI stops being a queue filler. It becomes a third navigator. The pair points it at the problem, watches what it produces, and accepts or rejects it on the spot. The conversation that used to happen three days late in a PR comment now happens in the moment, while context is fresh, before the tired-eye approval.\u003c/p\u003e\n\u003cp\u003eThroughput stops being terrifying. Two engineers and an AI agent producing code together can ship a remarkable amount of work in an afternoon, and they have already reviewed it. There is no second shoe to drop. The queue does not exist because the review already happened.\u003c/p\u003e\n\u003cp\u003eReviews stop being choke points. They become conversations.\u003c/p\u003e\n\u003cp\u003eTests catch what tired eyes cannot. This is the bit that most reliably catches AI drift. If your test suite is real, not the kind that passes by reflex but the kind that actually constrains behavior, then code arriving with passing tests carries real evidence with it. \u003ca href=\"https://leadership.garden/verification-debt/\"\u003eI have written before about verification debt\u003c/a\u003e, the gap between what you ship and what you have actually validated. The most reliable way to keep that gap small is to write the test before the code, and to do it together. I have since written about \u003ca href=\"https://leadership.garden/typing-was-the-safety-harness/\"\u003ewhy hand-rolling your schemas, interfaces, and tests matters more than people think\u003c/a\u003e, and how the slowness of typing was doing load-bearing QA work nobody invoiced for.\u003c/p\u003e\n\u003ch2 id=\"what-this-would-have-looked-like\"\u003eWhat this would have looked like\u003c/h2\u003e\n\u003cp\u003eImagine a team that had quietly removed pull requests as the default flow five years ago. Pairs and mobs. Trunk. Continuous integration. TDD. Lots of small commits. Lots of conversation.\u003c/p\u003e\n\u003cp\u003eThat team is having a different 2026 than the rest of us.\u003c/p\u003e\n\u003cp\u003eFor them, AI showed up and slotted in as another voice at the keyboard. Their integration cadence did not change. Their review cadence did not change, because the review was already happening continuously. The volume of work shipped per pair went up; the cost per change did not. They did not need a triage agent. They did not need a review queue dashboard. They did not need a multi-agent orchestration framework with a budget line in next quarter\u0026rsquo;s planning.\u003c/p\u003e\n\u003cp\u003eThey are not running ahead because they predicted AI. They are running ahead because they took the friction out of integration before there was a tidal wave to absorb.\u003c/p\u003e\n\u003cp\u003eThe teams in trouble are not in trouble because of AI. They are in trouble because they took an old problem, wrapped it in a new label, and built tools to manage the mess the previous tool created.\u003c/p\u003e\n\u003cp\u003e(I have seen versions of this play out before. Every \u0026ldquo;new\u0026rdquo; engineering problem of the past decade had an answer that someone had already written down in 2003. The answer was usually unfashionable.)\u003c/p\u003e\n\u003ch2 id=\"a-return-not-a-discovery\"\u003eA return, not a discovery\u003c/h2\u003e\n\u003cp\u003eI am not trying to be a contrarian about PRs. They are useful in the contexts they were designed for. If you are running an open source project, keep them. If you are accepting external contributions, keep them. If your team is genuinely composed of strangers throwing patches over a wall, well, you have a different problem worth naming, but PRs are still your tool.\u003c/p\u003e\n\u003cp\u003eFor everyone else, AI is doing you a favor. It is making visible a cost you had been quietly absorbing for years. Three-day review latency. Half-read approvals. Review threads that resolve nothing. Refactors deferred because nobody wants to merge a wide diff. None of that started in the last twelve months. AI just turned the volume up until you could no longer ignore it.\u003c/p\u003e\n\u003cp\u003eThe fix is not a new workflow. The fix is the workflow we already knew worked.\u003c/p\u003e\n\u003cp\u003eIt is not a discovery. It is a return.\u003c/p\u003e\n","date_modified":"2026-05-23T00:00:00Z","date_published":"2026-05-23T00:00:00Z","id":"https://leadership.garden/ai-didnt-break-prs/","summary":"AI didn't break pull requests; it exposed the review queues, slow integration, and weak collaboration habits engineering teams already had.","tags":["ai","engineering"],"title":"No, AI didn't break PRs","url":"https://leadership.garden/ai-didnt-break-prs/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eA senior engineer pinged me a couple of years back. Just \u0026ldquo;got a sec?\u0026rdquo; with no other context. We hopped on a call.\u003c/p\u003e\n\u003cp\u003eShe had been promoted to Staff six months earlier. Her review cycle was glowing. She was leading the most strategic project in the org. And she told me, in that flat tone people use when they have been rehearsing the sentence in their head for weeks, that she thought she was burning out.\u003c/p\u003e\n\u003cp\u003eI asked her what it felt like. She paused. \u0026ldquo;Different than last time.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eShe had burned out before in a different company, as a mid-level IC. That one had a familiar shape: too many tickets, too few hours, weekends bleeding into Mondays. She fixed it the way most people do. She set boundaries, took two weeks off, switched teams. It worked.\u003c/p\u003e\n\u003cp\u003eThis time was nothing like that. She wasn\u0026rsquo;t tired. She was hollow. The work was technically fine. The team was fine. Nothing was on fire. She just couldn\u0026rsquo;t find a reason to care about any of it, and the absence of that reason was its own slow horror.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;I thought this was supposed to get better when I got senior,\u0026rdquo; she said.\u003c/p\u003e\n\u003cp\u003eIt doesn\u0026rsquo;t. It just changes shape. And almost nobody tells you that.\u003c/p\u003e\n\u003cp\u003eThat conversation has stayed with me, because I\u0026rsquo;ve had some version of it dozens of times now. Different titles. Different orgs. The same confusion: why does the burnout I\u0026rsquo;m experiencing right now look nothing like the burnout I\u0026rsquo;ve been trained to recognize?\u003c/p\u003e\n\u003cp\u003eThe honest answer is in \u003ca href=\"https://hbr.org/2026/04/burnout-looks-different-across-the-org-chart-watch-for-these-signs\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ea piece Daisy Auger-Domínguez published in HBR earlier this month\u003c/a\u003e, which I think is the most useful thing I\u0026rsquo;ve read on burnout in years. Her central claim: burnout isn\u0026rsquo;t one illness. It\u0026rsquo;s four. They look different. They feel different. They have different root causes and different fixes. And which one you get is largely a function of where you sit on the org chart.\u003c/p\u003e\n\u003cp\u003eI want to take her framework and translate it into the specific shape it takes inside engineering organizations, because the translation is where most of the useful detail lives. Engineering has its own ladder, its own incentives, its own particular way of building each variant of burnout. We also have a dual ladder, which produces a fifth pattern she doesn\u0026rsquo;t quite name.\u003c/p\u003e\n\u003cp\u003eThen I want to address the question that almost nobody else does honestly: what do you do when you are the one burning out and you don\u0026rsquo;t have the authority to redesign the work?\u003c/p\u003e\n\u003cp\u003eThis will be uncomfortable. Burnout coverage in our industry is overwhelmingly about either symptoms (the \u003ca href=\"https://jellyfish.co/blog/engineering-burnout/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eseven warning signs of engineering burnout\u003c/a\u003e, the 10 tips for engineers) or about exhortations to leadership to \u0026ldquo;fix the system.\u0026rdquo; Both are useful, and I have spent time on the symptoms angle myself in \u003ca href=\"https://leadership.garden/demystifying-burnout/\"\u003eDemystifying Burnout\u003c/a\u003e. But neither tells you what to do at 11pm on a Thursday when you\u0026rsquo;ve just realized you\u0026rsquo;ve been in survival mode for nine months and the system has no plans to fix itself.\u003c/p\u003e\n\u003cp\u003eSo let\u0026rsquo;s talk about the five faces. Then let\u0026rsquo;s talk about the AI overlay. Then let\u0026rsquo;s talk about what to do when you cannot redesign the design.\u003c/p\u003e\n\u003ch2 id=\"face-one-ambiguity-the-burnout-of-the-early-career-engineer\"\u003eFace one: ambiguity (the burnout of the early-career engineer)\u003c/h2\u003e\n\u003cp\u003eAuger-Domínguez calls this \u003cstrong\u003eInvisible Overload\u003c/strong\u003e. Her description: constantly guessing what \u0026ldquo;good\u0026rdquo; looks like. Spending more time decoding expectations than doing the work. Anxiety about being replaceable.\u003c/p\u003e\n\u003cp\u003eI have watched this play out in person more times than I can count.\u003c/p\u003e\n\u003cp\u003eThe pattern in engineering: a junior or mid-level engineer who, by all visible measures, is doing fine. PRs land. Standups go normally. They show up. But every conversation with them has a faint undercurrent of dread. They ask \u0026ldquo;is this what you wanted?\u0026rdquo; three times a day. They rewrite their Slack messages four times before sending them. They spend 40 minutes on a one-line code change because the \u003cem\u003emeaning\u003c/em\u003e of the change is unclear.\u003c/p\u003e\n\u003cp\u003eThey are not lazy. They are not disengaged. They are doing an enormous amount of invisible work that has nothing to do with the actual code: reading the room, decoding norms, figuring out who actually decides things, calibrating what \u0026ldquo;fast enough\u0026rdquo; means here, modeling what their tech lead actually wants when they say \u0026ldquo;use your judgment.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eIn an office, this work is largely automatic. You absorb most of it from proximity. You overhear the staff engineer arguing with the PM. You see what your manager rolls their eyes at. You learn what gets praised and what gets quietly fixed by someone else.\u003c/p\u003e\n\u003cp\u003eIn hybrid and remote engineering orgs, that absorption layer is gone, and we have not replaced it with anything. So the work doesn\u0026rsquo;t disappear. It moves into the engineer\u0026rsquo;s head, where it sits there draining cognitive energy 10 hours a day with no name.\u003c/p\u003e\n\u003cp\u003eResearch consistently shows that lack of control and unclear expectations are stronger predictors of burnout than hours worked. The early-career engineer isn\u0026rsquo;t burning out from coding too much. They\u0026rsquo;re burning out from being asked to operate as a senior engineer (figuring out priorities, navigating ambiguity, making judgment calls) without yet having the model to do so cheaply.\u003c/p\u003e\n\u003cp\u003eThe cruel part is that this burnout is invisible to managers because \u003cem\u003ethe work is still getting done\u003c/em\u003e. They\u0026rsquo;re still shipping. They\u0026rsquo;re just dying inside while doing it. By the time anyone notices, the engineer has either quit or hardened into the cynical, defensive shape that takes years to repair.\u003c/p\u003e\n\u003cp\u003eWhat actually helps at this layer:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eMake the implicit explicit.\u003c/strong\u003e Write down decision rights. Say out loud who has authority for what. Tell people what \u0026ldquo;good\u0026rdquo; looks like with specifics, not vibes. The cost of explicit norms is some boring documentation. The cost of implicit ones is your team\u0026rsquo;s nervous systems.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eCap weekly priorities at three.\u003c/strong\u003e Not five. Not \u0026ldquo;everything is important.\u0026rdquo; Three. People can hold three things in their head and still feel like they\u0026rsquo;re winning. They cannot hold seven.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eNormalize asking.\u003c/strong\u003e Demonstrate that asking \u0026ldquo;what do you actually want?\u0026rdquo; is a sign of engineering maturity, not weakness. Then catch yourself when you punish it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eReal-time feedback, not review-cycle assessments.\u003c/strong\u003e If someone is operating off the wrong mental model, the cost compounds daily. Telling them at the next half-yearly review is not feedback. It\u0026rsquo;s a postmortem.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"face-two-compression-the-burnout-of-the-engineering-manager\"\u003eFace two: compression (the burnout of the engineering manager)\u003c/h2\u003e\n\u003cp\u003eAuger-Domínguez calls this \u003cstrong\u003eCompression\u003c/strong\u003e. The shape: absorbing pressure from above while protecting the team below. Working off-hours to catch up, compensating for unclear decisions. Carrying team emotion without structural support.\u003c/p\u003e\n\u003cp\u003eIn engineering, this is the EM and the senior EM, and it is the single most underappreciated burnout pattern in the industry.\u003c/p\u003e\n\u003cp\u003eThe EM\u0026rsquo;s job, in practice, is to translate. From product into eng. From strategy into roadmap. From the VP\u0026rsquo;s vague directive into something the team can actually execute. They are the load-bearing wall between two layers of the org that don\u0026rsquo;t quite speak the same language.\u003c/p\u003e\n\u003cp\u003eThe job depends on a quiet contract: the EM gets enough authority to make decisions on behalf of their team, and the team gets enough protection to focus on the work. When the contract holds, the EM sweats but doesn\u0026rsquo;t burn. When it breaks, the EM becomes a pressure-release valve with no exhaust.\u003c/p\u003e\n\u003cp\u003eThe contract breaks in predictable ways. The reorg that adds two more teams to the EM\u0026rsquo;s portfolio without adding direct reports of their own. The new VP who wants to be looped into \u0026ldquo;all major technical decisions\u0026rdquo; but won\u0026rsquo;t define what major means. The promotion that comes with a bigger budget number but no real say in headcount. The matrix structure where the EM owns the team\u0026rsquo;s outcomes but the staff engineer owns the technical direction and the PM owns the priorities, and somehow when everything goes sideways the EM is the one in the postmortem.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://medium.com/@tcaseylafrance/when-responsibility-outruns-authority-why-middle-management-breaks-first-a85c615eec51\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eOne survey found middle managers report higher burnout (36%) than non-managers, and 71% report being \u0026ldquo;sometimes or always\u0026rdquo; overwhelmed.\u003c/a\u003e That gap isn\u0026rsquo;t because EMs are weaker. It\u0026rsquo;s because the role, as currently designed, is a structural burnout factory.\u003c/p\u003e\n\u003cp\u003eI have been here. I will be here again. Every EM I respect has been here at some point. The honest version of the job sounds like this: you are paid to absorb chaos so that twelve other people can focus, and the price of doing it well is that nobody, including you, can clearly see how much you are absorbing.\u003c/p\u003e\n\u003cp\u003eThe EM\u0026rsquo;s burnout doesn\u0026rsquo;t look like exhaustion. It looks like Sunday anxiety. It looks like checking Slack at 10pm because if you don\u0026rsquo;t, you\u0026rsquo;ll find out tomorrow morning that something blew up and three of your reports are in DM with each other trying to figure out what to do. It looks like decision quality slowly dropping because every decision is being made under low-grade adrenaline. It looks like the EM no longer being able to write the strategy doc, because \u003ca href=\"https://leadership.garden/your-big-brain-needs-breathing-room/\"\u003ethere is no quiet anywhere in the schedule for the kind of thinking strategy requires\u003c/a\u003e.\u003c/p\u003e\n\u003cp\u003eWhat helps:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eReduce meeting load from the top.\u003c/strong\u003e Not as an EM hack. As an explicit executive choice. If your EMs have eight hours of meetings a day, you don\u0026rsquo;t have managers, you have meeting attendees with managerial titles.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eClarify decision rights so the EM doesn\u0026rsquo;t have to manufacture them.\u003c/strong\u003e \u0026ldquo;You can spend up to X without approval.\u0026rdquo; \u0026ldquo;You can make the call on Y.\u0026rdquo; \u0026ldquo;Z escalates.\u0026rdquo; Specificity is a love language for managers.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eBuild a regular check-in that asks about obstacles, not status.\u003c/strong\u003e Status updates are theater. \u0026ldquo;What is in your way that you can\u0026rsquo;t move yourself?\u0026rdquo; is the only question that surfaces compression early enough to help.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStop calling availability commitment.\u003c/strong\u003e The EM who answers Slack at 10:30pm is not your most committed manager. They are the one whose role is the most broken. Reward depth, not response time.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"face-three-the-dual-ladder-trap-the-burnout-hbr-doesnt-quite-name\"\u003eFace three: the dual-ladder trap (the burnout HBR doesn\u0026rsquo;t quite name)\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s where the HBR framework needs an engineering-specific addition.\u003c/p\u003e\n\u003cp\u003eEngineering organizations have something most other professions don\u0026rsquo;t: a real, structural dual ladder. Past senior, the path forks. Some people become EMs and head into the manager track. Others become Staff, then Principal, then Distinguished, and stay on the IC ladder. Both ladders are supposed to lead to seniority and influence. In well-designed orgs, they do.\u003c/p\u003e\n\u003cp\u003eIn poorly designed orgs (which is most of them), the IC ladder produces its own brutal burnout pattern that combines the worst features of two of HBR\u0026rsquo;s other categories.\u003c/p\u003e\n\u003cp\u003eThe Staff or Principal engineer is asked to operate at the strategic horizon of an executive: think across the org, influence roadmap, sniff out architectural risk three quarters out, mentor four EMs\u0026rsquo; worth of engineers. They are evaluated on impact, scope, and \u0026ldquo;tech leadership,\u0026rdquo; none of which are things they can do without authority over other people\u0026rsquo;s time and priorities. But they don\u0026rsquo;t have direct reports. They cannot say \u0026ldquo;do this.\u0026rdquo; They can only convince, persuade, model, write, and influence. And when the persuasion fails, the impact suffers, and they get told they need to \u0026ldquo;level up their tech leadership.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThis is \u003cstrong\u003emoral injury without the title to absorb it\u003c/strong\u003e. They see what\u0026rsquo;s wrong. They have been telling everyone for nine months. The org chooses not to act, because the org has different priorities and the Staff engineer doesn\u0026rsquo;t have the executive authority to force the issue. The codebase they\u0026rsquo;re responsible for keeps degrading in a direction they predicted. Eventually they stop predicting, because what\u0026rsquo;s the point.\u003c/p\u003e\n\u003cp\u003eI have watched extraordinarily talented Staff and Principal engineers burn out this way. The pattern looks like a slow, gradual disengagement from the organization-shaping work, followed by a retreat into deep-IC mode, followed by leaving. From the outside, this looks like \u0026ldquo;they decided they\u0026rsquo;d rather just code.\u0026rdquo; From the inside, it\u0026rsquo;s grief. They cared. They tried. They got tired of their care being treated like a free resource.\u003c/p\u003e\n\u003cp\u003eThe fix the IC ladder needs is genuinely hard, because it requires the org to do something it usually does badly: give Staff+ engineers actual decision authority over the technical direction in their domain, and back them when they use it. Most orgs don\u0026rsquo;t. They give Staff engineers visibility and weight, but reserve the actual decision rights for VPs and directors who have less context.\u003c/p\u003e\n\u003cp\u003eIf you are a Staff engineer reading this and any of it sounds familiar, the thing I want you to know is this: the burnout you have isn\u0026rsquo;t a sign you\u0026rsquo;re insufficiently resilient. It is a signal that the role, as your org has structured it, is not actually possible. That doesn\u0026rsquo;t mean leave. It means stop blaming yourself for failing to do an impossible job, and start having very direct conversations about what authority you would need for the role to be sustainable.\u003c/p\u003e\n\u003ch2 id=\"face-four-moral-injury-the-burnout-of-the-executive\"\u003eFace four: moral injury (the burnout of the executive)\u003c/h2\u003e\n\u003cp\u003eAuger-Domínguez calls this \u003cstrong\u003eMoral Injury\u003c/strong\u003e, borrowing a term from Jonathan Shay\u0026rsquo;s research on combat veterans. The original definition: the lasting damage done by perpetrating, witnessing, or failing to prevent acts that violate one\u0026rsquo;s deeply held moral beliefs.\u003c/p\u003e\n\u003cp\u003eInside engineering executive ranks (directors, VPs, CTOs), this is increasingly the dominant flavor of burnout. The shape: chronic vigilance. Isolation at the top. Values conflict masked as \u0026ldquo;strategy.\u0026rdquo; A sense of carrying consequences alone.\u003c/p\u003e\n\u003cp\u003eThe classic example: the layoff. You are a director. Your VP tells you to cut 15% of your org. You disagree with both the number and the criteria. You raise your concerns. You get heard, partially. The number changes from 15% to 12%. You go back to your team and execute the layoff. You are the one who tells five engineers, three of whom you hired, that their roles are eliminated. They cry. One of them is a single parent. You do this on a Thursday and then chair a roadmap meeting on Friday morning where everyone pretends Thursday didn\u0026rsquo;t happen.\u003c/p\u003e\n\u003cp\u003eYou did not make the decision. You disagreed with it. You executed it anyway, because that is what the job requires. And you carry it.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s moral injury. It is not stress. It is not workload. It is the slow, accumulating cost of acting against your own values at a scale and in a way that you can never fully metabolize. \u003ca href=\"https://ctocraft.com/blog/what-about-tech-leadership-makes-burnout-more-likely/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRecent research on tech leadership notes that 26% of executives report symptoms consistent with clinical depression, compared to 18% in the general workforce.\u003c/a\u003e The gap is not because executives have it harder. It\u0026rsquo;s because their burnout is shaped by something most workplaces don\u0026rsquo;t even have a vocabulary for.\u003c/p\u003e\n\u003cp\u003eThe cruel part of moral injury is that the standard burnout fixes make it worse. \u0026ldquo;Take a vacation\u0026rdquo; doesn\u0026rsquo;t help, because the moral residue doesn\u0026rsquo;t decay with rest. \u0026ldquo;Set boundaries\u0026rdquo; doesn\u0026rsquo;t help, because the problem isn\u0026rsquo;t volume of work, it\u0026rsquo;s the content of the decisions you\u0026rsquo;ve made. \u0026ldquo;Do more self-care\u0026rdquo; lands as condescension, because the executive knows perfectly well what self-care is. They are not in distress because they\u0026rsquo;re insufficiently rested. They\u0026rsquo;re in distress because they have done things that they can no longer pretend not to have done.\u003c/p\u003e\n\u003cp\u003eWhat helps, and this is genuinely hard:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eTrusted peer forums.\u003c/strong\u003e Not your direct reports. Not your boss. Not your spouse, who shouldn\u0026rsquo;t have to absorb this. Other executives, ideally outside your company, who have made versions of the same decisions and can talk about them honestly. If you don\u0026rsquo;t have this, build it. Other CTOs are your peers in a way nobody inside your company can be.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSlow the decision pace.\u003c/strong\u003e Most executive burnout I\u0026rsquo;ve seen comes from too many irreversible decisions made too quickly. Build in structured reflection time before high-stakes calls. The cost of waiting 48 hours on a hard decision is almost always lower than the cost of getting it wrong.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eName the values conflict explicitly.\u003c/strong\u003e When you are being asked to do something you disagree with, the moral cost is lower if you have named the disagreement out loud, even if you still execute. The damage compounds when you pretend, even to yourself, that you agree.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eStop confusing composure with health.\u003c/strong\u003e The fact that nobody can tell you are suffering is not a sign that you aren\u0026rsquo;t.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"face-five-identity-collapse-the-burnout-of-the-founder-and-the-head-of-engineering-who-acts-like-one\"\u003eFace five: identity collapse (the burnout of the founder, and the head of engineering who acts like one)\u003c/h2\u003e\n\u003cp\u003eThe final shape Auger-Domínguez names is \u003cstrong\u003eIdentity Collapse\u003c/strong\u003e, which she places primarily with founders and nonprofit leaders. The pattern: inability to rest without guilt. Personal worth tied to organizational survival. Staying in chronic crisis mode.\u003c/p\u003e\n\u003cp\u003eI want to extend this to a category she doesn\u0026rsquo;t quite cover: the head of engineering at a small or mid-stage company who has fused their identity with the engineering organization itself. The CTO who can\u0026rsquo;t take a real vacation because \u0026ldquo;what if something happens.\u0026rdquo; The VP of Eng who answers Slack from their kid\u0026rsquo;s recital. The first-engineering-hire-now-running-the-show whose entire sense of self is bound up in whether the next release goes well.\u003c/p\u003e\n\u003cp\u003eThis isn\u0026rsquo;t rare. It\u0026rsquo;s the modal failure mode of the leader who built the thing they now run. The work used to be something they did. It is now something they are. When the two collapse, rest stops feeling like recovery and starts feeling like betrayal.\u003c/p\u003e\n\u003cp\u003eThe signal is usually something a partner notices first. They can\u0026rsquo;t put their phone down. They go on vacation but they\u0026rsquo;re not actually there. A small production incident on Saturday consumes the entire weekend, including the part where they were supposed to be at their kid\u0026rsquo;s birthday party.\u003c/p\u003e\n\u003cp\u003eIf this is you, the only durable fix is to deliberately, structurally build the org so that you are not the single point of failure for it. Not as an exercise in delegation. As an exercise in your own continued ability to function as a human. \u0026ldquo;If I rest, I worry no one will carry the mission\u0026rdquo; is a sign you have built something dependent on your overextension, and the most generous thing you can do for the mission is to make it less dependent on you.\u003c/p\u003e\n\u003ch2 id=\"the-ladder-doesnt-cure-burnout-it-changes-its-shape\"\u003eThe ladder doesn\u0026rsquo;t cure burnout. It changes its shape.\u003c/h2\u003e\n\u003cp\u003eThis is the implicit truth in Auger-Domínguez\u0026rsquo;s framework, and it\u0026rsquo;s the part I think more engineers need to hear out loud.\u003c/p\u003e\n\u003cp\u003eThe mid-level engineer who burns out from too many tickets often consoles themselves with: \u0026ldquo;this will get better when I\u0026rsquo;m senior. Senior engineers don\u0026rsquo;t get pulled into every fire.\u0026rdquo; Then they get to senior and the fires are different but they\u0026rsquo;re still on fire.\u003c/p\u003e\n\u003cp\u003eThe senior who burns out from being on call for everything tells themselves: \u0026ldquo;this will get better when I\u0026rsquo;m Staff. Staff engineers get to focus.\u0026rdquo; Then they get to Staff and discover they are now responsible for things they cannot control, and that the lack of authority is a worse burnout than the lack of focus was.\u003c/p\u003e\n\u003cp\u003eThe Staff engineer thinks: \u0026ldquo;this will get better when I move into management and have actual reports.\u0026rdquo; Then they become an EM and discover compression, and Sunday anxiety, and the strange experience of having authority over people but not over the conditions of their work.\u003c/p\u003e\n\u003cp\u003eThe EM thinks: \u0026ldquo;this will get better at director, when I\u0026rsquo;m shaping strategy instead of executing it.\u0026rdquo; Then they become a director and discover moral injury, and isolation, and the slow weight of decisions they cannot fully make.\u003c/p\u003e\n\u003cp\u003eThe director thinks: \u0026ldquo;this will get better when I\u0026rsquo;m VP, when I have real authority.\u0026rdquo; And the VP, who has more authority than they\u0026rsquo;ve ever had, finds out that authority is the thing that creates moral injury, not the cure for it.\u003c/p\u003e\n\u003cp\u003eThe ladder is not a treatment plan. Each rung is a different illness. Promotion does not heal you. It changes which symptoms you have.\u003c/p\u003e\n\u003cp\u003eThis is not a counsel of despair. It\u0026rsquo;s a counsel of accuracy. Once you know the burnout you have is structurally different at each level, you can stop waiting to be promoted out of it and start actually addressing the version you have right now.\u003c/p\u003e\n\u003ch2 id=\"the-2026-ai-overlay\"\u003eThe 2026 AI overlay\u003c/h2\u003e\n\u003cp\u003eI want to add one piece the HBR framework doesn\u0026rsquo;t cover, because it\u0026rsquo;s relevant to anyone in engineering reading this in 2026.\u003c/p\u003e\n\u003cp\u003eAI is amplifying every layer of the burnout map. Not equally. Differently.\u003c/p\u003e\n\u003cp\u003eFor the early-career engineer, AI has dramatically increased the ambient ambiguity. What does \u0026ldquo;good\u0026rdquo; look like when 80% of your code can be generated, and the remaining 20% is the part that requires judgment you don\u0026rsquo;t yet have? \u0026ldquo;Junior engineer\u0026rdquo; used to mean \u0026ldquo;person learning to code.\u0026rdquo; Now it means \u0026ldquo;person learning to evaluate code,\u0026rdquo; which is a much harder job to learn cheaply. The decoding load has gone up, not down.\u003c/p\u003e\n\u003cp\u003eFor the EM, AI has \u003ca href=\"https://leaddev.com/culture/engineering-burnout-rising-2025-layoffs-reshape-tech-industry\" target=\"_blank\" rel=\"noopener noreferrer\"\u003emultiplied the throughput of their team without multiplying their decision capacity\u003c/a\u003e. PR volume goes up. Review burden goes up. The number of small decisions per day goes up. The EM\u0026rsquo;s own brain stays exactly the same size. Compression intensifies.\u003c/p\u003e\n\u003cp\u003eFor the Staff engineer, AI has made the architectural risk landscape genuinely harder to model. Codebases are growing faster. Coupling is being introduced by people who don\u0026rsquo;t fully understand what the AI generated for them. The Staff engineer can see the systemic risk earlier than anyone else, but their authority to act on it has not grown. Moral injury accelerates.\u003c/p\u003e\n\u003cp\u003eFor the executive, AI is the topic on which they are being asked to make the most consequential decisions of their career, with the least clear evidence, on the shortest timeline, in front of boards that don\u0026rsquo;t fully understand the technology and employees who rightly fear what those decisions will mean for them. Layoffs framed as \u0026ldquo;AI efficiency.\u0026rdquo; Hiring freezes framed as \u0026ldquo;we\u0026rsquo;ll see what AI does.\u0026rdquo; Each of those is a moral-load decision, and there are now a lot more of them per quarter.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m not saying AI causes burnout. I\u0026rsquo;m saying the five faces are all currently being amplified by it. Anyone diagnosing their own burnout in 2026 should factor this in.\u003c/p\u003e\n\u003ch2 id=\"what-to-do-when-you-cant-redesign-the-system\"\u003eWhat to do when you can\u0026rsquo;t redesign the system\u003c/h2\u003e\n\u003cp\u003eThis is the question almost no one writes about honestly.\u003c/p\u003e\n\u003cp\u003eMost burnout coverage assumes you have the authority to fix the conditions producing it. \u0026ldquo;Cap priorities at three.\u0026rdquo; \u0026ldquo;Clarify decision rights.\u0026rdquo; \u0026ldquo;Reduce meeting load from the top.\u0026rdquo; Wonderful. What if you\u0026rsquo;re the EM whose VP has not heard of any of this and won\u0026rsquo;t?\u003c/p\u003e\n\u003cp\u003eHere is the honest answer, in three parts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFirst, get accurate about which face you have.\u003c/strong\u003e This sounds trivial. It isn\u0026rsquo;t. Most people I\u0026rsquo;ve talked to about their burnout were misdiagnosing it, which meant they were also applying the wrong fix. The mid-career engineer trying to fix moral injury with vacation. The Staff engineer trying to fix compression with focus time. The executive trying to fix moral injury with workouts. The fix that maps to the wrong burnout is worse than no fix, because it consumes the energy you needed for the right fix and produces no relief, which then becomes evidence in your own head that you\u0026rsquo;re broken.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://hbr.org/2026/04/burnout-looks-different-across-the-org-chart-watch-for-these-signs\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eRead the HBR piece.\u003c/a\u003e Sit with it. Figure out, with as much honesty as you can, which face you have right now. If you also want a numerical read on the underlying exhaustion, the \u003ca href=\"https://leadership.garden/quantifying-burnout/\"\u003eMaslach inventory I shared earlier\u003c/a\u003e is the standard tool for scoring it. Notice that the face you have is probably not the same one you had two years ago.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSecond, do the things you can do, even when they feel insufficient.\u003c/strong\u003e You may not be able to redesign your org. You can, almost always, do some of the following:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eGet your own decision rights in writing, even informally. \u0026ldquo;Just to confirm, I have authority on X up to Y. Anything beyond that, I\u0026rsquo;ll bring to you.\u0026rdquo; Send it as a Slack message. Save it.\u003c/li\u003e\n\u003cli\u003eCap your own priorities at three. Even if your boss has given you ten. You can only do three well, anyway.\u003c/li\u003e\n\u003cli\u003ePick one recurring meeting you can decline. Decline it.\u003c/li\u003e\n\u003cli\u003eHave one honest conversation per week with someone outside your company who understands your role. Not advice. Witness. Burnout that is named is half its weight.\u003c/li\u003e\n\u003cli\u003eNotice when you\u0026rsquo;re doing emotional labor that nobody asked for and nobody will reward. Stop doing some of it.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThese are small. They are not transformative. They are also, in my experience, the difference between burning out in six months and lasting long enough to either change your situation or change your circumstances.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThird, accept that some roles, as currently structured, are not survivable, and leaving is sometimes the correct fix.\u003c/strong\u003e I am suspicious of every burnout post that ends with \u0026ldquo;and so I quit and started a substack.\u0026rdquo; I\u0026rsquo;m equally suspicious of the ones that pretend you can yoga your way out of an unsurvivable role. Both are dishonest. The truth is that some roles, in some orgs, at some moments, are designed in a way that no amount of personal practice will redeem. If you have named the problem, asked for the redesign, and watched the org choose not to redesign, leaving is not failure. It\u0026rsquo;s accurate.\u003c/p\u003e\n\u003cp\u003eThat said, leaving should be a clear-eyed decision, not a panic move. The job after this one will have one of the five faces too. Pick the one whose shape you can actually carry.\u003c/p\u003e\n\u003ch2 id=\"a-final-note\"\u003eA final note\u003c/h2\u003e\n\u003cp\u003eI started this post with the staff engineer who told me her burnout felt different this time. I want to come back to her, because I think the most important thing I told her in that conversation is the thing I want you to take away.\u003c/p\u003e\n\u003cp\u003eI told her: the burnout you have right now is not the burnout you\u0026rsquo;ve been trained to recognize. The version you have is real. It has a name. It has a shape. The fact that it doesn\u0026rsquo;t look like the kind of exhaustion you\u0026rsquo;ve been taught to spot doesn\u0026rsquo;t mean you\u0026rsquo;re imagining it. It means the map you were handed was incomplete.\u003c/p\u003e\n\u003cp\u003eEngineering as an industry has gotten reasonably good at noticing the early-career version of burnout. We\u0026rsquo;ve learned to talk about workload, hours, on-call rotation. We are getting better, slowly, at talking about the EM version. We are barely beginning to talk about the Staff version, the director version, the VP version. We have almost no public vocabulary for moral injury at the executive layer.\u003c/p\u003e\n\u003cp\u003eThe five faces are all real. They are all happening at your company right now. They are all under-named, under-treated, and routinely misdiagnosed.\u003c/p\u003e\n\u003cp\u003eIf you are in any kind of leadership role in an engineering org, the most useful thing you can do is learn to tell the five apart in yourself first, then in the people you\u0026rsquo;re responsible for. The fix that maps to the wrong burnout is the fix that doesn\u0026rsquo;t help. The fix that maps to the right one, even when it\u0026rsquo;s small, is the fix that buys you years.\u003c/p\u003e\n\u003cp\u003eThe work is not to be more resilient. The work is to be more accurate.\u003c/p\u003e\n","date_modified":"2026-05-16T00:00:00Z","date_published":"2026-05-16T00:00:00Z","id":"https://leadership.garden/engineering-burnout-five-faces/","summary":"Burnout has a different shape at every rung of the engineering ladder, and promotion doesn't cure it: it just trades one variant for another.","tags":["burnout","leadership","engineering","career"],"title":"Engineering Burnout Has Five Faces, and Your Career Ladder Walks You Through All of Them","url":"https://leadership.garden/engineering-burnout-five-faces/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe question everyone is asking is: who will be the senior engineers in 10 years?\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s a reasonable question. But I think it\u0026rsquo;s the wrong timeframe. The decisions shaping what your senior engineering pool looks like in a decade are not future decisions. They were made in 2023. They are being made right now, this quarter, in budget reviews and headcount conversations happening in meeting rooms and Zoom calls at companies you\u0026rsquo;ve heard of. And most of those rooms are making the same call without realizing the long-term consequences.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve managed engineering teams long enough to have lived through a few versions of this panic. The talent war of 2021-2022, when we were outbid for mid-levels by companies throwing RSUs around like confetti. The post-pandemic correction, when those same companies collapsed their hiring overnight. You develop a feel for when the industry is about to step on a rake. This feels like that.\u003c/p\u003e\n\u003cp\u003eWhat follows is my honest attempt to think through where we\u0026rsquo;re actually headed, why the optimistic reading keeps getting things wrong, and what I think is the most likely future for engineering talent in the next decade. I\u0026rsquo;m going to be more specific than \u0026ldquo;it could go several ways.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eI have opinions. I\u0026rsquo;ll share them.\u003c/p\u003e\n\u003ch2 id=\"the-pipeline-nobody-noticed\"\u003eThe pipeline nobody noticed\u003c/h2\u003e\n\u003cp\u003eFor decades, the junior-to-senior progression worked almost automatically.\u003c/p\u003e\n\u003cp\u003eNot because companies were particularly good at developing talent. Most weren\u0026rsquo;t. It worked because the \u003cem\u003eenvironment\u003c/em\u003e did the development work. Codebases were messy and undocumented. There was no AI to ask. Production incidents were your responsibility to debug with the logs you had. You sat next to someone more experienced and absorbed how they thought, not because your manager had a development plan for you, but because that was just how offices worked.\u003c/p\u003e\n\u003cp\u003eI learned more in my first two years from reading other people\u0026rsquo;s code reviews than I did from any deliberate training my employer offered. The environment created friction. The friction created learning. Managers got credit for development that the situation was quietly doing for them.\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s what\u0026rsquo;s changed: AI has removed most of that natural friction. Junior engineers can now get an implementation in 30 seconds that would have taken them two hours to work through. That\u0026rsquo;s obviously good for output. It\u0026rsquo;s not obviously good for learning. When you skip the struggle, you skip the part where the mental model forms.\u003c/p\u003e\n\u003cp\u003eAnd simultaneously: there are fewer juniors to speak of. Entry-level tech job postings \u003ca href=\"https://www.rezi.ai/posts/entry-level-jobs-and-ai-2026-report\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ehave dropped by more than 60% since 2022\u003c/a\u003e. \u003ca href=\"https://spectrum.ieee.org/ai-effect-entry-level-jobs\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eStanford researchers tracked\u003c/a\u003e a nearly 20% decline in employment for software developers aged 22-25 from late 2022 to mid-2025. A \u003ca href=\"https://papers.ssrn.com/sol3/papers.cfm?abstract_id=5425555\u0026amp;__cf_chl_tk=gXaHUKS5rCMqzBLtPt6xq9ls2Ha7V0TK_Us130bpnEU-1776103843-1.0.1.1-3SwXc4Xs8nwCv434tjLWbHL4xQeepXWuCRXFtm_z81k\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eHarvard study\u003c/a\u003e found that in firms actively adopting AI tools, junior employment fell by nearly 8% relative to non-adopters within six quarters. These aren\u0026rsquo;t rounding errors. An entire cohort is missing.\u003c/p\u003e\n\u003cp\u003eSo we have two things happening at once: fewer people entering the pipeline, and the pipeline itself working less reliably for those who do enter. The compounding effect of that combination is what nobody is quite willing to say out loud.\u003c/p\u003e\n\u003ch2 id=\"why-the-optimistic-reading-keeps-failing\"\u003eWhy the optimistic reading keeps failing\u003c/h2\u003e\n\u003cp\u003eThe hopeful version of this story usually goes like this: every abstraction layer was supposed to be the end of entry-level programming, and it never was. Machine code gave way to assembly, assembly to higher-level languages, the browser brought JavaScript, the cloud abstracted away infrastructure. Each time, instead of collapsing the entry points, the new layer created different ones.\u003c/p\u003e\n\u003cp\u003eI find this argument genuinely compelling as history. I find it much less compelling as forecast.\u003c/p\u003e\n\u003cp\u003eThe thing about previous abstraction layers is that they made programming \u003cem\u003eaccessible to more people\u003c/em\u003e, not just faster for existing programmers. BASIC on home computers meant a generation of teenagers could start coding on their own. JavaScript in browsers meant designers could learn to program without setting up a build environment. Each layer lowered the floor and expanded the population.\u003c/p\u003e\n\u003cp\u003eAI does something categorically different. It doesn\u0026rsquo;t lower the floor by making concepts easier to learn. It lowers the floor by letting you \u003cstrong\u003e\u003cem\u003eskip the concepts entirely\u003c/em\u003e\u003c/strong\u003e. You can ship working software without understanding what it does. That is genuinely new (and harmful/dangerous on many levels, but that\u0026rsquo;s for another post\u0026hellip;).\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a real version of the optimistic scenario where new entry points emerge that we haven\u0026rsquo;t imagined yet. Maybe product engineers who orchestrate AI become the new juniors. Maybe the skills required shift enough that a whole new population can participate. I hold that possibility open.\u003c/p\u003e\n\u003cp\u003eBut I don\u0026rsquo;t think you can bet a talent strategy on \u0026ldquo;maybe.\u0026rdquo; And more importantly, I think we need to be honest about what the data is already showing.\u003c/p\u003e\n\u003ch2 id=\"three-predictions-not-three-scenarios\"\u003eThree predictions, not three scenarios\u003c/h2\u003e\n\u003cp\u003eMost writing on this topic offers you a menu of scenarios and declines to pick one. That\u0026rsquo;s intellectually safe. It\u0026rsquo;s also not very useful.\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s what I actually think is going to happen, in roughly the order I expect it to unfold.\u003c/p\u003e\n\u003ch3 id=\"first-a-two-tier-labor-market-arriving-faster-than-expected\"\u003e\u003cstrong\u003eFirst: a two-tier labor market, arriving faster than expected\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eThis is already beginning. It won\u0026rsquo;t look like a sudden bifurcation. It will look like a gradual widening.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eOn one side\u003c/strong\u003e: engineers who have judgment, system intuition, the ability to debug things they\u0026rsquo;ve never seen before. Engineers who were formed by years of actual struggle with real systems, who can hold the architecture of a large codebase in their head, who have a feel for when something is about to go wrong before it does. \u003cstrong\u003eThese people are already scarce\u003c/strong\u003e. They will become scarcer.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eOn the other side\u003c/strong\u003e: engineers who are highly productive with AI tools, competent at composing features from components, good at moving fast. Not incapable, but shallow in ways that don\u0026rsquo;t show up until you hit a real systems problem, a production incident at 2am, a migration that needs careful sequencing across a distributed system with three years of accumulated decisions baked in.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe gap between these two groups is already visible to anyone managing teams. What changes by 2028 or so is that the gap becomes a chasm. The companies that have been running lean on senior headcount for a few years start to feel the absence. The engineers who can do the hard things become significantly more expensive. And the engineers who grew up purely on AI assistance hit ceilings they don\u0026rsquo;t fully understand.\u003c/p\u003e\n\u003cp\u003eI want to be careful here. I\u0026rsquo;m not saying the AI-native engineers are less valuable. In many roles they\u0026rsquo;ll be more than enough. But for the work that actually requires engineering judgment - and that work will still exist, probably more of it as systems become more complex - the shortage will be real.\u003c/p\u003e\n\u003ch3 id=\"second-a-talent-war-in-2029-2031-that-makes-2021-look-mild\"\u003e\u003cstrong\u003eSecond: a talent war in 2029-2031 that makes 2021 look mild\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eThe 2021-2022 hiring boom happened against a backdrop where the pipeline was still functioning. There were plenty of engineers at every level; the issue was that everyone wanted them at once.\u003c/p\u003e\n\u003cp\u003eWhat happens when you add a structural pipeline shortage to high demand? The competition concentrates at the top of the distribution. Senior engineers with genuine systems depth will be fought over by companies who realize, too late, that they don\u0026rsquo;t have enough of them. Compensation will spike in ways that feel absurd at the time. Retention will become the primary engineering leadership challenge for several years.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve been in that environment before, and it\u0026rsquo;s grinding. You spend more time on compensation strategy and counteroffers than on anything technical. Your best engineers get calls weekly. The institutional knowledge embedded in the people you\u0026rsquo;ve developed walks out the door when someone offers them a 40% raise.\u003c/p\u003e\n\u003cp\u003eThe companies that will be in the best position are the ones that kept developing engineers through the lean years, even when it felt expensive and unnecessary. They\u0026rsquo;ll have mid-levels they grew into seniors. They\u0026rsquo;ll have seniors who know their systems deeply because they\u0026rsquo;ve been there long enough to accumulate the context. Everyone else will be competing for the same thin pool of external hires.\u003c/p\u003e\n\u003ch3 id=\"third-a-correction-in-how-the-industry-thinks-about-ai-and-skill-formation-probably-around-2030-2032\"\u003e\u003cstrong\u003eThird: a correction in how the industry thinks about AI and skill formation, probably around 2030-2032\u003c/strong\u003e\u003c/h3\u003e\n\u003cp\u003eI think we will look back on the 2024-2027 period the way we now look back on the early days of GPS in cars. Remember when people thought GPS would make navigation skills obsolete? Then people started driving into lakes because they followed their satnav off a pier. There was a period of recalibration.\u003c/p\u003e\n\u003cp\u003eI expect something similar with AI and engineering skill formation. Not a rejection of the tools. The tools are genuinely transformative, and \u003cem\u003esome\u003c/em\u003e productivity gains are real. But a serious reckoning with the second-order effects.\u003c/p\u003e\n\u003cp\u003eThe evidence is already starting to accumulate. \u003ca href=\"https://stackoverflow.blog/2025/12/26/ai-vs-gen-z/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eStack Overflow\u0026rsquo;s data\u003c/a\u003e shows positive sentiment toward AI tools dropped from above 70% in 2023-2024 to 60% in 2025. A large share of developers report that debugging AI-generated code takes longer than writing code from scratch. The bugs are different: they look plausible, they often pass review, and they fail in edge cases that require understanding the system to catch.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eMy prediction is that by the early 2030s, the most forward-thinking engineering organizations will have developed explicit curricula for building judgment - not just productivity. They\u0026rsquo;ll treat AI assistance and depth-of-understanding as separate axes to develop deliberately, rather than assuming the first produces the second.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThe organizations that figure this out first will develop stronger engineers faster than the ones that don\u0026rsquo;t. Not because they reject AI, but because they use it with a clear model of what it does and doesn\u0026rsquo;t teach.\u003c/p\u003e\n\u003ch2 id=\"what-the-2035-picture-actually-looks-like\"\u003eWhat the 2035 picture actually looks like\u003c/h2\u003e\n\u003cp\u003ePut all three of these together and here\u0026rsquo;s what I think the engineering talent landscape looks like in ten years.\u003c/p\u003e\n\u003cp\u003eThe sheer number of people writing code will have expanded significantly. AI tools will have lowered the floor enough that product managers, designers, and domain experts routinely build functional software. In that sense, the optimistic \u0026ldquo;democratization\u0026rdquo; reading will have come \u003cem\u003epartially\u003c/em\u003e true.\u003c/p\u003e\n\u003cp\u003eBut the engineers who can reason about complex systems, manage large codebases over time, make architectural decisions with long-term consequences, and debug hard failures under pressure - those engineers will be a smaller proportion of the overall field than they are today. And the absolute number in that category will depend heavily on choices being made between now and 2028.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://www.infoworld.com/article/3509197/junior-developers-and-ai.html\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCharity Majors put it well\u003c/a\u003e: \u0026ldquo;Being a senior engineer is not primarily a function of your ability to write code. It has far more to do with your ability to understand, maintain, explain, and manage a large body of software in production over time.\u0026rdquo; AI has accelerated code writing significantly. It has done very little for the rest of what seniority actually means.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe companies that understand this distinction - and act on it now - will be positioned well. The ones that conflate productivity with capability will feel fine through 2027 and start hurting around 2030.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-thing-that-worries-me-most\"\u003eThe thing that worries me most\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve watched a few rounds of the industry eating its seed corn and convincing itself it was making a rational trade. The post-2022 layoffs hit engineering managers and tech leads disproportionately hard. The implicit logic was: we can run leaner, we have AI, the seniors can cover more ground.\u003c/p\u003e\n\u003cp\u003eWhat got cut in many of those rounds wasn\u0026rsquo;t just headcount. It was the connective tissue of a team: the people who did the knowledge transfer, who ran the design reviews, who had enough context to mentor early-career engineers while still shipping. When you cut that layer, you don\u0026rsquo;t see the damage immediately. You see it eighteen months later when your juniors are blocked on things nobody knows how to answer, when your senior engineers are burning out because they\u0026rsquo;re carrying the entire weight of technical decision-making alone, when the institutional knowledge that was being passed down just\u0026hellip; stops.\u003c/p\u003e\n\u003cp\u003eThe same dynamic is playing out at the junior level, and I think the timescales involved mean we won\u0026rsquo;t fully see the consequences for years. A 22-year-old who couldn\u0026rsquo;t get a job in 2024 didn\u0026rsquo;t disappear. Some of them found their way in eventually. Some changed careers. Some are brilliant engineers who just needed a different entry point.\u003c/p\u003e\n\u003cp\u003eBut there\u0026rsquo;s a cohort - I genuinely don\u0026rsquo;t know how large - who got priced out of the profession entirely during the hiring freeze. Those are the engineers who would have been mid-levels by 2028 and seniors by 2033. That pool is smaller than it should be. And the knowledge and habits they would have built during those early, formative years can\u0026rsquo;t be reconstructed later.\u003c/p\u003e\n\u003cp\u003eI find this genuinely sad, not just strategically worrying. The early years of an engineering career are formative in ways that go beyond skills. The sense of what good engineering culture looks like, the norms around code quality and documentation and incident response - these get embedded early. A generation that missed that formation is navigating its careers without a north star that many of us take for granted.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-i-think-you-should-actually-do\"\u003eWhat I think you should actually do\u003c/h2\u003e\n\u003cp\u003eThe honest answer is that individual companies can\u0026rsquo;t fix a systemic pipeline problem. If the industry collectively under-hired juniors for four years, no single organization can compensate for that. What you can do is position your team well relative to the broader shortage.\u003c/p\u003e\n\u003cp\u003eA few things I think are worth doing now, not as a checklist but as a genuine shift in how you think about talent.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTreat junior hiring as risk mitigation.\u003c/strong\u003e Not charity, not altruism. The engineers you develop over the next three years are your insurance against the talent war I think is coming. The cost of growing someone from junior to senior over four years is significantly lower than the cost of competing for experienced engineers in a constrained market. (Run that math explicitly in your planning. Leadership tends to respond better to projected future cost than to abstract arguments about pipelines. \u0026ldquo;Here\u0026rsquo;s what we\u0026rsquo;ll be paying a senior engineer in 2029 if we haven\u0026rsquo;t grown any internally\u0026rdquo; lands differently than \u0026ldquo;we should invest in people.\u0026rdquo;)\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDon\u0026rsquo;t assume the conditions for growth are present.\u003c/strong\u003e This is the part I see most managers miss. They hire a junior, point them at a Jira board, and assume the environment will do the development work. It used to. It doesn\u0026rsquo;t anymore.\u003c/p\u003e\n\u003cp\u003eThe natural friction that formed engineers - the undocumented codebase, the slow feedback loops, the production incident you had to debug with nothing but logs and intuition - has been reduced by AI tooling. That friction was annoying. It was also pedagogically essential. When you skip the struggle, you skip the part where the mental model forms.\u003c/p\u003e\n\u003cp\u003eSo you have to reconstruct the friction deliberately. Not by withholding AI tools - that\u0026rsquo;s counterproductive - but by designing the work for learning, not just output. Give people ownership of problems where the hard part is figuring out what to build, not just how to build it. Pair them on architecture discussions where the ambiguity is real. Let them run the post-incident review rather than just attending it. Make them write the runbook before the incident happens. The goal is to ensure AI is \u003ca href=\"/not-just-a-tool/\"\u003ea tool they\u0026rsquo;re steering\u003c/a\u003e, not a crutch doing the thinking.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve seen this done well a few times. The managers who do it well share a common trait: they think explicitly about what skills they\u0026rsquo;re trying to build in each person, and they choose work assignments accordingly. They\u0026rsquo;re playing a longer game than the sprint.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eInvest in making knowledge visible.\u003c/strong\u003e The institutional knowledge in your most experienced engineers\u0026rsquo; heads is the most irreplaceable asset you have. It can\u0026rsquo;t be hired externally. It degrades slowly when people leave or move into management. And most organizations have almost no systematic way to transfer it.\u003c/p\u003e\n\u003cp\u003eThe barrier to doing this has genuinely never been lower. AI makes writing, diagramming, and explaining dramatically easier. A two-hour architecture review where a senior engineer talks through a system can be transcribed, summarized, and turned into documentation before the meeting ends. What used to require significant willpower to produce can now happen almost as a side effect of normal work, if you build the habit. Make it a first-class expectation, not an optional nicety.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTrack your knowledge concentration.\u003c/strong\u003e How many people on your team can independently debug your three most critical services? What\u0026rsquo;s your bus factor on your oldest, most important codebase? If the answer to either question is \u0026ldquo;one or two,\u0026rdquo; you have a fragile organization - and the fragility compounds over time if you\u0026rsquo;re not actively moving knowledge around.\u003c/p\u003e\n\u003cp\u003eAnd if you\u0026rsquo;re an individual contributor: the gap between those who have genuine depth and those who have AI-assisted productivity will widen for the next several years. The engineers who will be most valuable are \u003cstrong\u003e\u003cem\u003enot\u003c/em\u003e\u003c/strong\u003e the ones who ship the most features today. They\u0026rsquo;re the ones who can reason about hard problems independently, who understand why systems fail, who have accumulated enough context about real software in production to have genuine instincts.\u003c/p\u003e\n\u003cp\u003eSeek the hard problems. Volunteer for the migration nobody else wants. Stay on the post-incident review long enough to actually understand what happened, not just to mark it resolved. When the AI gives you an answer, take the time to understand why it\u0026rsquo;s right - or whether it\u0026rsquo;s right at all. The discomfort of not immediately knowing is exactly where the growth happens. Don\u0026rsquo;t outsource it.\u003c/p\u003e\n\u003ch2 id=\"the-choice-thats-already-being-made\"\u003eThe choice that\u0026rsquo;s already being made\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what I keep coming back to.\u003c/p\u003e\n\u003cp\u003eThe senior engineers of 2035 are not a future problem. They are people who are somewhere in the industry right now, or who tried to enter the industry and were turned away, or who are making decisions right now about whether software engineering is a viable career. The conditions that will determine whether they develop into exceptional engineers are being created today.\u003c/p\u003e\n\u003cp\u003eEvery company that freezes junior hiring is making a choice about 2033. Every manager who stops investing in early-career development because AI covers the gap is making a choice about 2031. Every organization that measures engineering output purely in velocity without asking whether the people producing that output are growing is making a choice it won\u0026rsquo;t fully feel for years.\u003c/p\u003e\n\u003cp\u003eI think most of those choices are being made without a clear view of their consequences. Not maliciously. Just with the usual human preference for short-term clarity over long-term uncertainty.\u003c/p\u003e\n\u003cp\u003eThe irony is that the companies best positioned for 2035 won\u0026rsquo;t look obviously superior in 2026. They\u0026rsquo;ll look slightly less efficient. They\u0026rsquo;ll be carrying some overhead in the form of junior engineers who aren\u0026rsquo;t yet fully productive. Their senior engineers will spend some time on mentorship that doesn\u0026rsquo;t show up in sprint velocity.\u003c/p\u003e\n\u003cp\u003eAnd then 2029 arrives, and the talent war starts, and those are the teams that already have the people they need.\u003c/p\u003e\n","date_modified":"2026-05-08T18:37:07Z","date_published":"2026-05-08T18:37:07Z","id":"https://leadership.garden/the-senior-engineer-crisis/","summary":"AI is cutting junior hiring. But the engineers that won't exist in 10 years are being decided right now. Here's what I think actually happens next.","tags":["career","growth","hiring","ai"],"title":"The Senior Engineer Crisis Isn't Coming. It's Already Here.","url":"https://leadership.garden/the-senior-engineer-crisis/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe junior engineer on my team was great. Fast learner, sharp instincts, the kind of person who makes you feel smug about a hiring decision. Six months in, I was proud of the progress she had made.\u003c/p\u003e\n\u003cp\u003eThen she told me she was leaving.\u003c/p\u003e\n\u003cp\u003eWhen I asked why, she said something I haven\u0026rsquo;t forgotten: \u0026ldquo;I feel like I\u0026rsquo;m still waiting to do real work.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eShe wasn\u0026rsquo;t being ungrateful. She wasn\u0026rsquo;t wrong. I had run a textbook onboarding: graduated her through a learning path, assigned well-scoped tickets, shielded her from ambiguity while she \u0026ldquo;found her footing.\u0026rdquo; I had read the right blog posts, used the right frameworks, done everything a thoughtful engineering manager is supposed to do.\u003c/p\u003e\n\u003cp\u003eI had also accidentally built a school. And she had spotted it.\u003c/p\u003e\n\u003ch2 id=\"the-school-we-built-without-noticing\"\u003eThe School We Built Without Noticing\u003c/h2\u003e\n\u003cp\u003eMost engineering teams grow people with school logic.\u003c/p\u003e\n\u003cp\u003eNew engineers get a learning phase full of bounded tasks. Sprints become curriculum. Code reviews feel graded. Access still moves level by level, with someone else deciding when the next gate opens. The backlog comes with a reading list of internal wikis, architecture docs, and \u0026ldquo;\u003cem\u003ehere\u0026rsquo;s the ten things you need to understand before we trust you with anything real.\u003c/em\u003e\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eWe do this for understandable reasons. We want to lower the odds of public failure, so we remove ambiguity and sequence the hard parts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cem\u003eBut the effect is the same as any classroom: we have placed the learning before the doing.\u003c/em\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eSimon Sarris made the point well in 2024 in \u003ca href=\"https://map.simonsarris.com/p/school-is-not-enough\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eSchool Is Not Enough\u003c/a\u003e. People learn through the work itself.\u003c/p\u003e\n\u003ch2 id=\"what-the-school-model-looks-like-in-a-codebase\"\u003eWhat the school model looks like in a codebase\u003c/h2\u003e\n\u003cp\u003eOn an engineering team, the school model shows up as pre-decomposed tickets.\u003c/p\u003e\n\u003cp\u003eA senior engineer turns a project into small, bounded tasks before handing it to a junior. That feels generous. It also strips out the part of the job that grows senior judgment.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve done this plenty of times. It makes contribution easier, but it also lets the senior keep running the project. The junior executes pieces of a design someone else already made.\u003c/p\u003e\n\u003cp\u003eThat is staffing, not growth.\u003c/p\u003e\n\u003cp\u003eSenior engineers earn judgment by defining success and sizing scope. They also choose risks and explain uncertainty. They learn that by working through vague briefs, not by clearing neat tickets.\u003c/p\u003e\n\u003cp\u003eBradford Cross makes a similar point about the damage of \u0026ldquo;just take the next ticket.\u0026rdquo; The deeper problem is the model it teaches. Engineers start to think their job is execution. They wait for someone else to define the problem. Then they stall when the edges disappear.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve hired technically strong engineers from competent teams who froze the first time a problem arrived without predefined edges.\u003c/p\u003e\n\u003ch2 id=\"the-fake-work-problem\"\u003eThe Fake Work Problem\u003c/h2\u003e\n\u003cp\u003ePeople can tell when the work is fake.\u003c/p\u003e\n\u003cp\u003eStarter projects and learning tickets tell the engineer that nothing important is at stake. We assign them because they seem educational, not because the team needs them done. Engineers can feel that difference.\u003c/p\u003e\n\u003cp\u003eI saw it with two onboarding engineers. One got our standard learning path, a sequence of scoped tickets designed to build context. The other got a real project with a fuzzy brief, real users, and a deadline that mattered. I gave her a senior as a backstop and made clear that a stumble would not count against her.\u003c/p\u003e\n\u003cp\u003eThree months later, their technical knowledge was roughly similar. Their behavior was not. The engineer on real work thought about outcomes. The engineer on the learning path thought about tasks.\u003c/p\u003e\n\u003cp\u003eReal work created care; the learning path created compliance.\u003c/p\u003e\n\u003ch2 id=\"safe-is-the-most-expensive-word-in-your-vocabulary\"\u003e\u0026ldquo;Safe\u0026rdquo; Is the Most Expensive Word in Your Vocabulary\u003c/h2\u003e\n\u003cp\u003eManagers often say, \u0026ldquo;They\u0026rsquo;re not ready for that yet. Let them build confidence first.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eI think that gets the sequence wrong.\u003c/p\u003e\n\u003cp\u003eConfidence comes from surviving hard work, not from completing safe tasks. Real confidence is what lets an engineer walk into ambiguity, make a call, and stand behind it. K. Anders Ericsson\u0026rsquo;s \u003ca href=\"https://pubmed.ncbi.nlm.nih.gov/18778378/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eresearch on expert performance\u003c/a\u003e points the same way. Expertise grows at the edge of current ability, with feedback from real outcomes. Safe tasks do not produce that.\u003c/p\u003e\n\u003cp\u003eSarris puts it plainly. \u0026ldquo;It is building skill itself that builds self-possession.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eIn engineering, that shows up when someone owns an incident from detection through post-mortem. It also shows up when someone carries a project from fuzzy brief to shipped feature and handles the stakeholder conversations that come with it.\u003c/p\u003e\n\u003cp\u003eThose experiences are the development. Engineers can pick up technical facts on demand, but judgment grows when someone makes a call and then lives with the result.\u003c/p\u003e\n\u003cp\u003eWhen you shield engineers from that work, you are postponing the bill. It comes due when they are nominally senior and still have never made a hard call.\u003c/p\u003e\n\u003ch2 id=\"the-apprentice-model\"\u003eThe Apprentice Model\u003c/h2\u003e\n\u003cp\u003eThe alternative I\u0026rsquo;m reaching for isn\u0026rsquo;t \u0026ldquo;throw juniors in the deep end and see who swims.\u0026rdquo; That\u0026rsquo;s not how apprenticeships historically worked, and it\u0026rsquo;s not what I\u0026rsquo;m advocating.\u003c/p\u003e\n\u003cp\u003eThe apprentice model is different. In Verrocchio\u0026rsquo;s studio, da Vinci didn\u0026rsquo;t show up and immediately produce masterworks. He mixed pigments. He prepared canvases. He did the unglamorous, real work of an actual studio. But the work was \u003cem\u003ereal\u003c/em\u003e: not simulated, not graded, not designed for his education. It existed because the studio needed it. And he was in proximity to people doing more complex work - watching how decisions got made, occasionally doing pieces of it himself, eventually being trusted with more.\u003c/p\u003e\n\u003cp\u003eThe studio metaphor is more useful than the school metaphor for engineering teams, and I\u0026rsquo;d encourage you to spend some time with it. It also has a serious theoretical grounding: Lave and Wenger\u0026rsquo;s \u003ca href=\"https://www.cambridge.org/highereducation/books/situated-learning/6915ABD21C8E4619F750A4D4ACA616CD\" target=\"_blank\" rel=\"noopener noreferrer\"\u003esituated learning research\u003c/a\u003e found that newcomers in craft communities didn\u0026rsquo;t learn by being taught - they learned by participating, starting at the periphery and moving toward full membership as their competence grew. The community of practice was the curriculum.\u003c/p\u003e\n\u003cp\u003eIn a school, the point is the curriculum. The work exists to teach.\u003c/p\u003e\n\u003cp\u003eIn a studio, the point is the work. Learning is what happens when you do real work seriously.\u003c/p\u003e\n\u003cp\u003eYour job as an engineering manager is not to be a teacher. Teachers transfer knowledge deliberately, sequentially, to students who are temporarily exempt from the demands of the real world. That model made sense when knowledge was scarce and expertise was hard to access. It doesn\u0026rsquo;t map well to an environment where any engineer can learn almost anything on demand.\u003c/p\u003e\n\u003cp\u003eYour job is to be a studio owner. You find real work worth doing. You make sure your engineers have enough context to attempt it. You are a backstop when they go off the edge, not a railing that prevents them from going anywhere interesting.\u003c/p\u003e\n\u003cp\u003eWill Larson writes about the art of finding \u0026ldquo;safe learning projects that also provide real value to the business.\u0026rdquo; I\u0026rsquo;ve long admired how precisely Will thinks about organizational problems, and he\u0026rsquo;s right that this is an art. But I\u0026rsquo;d push back on the framing. The goal isn\u0026rsquo;t to make the project safe. The goal is to make the \u003cem\u003eenvironment\u003c/em\u003e safe for learning, which is a different thing. A project with real stakes, a patient senior as a backstop, and a manager who will not punish honest failure - that\u0026rsquo;s a safe learning environment. A project with artificially reduced complexity is just school with a paycheck.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/your-team-is-not-a-school/stakes-vs-support_hu_152883481c8e8f9f.png\"\n    srcset=\"/your-team-is-not-a-school/stakes-vs-support_hu_6cff1bb3523df9aa.webp 640w, /your-team-is-not-a-school/stakes-vs-support_hu_402e649e8b947c14.webp 960w, /your-team-is-not-a-school/stakes-vs-support_hu_66802d7fe4352d55.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"986\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"the-permissionless-principle\"\u003eThe Permissionless Principle\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a specific point Sarris makes about software that I keep returning to when I think about engineering culture.\u003c/p\u003e\n\u003cp\u003eHe argues that programming thrives because of its \u0026ldquo;permissionless culture.\u0026rdquo; You don\u0026rsquo;t need a building permit. You don\u0026rsquo;t need an audience or a patron. You don\u0026rsquo;t have to ask anyone. You can just create. He argues this is one of the reasons precocious children are drawn to it: it is one of the few domains that doesn\u0026rsquo;t make them wait.\u003c/p\u003e\n\u003cp\u003eHe\u0026rsquo;s right. And most engineering managers are quietly dismantling this.\u003c/p\u003e\n\u003cp\u003eThe permission creep is subtle. It starts with process: tickets must be groomed before you work on them, PRs need two approvals, production access requires a six-week onboarding milestone, architectural decisions require an RFC. Some of this is necessary. Infrastructure has real blast radius. But at some point, you\u0026rsquo;ve built a bureaucracy that requires explicit permission at every step, and you\u0026rsquo;ve sucked the agency out of what should be the most agentive environment in any company.\u003c/p\u003e\n\u003cp\u003eThe engineers who grow fastest are almost always the ones who don\u0026rsquo;t wait to be handed problems. They notice something broken in the codebase and fix it. They read the roadmap and find an inconsistency and bring you a proposal. They implement the improvement that wasn\u0026rsquo;t in the sprint and show you the metrics afterward. They move ahead and course-correct when needed.\u003c/p\u003e\n\u003cp\u003eYour job is not to make this harder in the name of process. Your job is to create conditions where this happens. That means being explicit about what engineers can do without permission. It means celebrating the engineer who shipped an unrequested improvement more than the engineer who waited patiently for a ticket. It means tolerating - even welcoming - a certain amount of productive noise.\u003c/p\u003e\n\u003cp\u003e(\u003cem\u003eI\u0026rsquo;ve worked at places where shipping unrequested code was a fireable offense. Those places did not grow good engineers. They grew compliant ones. Compliant is not a career outcome.\u003c/em\u003e)\u003c/p\u003e\n\u003cp\u003eThe permissionless principle also extends to how you define scope when you do assign work. Leave something undefined. Leave the hard question unanswered. Not because you\u0026rsquo;re being lazy - and this is important, because there\u0026rsquo;s a real difference between generous ambiguity and careless ambiguity - but because the act of the engineer having to find the answer is part of the education. Carnegie didn\u0026rsquo;t learn the telegraph because someone designed a learning path for him. He convinced his boss to let him try, and then he figured it out.\u003c/p\u003e\n\u003ch2 id=\"what-real-stakes-actually-feel-like\"\u003eWhat Real Stakes Actually Feel Like\u003c/h2\u003e\n\u003cp\u003eReal stakes don\u0026rsquo;t require catastrophic risk. I\u0026rsquo;m not suggesting you put a junior engineer on-call for a P0 service in their first month.\u003c/p\u003e\n\u003cp\u003eReal stakes means: the work matters. The outcome affects something real. The engineer can feel the difference between doing it well and doing it poorly, without needing a code review comment to tell them. Someone, somewhere, actually cares whether this gets done right.\u003c/p\u003e\n\u003cp\u003eIn practice, I\u0026rsquo;ve found this shows up in a few specific forms.\u003c/p\u003e\n\u003cp\u003eOne is owning a user-facing feature end to end - not just implementing the code someone else designed, but making the product decisions about scope, communicating about trade-offs with the PM, and being the person who explains in the post-release review what shipped and why.\u003c/p\u003e\n\u003cp\u003eAnother is writing the post-mortem after something they own breaks in production. This one is uncomfortable and I\u0026rsquo;ve had to resist every instinct to do it for them. But there is no substitute for the experience of writing a document that explains, to stakeholders and colleagues, what went wrong on your watch and what you\u0026rsquo;re going to do about it. It develops a kind of seriousness about reliability that no training module comes close to.\u003c/p\u003e\n\u003cp\u003eA third form, and this one is underrated: becoming the person other people route questions to. When an engineer becomes the domain expert that their colleagues ping before pinging you, something shifts. They start thinking about their work differently. They notice the edge cases at the boundary of their domain. They start caring whether the thing is actually good, not just whether it passes review.\u003c/p\u003e\n\u003cp\u003eThat shift - from executing to owning - is the thing you\u0026rsquo;re trying to produce. And it only happens when someone else depends on you for real.\u003c/p\u003e\n\u003ch2 id=\"the-senior-engineers-role-in-all-this\"\u003eThe Senior Engineer\u0026rsquo;s Role in All This\u003c/h2\u003e\n\u003cp\u003eSenior engineers often get the wrong instruction.\u003c/p\u003e\n\u003cp\u003eWe tell them to mentor juniors, review code, and stay available. That pushes them toward the role of teacher.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThe more useful framing: the senior engineer\u0026rsquo;s job is to be the studio, not the classroom. They model the work, not the curriculum.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eBring junior engineers into real decisions. When you scope a project, think out loud with them in the room. They learn how good engineers handle ambiguity by watching the work happen.\u003c/p\u003e\n\u003cp\u003eReview PRs like conversations between peers. Code review should feel like joint problem-solving, not grading.\u003c/p\u003e\n\u003cp\u003eSometimes a senior engineer has to step back and let a junior wrestle with the hard part. It is slower in the moment. It is still the better trade.\u003c/p\u003e\n\u003ch2 id=\"an-honest-note-on-ai\"\u003eAn Honest Note on AI\u003c/h2\u003e\n\u003cp\u003eI can\u0026rsquo;t write this post in 2026 without acknowledging the AI acceleration context, because I think it changes the argument slightly.\u003c/p\u003e\n\u003cp\u003eIf your theory of the world is that senior engineers are valuable primarily for their execution speed - their ability to produce correct code quickly - then you might worry that AI is compressing that value. You\u0026rsquo;d be at least partly right.\u003c/p\u003e\n\u003cp\u003eBut if your theory is that the real value of a senior engineer is \u003cem\u003ejudgment\u003c/em\u003e - knowing which problem to solve, when to push back on a product decision, how to frame a technical risk so leadership can actually reason about it, when a simple solution beats an elegant one - then AI makes the apprentice model \u003cem\u003emore\u003c/em\u003e important, not less. The work that remains most distinctively human is exactly the work you can only learn by doing it under real conditions.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eTraining an engineer to complete pre-defined tasks is now, more than it has ever been, a mistake.\u003c/strong\u003e The tasks are the part that will be automated. The judgment is the part that won\u0026rsquo;t be. And judgment only grows through experience with real stakes.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"what-to-actually-change\"\u003eWhat to Actually Change\u003c/h2\u003e\n\u003cp\u003e\u003cstrong\u003eStop pre-decomposing everything.\u003c/strong\u003e When you\u0026rsquo;re tempted to break a project into tasks before handing it to a junior, ask yourself: what\u0026rsquo;s the minimum scoping I can do here and still have this be viable? Can I give them the (sub)problem instead of the tasks? What do they need to know, and what is it more valuable for them to discover?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGive ownership of outcomes, not activities.\u003c/strong\u003e \u0026ldquo;You own the reliability of this service\u0026rdquo; is different from \u0026ldquo;you own the on-call rotation for this service.\u0026rdquo; The first creates an engineer who thinks about the system. The second creates an engineer who rotates through tasks and runbooks. The language you use sets the frame for how people think about their work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMake the stakes visible.\u003c/strong\u003e Engineers often don\u0026rsquo;t know that what they\u0026rsquo;re working on matters to real people. They don\u0026rsquo;t know the customer has been complaining about this bug for six months. They don\u0026rsquo;t know the PM has been asking for this feature in every planning meeting for a year. Tell them. Let the real weight of the work land. Some engineers will rise to it. The ones who don\u0026rsquo;t are telling you something useful early. Of course, do this in a safe environment, acknowledging what\u0026rsquo;s actually feasible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eExplicitly carve out permissionless space.\u003c/strong\u003e Tell your team: if you see something broken and you have a fix, ship it. If you have an idea for an improvement that fits in an afternoon, try it. Make a clear distinction between \u0026ldquo;things you can do without asking\u0026rdquo; and \u0026ldquo;things that need coordination,\u0026rdquo; and make the first category as large as possible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eBring people into the room when decisions get made.\u003c/strong\u003e When you\u0026rsquo;re making a hard call about technical direction or navigating a difficult stakeholder conversation, bring a junior engineer with you. Not to vote, but to watch. They should see how a good engineer handles a situation that isn\u0026rsquo;t clean. You will teach them more in that hour than in a month of tickets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMake the onboarding project real.\u003c/strong\u003e This one is uncomfortable. It\u0026rsquo;s tempting to design a perfect starter project: safe, bounded, non-critical, pedagogically structured. Resist it. The best onboarding projects are the ones where the engineer is doing a thing that actually needs to happen, and someone else on the team genuinely cares whether it gets done well. The sense of contribution has to be real. Fake contribution produces fake confidence, and fake confidence is worse than no confidence because it\u0026rsquo;s invisible until it fails.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThere\u0026rsquo;s a question underneath all of this that\u0026rsquo;s worth sitting with honestly: what are you actually trying to produce?\u003c/p\u003e\n\u003cp\u003eIf the answer is \u0026ldquo;engineers who can reliably complete the tasks on their backlog,\u0026rdquo; the school model is fine. It\u0026rsquo;s efficient. It produces people who are skilled at defined tasks and comfortable in defined environments.\u003c/p\u003e\n\u003cp\u003eIf the answer is \u0026ldquo;engineers who can figure out what to build and why, who can navigate genuine ambiguity, who can grow into senior and staff roles and eventually solve problems you haven\u0026rsquo;t encountered yet\u0026rdquo; - then you need something different.\u003c/p\u003e\n\u003cp\u003eSarris writes that \u0026ldquo;the purpose of education is to develop agency within a child. Purposeful work and achieving mastery are tools to getting there. They aren\u0026rsquo;t the results of learning and imagination, it\u0026rsquo;s the other way around.\u0026rdquo; Swap \u0026ldquo;child\u0026rdquo; for \u0026ldquo;engineer\u0026rdquo; and you\u0026rsquo;ve described what most of us should be doing differently.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eAgency is learnable. But only through agency. You cannot teach it by proxy. The engineer who spends three years completing pre-decomposed tickets has learned to complete pre-decomposed tickets. The engineer who spends three years owning real problems has learned to own real problems.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThat\u0026rsquo;s the only kind of growth that actually transfers.\u003c/p\u003e\n","date_modified":"2026-05-01T12:13:11Z","date_published":"2026-05-01T12:13:11Z","id":"https://leadership.garden/your-team-is-not-a-school/","summary":"Your team is not a school. You are not a teacher. The studio model is what actually grows engineers, and most of us are running classrooms.","tags":["growth","teams"],"title":"Your Team Is Not a School","url":"https://leadership.garden/your-team-is-not-a-school/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eI got my first proper 360 report in my first year as an engineering manager. Forty-two pages. Color-coded charts. Numerical breakdowns by relationship type - peers, directs, stakeholders. Someone had clearly put a lot of work into this thing.\u003c/p\u003e\n\u003cp\u003eI read it in a single sitting, highlighted maybe a dozen items, had a somewhat uncomfortable conversation with my manager, and filed it in a folder labeled \u0026ldquo;Development - 2015.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eI changed nothing. My manager never followed up. The folder still exists somewhere in a Google Drive I no longer have access to.\u003c/p\u003e\n\u003cp\u003eI share this not because I\u0026rsquo;m uniquely bad at follow-through - though I\u0026rsquo;ve had my moments - but because this is the almost universal experience of 360 feedback in most organizations. The data gets collected. The report gets generated. And then everyone quietly moves on and acts surprised twelve months later when the same themes show up in the next cycle.\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a better way. But I want to challenge something first.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-dirty-secret-nobody-talks-about\"\u003eThe Dirty Secret Nobody Talks About\u003c/h2\u003e\n\u003cp\u003eMost 360 improvement advice focuses entirely on the behavior change side of the equation. Get specific. Build habits. Track your progress. Find an accountability partner. And yes, all of that matters.\u003c/p\u003e\n\u003cp\u003eBut there\u0026rsquo;s a second problem nobody addresses, and it\u0026rsquo;s the one that kills most genuine improvement efforts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eYou can actually change, and nobody notices.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eHere\u0026rsquo;s what happens. Let\u0026rsquo;s say your 360 surfaces that you\u0026rsquo;re perceived as dismissive in meetings - you cut people off, move on before ideas are fully heard, visibly check out when the conversation leaves your domain. You take that seriously. You build a real practice around it. You stop interrupting. You ask follow-up questions. You let meetings breathe.\u003c/p\u003e\n\u003cp\u003eThree months later, your directs still think of you as dismissive.\u003c/p\u003e\n\u003cp\u003eNot because they\u0026rsquo;re cruel or unobservant. Because the human brain doesn\u0026rsquo;t naturally run a continuous reassessment of the people it has already formed opinions about. Confirmation bias is aggressive. Once someone has filed you under \u0026ldquo;dismissive leader,\u0026rdquo; their brain will continue to notice evidence that confirms that label and unconsciously minimize evidence that doesn\u0026rsquo;t. They\u0026rsquo;ll remember the one time you cut someone off and forget the six times you didn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://pubmed.ncbi.nlm.nih.gov/10707330/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003espotlight effect\u003c/a\u003e makes it worse. You think people are paying close attention to your behavior. They\u0026rsquo;re not. They\u0026rsquo;re busy. They\u0026rsquo;re focused on themselves. They\u0026rsquo;re managing their own careers and their own anxieties. Your deliberate change registers to you as a major life event. To your peers, it barely registers at all.\u003c/p\u003e\n\u003cp\u003eThis is why behavior change is actually two jobs. There\u0026rsquo;s the change itself - the specific, disciplined work of doing things differently. And then there\u0026rsquo;s the social work of making sure the people who formed their opinion of you actually get a chance to update it.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eMost people only do the first job. This is why most 360 improvement efforts quietly die.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"choose-who-gets-to-watch-you-change\"\u003eChoose Who Gets to Watch You Change\u003c/h2\u003e\n\u003cp\u003eThe standard 360 advice on rater selection goes something like this: pick a diverse group, avoid people who like you too much, aim for seven to fifteen respondents. It\u0026rsquo;s fine advice if your goal is collecting valid data.\u003c/p\u003e\n\u003cp\u003eBut if your goal is actually changing your reputation - which is what you\u0026rsquo;re trying to do, whether you admit it or not - the selection criteria are different.\u003c/p\u003e\n\u003cp\u003eI now think about rater selection in terms of two questions.\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eFirst\u003c/strong\u003e: who gave me this feedback? If your directs told you they don\u0026rsquo;t feel heard, those directs need to be in the group. If your peers said you\u0026rsquo;re hard to collaborate with, include the peer who said it most loudly. The people who have the most charged version of the old story about you are exactly the people whose updated story matters most.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecond\u003c/strong\u003e: who do I actually want to influence? This is the question most people don\u0026rsquo;t ask out loud, but it\u0026rsquo;s real. Changing how your directs experience you matters. Changing how a senior cross-functional partner experiences you matters. Both have career implications. Both affect your day-to-day work environment. There is nothing cynical about being intentional here - it\u0026rsquo;s just honest about what\u0026rsquo;s actually at stake.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe right number is smaller than most people think. Three to seven people. Enough that patterns can emerge, small enough that the relationships are real. A group of fifteen reviewers sounds thorough. In practice, it means your change effort is scattered across too many relationships to go deep with any of them.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"not-all-feedback-deserves-your-commitment\"\u003eNot All Feedback Deserves Your Commitment\u003c/h2\u003e\n\u003cp\u003eWhen the feedback comes back, the instinct is to treat it like a verdict. Nobody told me what I\u0026rsquo;m about to tell you, and I wish someone had. Someone said you\u0026rsquo;re impatient, so now you\u0026rsquo;re working on patience. Someone said you don\u0026rsquo;t delegate enough, so delegation goes on the list. Someone said you need to be more strategic, so you add \u0026ldquo;be more strategic\u0026rdquo; to your development plan and promptly have no idea what to do with it.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve sat in enough conversations with people reading their 360 reports to know what this looks like in practice. It\u0026rsquo;s someone staring at a printout, feeling a low-grade shame spiral, and trying to figure out which version of themselves they need to become in order to satisfy every piece of input on the page.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s not development. That\u0026rsquo;s self-erasure.\u003c/p\u003e\n\u003cp\u003eThe more useful move is to go line by line and consciously sort each piece of feedback into one of three buckets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSign it.\u003c/strong\u003e This is real. You recognize it. You want to change it. When you sit with it honestly, it describes something you\u0026rsquo;ve half-known about yourself for years. Commit fully. These are your actual development targets.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eRealign it.\u003c/strong\u003e The underlying point is valid, but the framing doesn\u0026rsquo;t fit who you are or how you work. \u0026ldquo;Be less blunt\u0026rdquo; might become \u0026ldquo;choose the right moments for directness.\u0026rdquo; Same direction, different execution. You\u0026rsquo;re not declining the feedback - you\u0026rsquo;re translating it into something authentic enough that you\u0026rsquo;ll actually do it.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDecline it.\u003c/strong\u003e This exists. Some feedback conflicts with your values. Some of it reflects someone else\u0026rsquo;s preferences more than your actual impact. Some of it is asking you to be a different person, not a better version of the person you are. Fake commitments never produce real change - they produce polished performance of change until the performance becomes exhausting and you stop. Better to be honest with yourself about what you\u0026rsquo;ll actually do.\u003c/p\u003e\n\u003cp\u003eThis is harder than it sounds, because \u0026ldquo;decline\u0026rdquo; can easily become \u0026ldquo;I\u0026rsquo;m too proud to hear difficult feedback.\u0026rdquo; The way I try to tell the difference: am I declining because this doesn\u0026rsquo;t fit how I work, or am I declining because it\u0026rsquo;s uncomfortable? The first is legitimate. The second is ego.\u003c/p\u003e\n\u003cp\u003eWhen you\u0026rsquo;ve sorted honestly, you probably have two or three real commitments. Maybe four. That\u0026rsquo;s the right number. Enough to work on meaningfully, few enough to actually track.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"be-more-strategic-is-not-a-behavior\"\u003e\u0026ldquo;Be More Strategic\u0026rdquo; Is Not a Behavior\u003c/h2\u003e\n\u003cp\u003eWe cannot change concepts. We can only change specific, observable actions.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Be more strategic\u0026rdquo; is a concept. \u0026ldquo;Send a written summary after every major decision that includes the business rationale and trade-offs\u0026rdquo; is an action. \u0026ldquo;Be less emotional\u0026rdquo; is a concept. \u0026ldquo;Wait twenty-four hours before responding to any message that triggers a strong reaction\u0026rdquo; is an action. \u0026ldquo;Be a better communicator\u0026rdquo; is a concept. \u0026ldquo;Open every one-on-one by naming one specific thing the person did well since we last spoke\u0026rdquo; is an action.\u003c/p\u003e\n\u003cp\u003eThe action version has three properties that matter. You can do it - it\u0026rsquo;s concrete enough to execute, not just intend. You can schedule it - it has a natural trigger, a context in which it occurs. You can track it - at the end of the week, you either did it or you didn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve found it helps to use your own history of successful change here. Think about something you actually changed about how you work. Not what you planned to change - what you actually changed and sustained. What made that work? Some people build habits through streaks and tracking. Some do it through social commitment. Some need to tie new behaviors to existing routines. Whatever worked before is the system worth applying here.\u003c/p\u003e\n\u003cp\u003eThe failure mode is making this step too conceptual. A development plan that says \u0026ldquo;I will work on strategic communication in my leadership interactions\u0026rdquo; is not a plan. It\u0026rsquo;s an intention dressed up as a plan. The question to keep asking until you can\u0026rsquo;t subdivide anymore: what will I actually do, when, and how will I know if I did it?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eYou might be interested in \u003ca href=\"https://leadership.garden/goal-setting/\"\u003emy earlier post about goal setting\u003c/a\u003e.\u003c/strong\u003e\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-step-that-changes-everything\"\u003eThe Step That Changes Everything\u003c/h2\u003e\n\u003cp\u003eThis is the part most people skip. It\u0026rsquo;s also the single most important thing you can do.\u003c/p\u003e\n\u003cp\u003eGo back to your feedback givers individually. Before you\u0026rsquo;ve done all the work. Before you\u0026rsquo;ve accumulated a track record of change. Early, when you\u0026rsquo;re still in the uncomfortable place of having heard the feedback and not yet having responded to it.\u003c/p\u003e\n\u003cp\u003eTell them what you heard. Tell them what you\u0026rsquo;re committing to change. Tell them where you\u0026rsquo;d like their help.\u003c/p\u003e\n\u003cp\u003eThat last part matters. Help is not the same as accountability. \u0026ldquo;Hold me accountable\u0026rdquo; sounds serious, but it puts the relationship into an evaluative frame. \u0026ldquo;I\u0026rsquo;d like your help\u0026rdquo; is vulnerable. It acknowledges that you can\u0026rsquo;t do this alone. Almost no one will refuse a genuine ask for help.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhat you\u0026rsquo;re specifically asking for is simple: if you see me doing this well, tell me. If you see me drifting back, tell me that too.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eThis does two things, and the less obvious one matters more.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eObviously, it creates a feedback loop that most change efforts don\u0026rsquo;t have. You\u0026rsquo;re no longer trying to self-assess whether you\u0026rsquo;re improving while simultaneously doing the thing you\u0026rsquo;re trying to improve. You have real-time input from people who were close enough to the original problem to notice the change.\u003c/p\u003e\n\u003cp\u003eLess obviously, you\u0026rsquo;re nudging the other person to pay attention. Not manipulating them - just acknowledging that they\u0026rsquo;re busy and their brain isn\u0026rsquo;t running continuous reassessments of your leadership on its own. When someone knows you\u0026rsquo;re working on something and has agreed to watch for it, they actually watch for it. When they see it, they update their mental model of you. When they update their mental model of you, your reputation shifts.\u003c/p\u003e\n\u003cp\u003eThis is the mechanism by which genuine change actually becomes visible. It doesn\u0026rsquo;t happen automatically. It happens because you made it possible for the update to occur.\u003c/p\u003e\n\u003cp\u003e(I realize this sounds almost embarrassingly obvious when described this way. But I\u0026rsquo;ve been in enough post-360 planning conversations to know that the vast majority of leaders never do this step. They do their work in private and hope someone notices.)\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-problem-with-motivation\"\u003eThe Problem With Motivation\u003c/h2\u003e\n\u003cp\u003eThe period immediately after receiving feedback is the worst time to judge your own commitment. I\u0026rsquo;ve learned this the hard way.\u003c/p\u003e\n\u003cp\u003eIn the first few days after a difficult 360, motivation is often genuinely high. The feedback is fresh. The gap between who you are and who you want to be feels vivid and real. You\u0026rsquo;ve had the uncomfortable conversation. You\u0026rsquo;ve made a plan. You\u0026rsquo;re going to do this.\u003c/p\u003e\n\u003cp\u003eSix weeks later, the motivation has faded. The work is the same. The initial discomfort that drove the commitment has worn off. There are a hundred other things demanding your attention. And the change effort quietly dies.\u003c/p\u003e\n\u003cp\u003eThis is not a character flaw. It\u0026rsquo;s how humans work. The mistake is designing a change effort that depends on motivation staying high, when motivation is by definition a depletable resource.\u003c/p\u003e\n\u003cp\u003eWhich is why the behavior change work needs a system that functions independently of how motivated you happen to feel on any given week.\u003c/p\u003e\n\u003cp\u003eThere are a few approaches that actually work here. The simplest is self-scoring: at the end of every week, for each commitment you\u0026rsquo;ve made, just answer yes or no. Did you do what you said you\u0026rsquo;d do? Not a narrative. Not a reflection. Just a score. The score creates a feedback loop that\u0026rsquo;s honest in a way that intentions rarely are.\u003c/p\u003e\n\u003cp\u003eIf you want to go further - and I think this is underutilized - feed your meeting recordings or transcripts into an AI tool against your stated commitments. Ask it to score your behavior week to week. It\u0026rsquo;s cheap. It\u0026rsquo;s consistent. It has no personal history with you and no interest in protecting your feelings. I\u0026rsquo;ve used this myself and it surfaces things that I was convinced I had addressed and hadn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eThe minimum viable version of this is ten minutes every Friday. Am I making progress? What got in the way? What will I do differently next week? That\u0026rsquo;s it. Ten minutes to maintain the loop. Most people won\u0026rsquo;t even do that.\u003c/p\u003e\n\u003cp\u003eOh, by the way, I\u0026rsquo;ve \u003ca href=\"https://leadership.garden/motivation-and-engineering-management/\"\u003ewritten about motivation\u003c/a\u003e in the past.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-youre-actually-trying-to-do\"\u003eWhat You\u0026rsquo;re Actually Trying to Do\u003c/h2\u003e\n\u003cp\u003eI want to be direct about the goal here, because I think it often gets obscured by the development language that surrounds 360 feedback.\u003c/p\u003e\n\u003cp\u003eYou are not trying to optimize your survey scores in the next cycle. You are not trying to satisfy HR\u0026rsquo;s annual process. You are not even, primarily, trying to become a better leader in the abstract.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eYou are trying to build a better reputation, earned through genuine change, with the specific people who matter to your work.\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThat sounds mercenary if you say it out loud, so people usually don\u0026rsquo;t. But it\u0026rsquo;s the honest description of what\u0026rsquo;s at stake.\u003c/p\u003e\n\u003cp\u003eTo be clear: I\u0026rsquo;m not arguing that reputation is the only reason to do this work, or even the primary one. Genuine growth - actually becoming less reactive, more communicative, more present as a leader - matters independently of whether anyone notices. The people who benefit from your change don\u0026rsquo;t care why you made it. Your directs don\u0026rsquo;t need to know you were motivated by a 360 report. The improvement in how you lead them is real regardless.\u003c/p\u003e\n\u003cp\u003eBut \u003cstrong\u003e\u003cem\u003ecaring about reputation isn\u0026rsquo;t vanity\u003c/em\u003e\u003c/strong\u003e. It\u0026rsquo;s something more specific and more defensible than that. The people giving 360 feedback are working from a handful of data points — more than most recipients realize. Marcus Buckingham made a version of this argument in his \u003ca href=\"https://hbr.org/2011/10/the-fatal-flaw-with-360-survey\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e2011 HBR piece on 360 surveys\u003c/a\u003e - when someone rates your behavior, what they\u0026rsquo;re actually measuring is their own experience of you relative to themselves, not some objective truth. Your peer who said you\u0026rsquo;re hard to collaborate with probably formed that impression from three or four interactions - maybe a contentious roadmap meeting, a Slack exchange that landed wrong, a moment where you pushed back harder than the situation warranted. That\u0026rsquo;s it. Three interactions, out of hundreds, now generalized into a label that will follow you through every future interaction with that person.\u003c/p\u003e\n\u003cp\u003eThis is not a flaw in 360 feedback. It\u0026rsquo;s how human beings form impressions - quickly, from thin evidence, and then self-confirmingly. Buckingham and Goodall\u0026rsquo;s \u003ca href=\"https://hbr.org/2019/03/the-feedback-fallacy\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eFeedback Fallacy piece in HBR\u003c/a\u003e puts it well: when someone rates you, the data reflects their own perceptions and filters at least as much as it reflects your actual behavior. The feedback you received was based on incomplete data, because all feedback always is. Which means the label attached to you may be accurate in what it observed and still be a significant distortion of who you actually are and how you typically show up. Actively working to update that picture isn\u0026rsquo;t reputation management in the PR sense. It\u0026rsquo;s asking for a fair assessment based on a fuller data set.\u003c/p\u003e\n\u003cp\u003eBut I\u0026rsquo;ve watched too many people do real, honest personal development work and then wonder why nothing seems to have shifted in how they\u0026rsquo;re perceived or treated. The work was real. The gap was in understanding that behavioral change and reputation change are two separate processes, and one doesn\u0026rsquo;t automatically produce the other. \u003cstrong\u003e\u003cem\u003eYour reputation is not your personality or your intentions - it\u0026rsquo;s the story other people tell about you when you\u0026rsquo;re not in the room\u003c/em\u003e\u003c/strong\u003e. That story determines whether talented people want to work with you, whether senior leaders trust you with bigger problems, whether your directs give you their real work or their performance of their real work.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cem\u003e360 feedback, at its best, gives you a rare honest look at what that story currently sounds like.\u003c/em\u003e\u003c/strong\u003e It\u0026rsquo;s a gift, even when it doesn\u0026rsquo;t feel like one. But the data is only the starting point. What comes after - the sorting, the behavioral translation, the uncomfortable conversations, the system, the discipline - that\u0026rsquo;s where the actual work is.\u003c/p\u003e\n\u003cp\u003eMost organizations treat the feedback collection as the thing. The collection is nothing. It\u0026rsquo;s expensive data you paid for and then filed.\u003c/p\u003e\n\u003cp\u003eThe change is the thing. The change that specific, real people in your actual work context will see, recognize, and update their picture of you based on.\u003c/p\u003e\n\u003cp\u003eEverything else is just expensive data you collected.\u003c/p\u003e\n\u003cp\u003eAnd those conversations you hoped you\u0026rsquo;d never have to have again? They don\u0026rsquo;t go away because you survived one review cycle. They come back, slightly reworded, with the same underlying truth about how you\u0026rsquo;re showing up.\u003c/p\u003e\n\u003cp\u003eUntil you actually do the second job.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003e\u003cem\u003eIf this resonated, I write about engineering leadership, feedback systems, and the parts of management nobody puts in the job description. New post every week.\u003c/em\u003e\u003c/p\u003e\n","date_modified":"2026-04-24T09:07:32Z","date_published":"2026-04-24T09:07:32Z","id":"https://leadership.garden/why-your-360-feedback-isnt-working/","summary":"Most 360 feedback fails not because leaders don't try to change, but because changed behavior doesn't automatically update other people's mental models.","tags":["feedback","management"],"title":"Why Your 360 Feedback Isn't Working","url":"https://leadership.garden/why-your-360-feedback-isnt-working/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThere\u0026rsquo;s a debate happening right now about whether AI makes engineering better or worse. I think it\u0026rsquo;s the wrong debate. The better question is: what was your engineering like \u003cem\u003ebefore\u003c/em\u003e AI showed up?\u003c/p\u003e\n\u003cp\u003eBecause AI doesn\u0026rsquo;t have opinions about quality. It doesn\u0026rsquo;t care whether your team writes clear specs, runs rigorous reviews, or actually validates what it ships. It just moves faster in whichever direction you were already pointed. If you were building carefully, it helps you build carefully, faster. If you were cutting corners, it helps you cut corners at scale.\u003c/p\u003e\n\u003cp\u003eAI is an amplifier. And most engineering leaders haven\u0026rsquo;t stopped to ask what exactly they\u0026rsquo;re amplifying.\u003c/p\u003e\n\u003ch2 id=\"the-amdahls-law-problem\"\u003eThe Amdahl\u0026rsquo;s Law Problem\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://en.wikipedia.org/wiki/Amdahl%27s_law\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eAmdahl\u0026rsquo;s Law\u003c/a\u003e is usually invoked in conversations about parallelism: if only part of a task can be sped up, the overall speedup is limited by the part that can\u0026rsquo;t. It applies just as cleanly here, and I haven\u0026rsquo;t seen enough people make this argument explicitly.\u003c/p\u003e\n\u003cp\u003eGood engineering requires that you actually understand and validate what the AI produces. Bad engineering skips that step. When you shorten only the steps that don\u0026rsquo;t require deep validation, you give a proportionally bigger speedup to the engineers who weren\u0026rsquo;t validating anyway.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe gap between good and bad engineering just got wider.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis reframes the whole conversation. The question isn\u0026rsquo;t whether AI produces good or bad code. It\u0026rsquo;s whether the humans using it are doing the hard work of understanding what came out. That work, reading carefully, reasoning about behavior, catching drift before it compounds into something unmanageable, isn\u0026rsquo;t something AI speeds up at all. It requires the same concentration it always did. Probably more, because there\u0026rsquo;s simply more code to read.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003ca href=\"https://leadership.garden/ai-the-work-moved/\"\u003eThe bottleneck moved\u003c/a\u003e. Most teams haven\u0026rsquo;t noticed yet.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003ch2 id=\"the-incentive-problem-is-worse-than-the-tool-problem\"\u003eThe Incentive Problem Is Worse Than the Tool Problem\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve watched something uncomfortable happen in teams over the past year: engineers who were doing genuinely good work before AI have since opted to ship three times as much mediocre work, rather than ten percent more excellent work.\u003c/p\u003e\n\u003cp\u003eI don\u0026rsquo;t blame them. That\u0026rsquo;s a rational response to incentives.\u003c/p\u003e\n\u003cp\u003eIf your delivery culture rewards velocity over correctness, if your code review is a rubber stamp, if nobody tracks alignment between what was specified and what was actually built, then of course engineers will use AI to go faster rather than go deeper. You built a system that rewards throughput. They\u0026rsquo;re delivering throughput. The tool is just making the mismatch more visible.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve seen this in review meetings. PRs are bigger, they arrive faster, and the diff makes less intuitive sense because nobody fully authored it. The reviewer is now reconstructing intent from generated output, which is a harder cognitive task than reviewing code a human wrote with full knowledge of the surrounding system. You\u0026rsquo;ve shifted the cognitive load downstream without changing downstream capacity.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThat is a leadership problem. Not an AI problem.\u003c/strong\u003e\u003c/p\u003e\n\u003ch2 id=\"spec-drift\"\u003eSpec Drift\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a phenomenon I\u0026rsquo;ve started calling \u003ca href=\"https://leadership.garden/verification-debt\"\u003everification debt\u003c/a\u003e, related to but distinct from the technical debt most of us are already tracking. Technical debt is visible, at least in principle: you can point at the legacy module, the missing abstraction, the thing you\u0026rsquo;re going to fix next quarter. Verification debt is more insidious. It lives in the gap between what you think the system does and what it actually does.\u003c/p\u003e\n\u003cp\u003eThe mechanism is straightforward. When code can be produced faster than the thinking that should precede it, you get more code and proportionally less specification. The shape of the system changes before anyone has updated the mental model of the system. Tests written against an earlier version of intended behavior now verify the wrong things, or nothing meaningful at all. Spec, tests, and implementation quietly drift apart.\u003c/p\u003e\n\u003cp\u003eAI is exceptional at creating that gap without obvious warning signs, because the code it produces often looks correct, compiles cleanly, and passes existing tests. The problem is invisible until it isn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://dora.dev/research/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eDORA research\u003c/a\u003e has consistently shown that the highest-performing engineering teams combine speed with stability, and that stability is primarily a function of process discipline: clear change management, reliable testing, and fast recovery mechanisms. None of that comes from the tool. All of it comes from the conditions leaders create. AI changes the speed at which code enters the system. It doesn\u0026rsquo;t change what happens when that code is misaligned.\u003c/p\u003e\n\u003cp\u003eThe solution isn\u0026rsquo;t to use AI less. It\u0026rsquo;s to treat specification and alignment as first-class engineering work, which most teams still don\u0026rsquo;t.\u003c/p\u003e\n\u003ch2 id=\"the-four-questions-you-should-be-asking-your-teams\"\u003eThe Four Questions You Should Be Asking Your Teams\u003c/h2\u003e\n\u003cp\u003eI want to be concrete, because \u0026ldquo;strengthen your engineering process\u0026rdquo; is the kind of advice that sounds good and changes nothing.\u003c/p\u003e\n\u003cp\u003eWhen I look at how AI is actually changing the work, four questions separate teams that are getting stronger from those quietly accumulating debt:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eWho owns the specification?\u003c/strong\u003e Not the AI. Not the product manager via a ticket. Somebody on the engineering side has to be accountable for a written, current description of what the system is supposed to do. If that document doesn\u0026rsquo;t exist, or nobody reads it, or it hasn\u0026rsquo;t been touched in months, you are flying blind. AI makes that worse by an order of magnitude.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eWhat does your code review actually verify?\u003c/strong\u003e If the answer is \u0026ldquo;roughly whether it does what the PR description says,\u0026rdquo; that\u0026rsquo;s not enough anymore. Reviewers need to be asking: does this change preserve the alignment of the system? Does the behavior described in the spec still match the behavior in the tests? Does the test still mean something? \u003ca href=\"https://google.github.io/eng-practices/review/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGood code review\u003c/a\u003e has always required this. AI makes skipping it far more costly.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eIs validation a gate or a formality?\u003c/strong\u003e Teams treating a green CI pipeline as a proxy for correctness have been getting away with it for years. With AI-generated code, it becomes actively dangerous, because the AI will write tests that pass without validating much. A passing test suite is not evidence of a correct system. It\u0026rsquo;s evidence of a test suite that passes. Those are different things. \u003ca href=\"https://charity.wtf/2021/02/04/testing-in-the-twenties/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCharity Majors has written about this\u003c/a\u003e more sharply than I can: testing strategy has to be intentional or it\u0026rsquo;s just confidence theater.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eAre your engineers slowing down anywhere?\u003c/strong\u003e This is the most important question and the hardest to answer honestly. AI lets people move faster across the board. The engineers using it well are choosing to spend some of that reclaimed time going deeper: on design, on review, on genuine understanding of what they\u0026rsquo;re shipping. The engineers who aren\u0026rsquo;t are spending all of it on velocity. You can usually tell which is which by looking at their PRs over the last three months. The question is whether you\u0026rsquo;re looking.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"the-leaders-job-didnt-get-simpler\"\u003eThe Leader\u0026rsquo;s Job Didn\u0026rsquo;t Get Simpler\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a fantasy version of AI in software engineering where the machines write the code and humans do the \u0026ldquo;interesting parts.\u0026rdquo; I find this fantasy genuinely appealing. I also think it fundamentally misunderstands what the interesting parts are.\u003c/p\u003e\n\u003cp\u003eThe interesting parts of software engineering aren\u0026rsquo;t \u0026ldquo;above\u0026rdquo; the code. They\u0026rsquo;re tangled up with it. The judgment about whether a behavior is correct requires understanding the system. The decision about which tradeoff to make requires understanding both the tradeoff and its downstream consequences. Those things require someone who has built an accurate mental model of what the system is actually doing. AI doesn\u0026rsquo;t build that model. It generates statistically plausible code based on what similar systems have looked like before.\u003c/p\u003e\n\u003cp\u003eYour engineers are still the ones who have to build that model. Your job is to create the conditions in which they actually do.\u003c/p\u003e\n\u003cp\u003eThat means resisting the pressure to measure productivity by output volume alone. (I know that\u0026rsquo;s hard when your own leadership is looking at deployment frequency and feature counts. I\u0026rsquo;m not pretending otherwise.) It means maintaining review processes that have real teeth, even when it slows things down. It means insisting on specs that are current and owned. It means asking, regularly, whether your team understands the systems they\u0026rsquo;re shipping, or whether they\u0026rsquo;re shepherding code they couldn\u0026rsquo;t fully explain under pressure.\u003c/p\u003e\n\u003cp\u003e\u003ca href=\"https://lethain.com/sustainable-pace/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eWill Larson\u0026rsquo;s framing on sustainable pace\u003c/a\u003e applies here too: the teams that compound over time are the ones who build durable understanding, not just durable output. AI can help you build output faster. It cannot substitute for the understanding.\u003c/p\u003e\n\u003cp\u003eI don\u0026rsquo;t think those leadership responsibilities changed because of AI. I think AI made the consequences of ignoring them arrive faster.\u003c/p\u003e\n\u003ch2 id=\"a-note-on-the-historical-cycle-argument\"\u003eA Note on the Historical Cycle Argument\u003c/h2\u003e\n\u003cp\u003eThe \u0026ldquo;we\u0026rsquo;ve seen this before\u0026rdquo; argument is popular right now, and it\u0026rsquo;s not wrong. Every decade has had its version of \u0026ldquo;expertise is no longer necessary\u0026rdquo;: fourth-generation languages, CASE tools, visual programming environments, offshore arbitrage. And every time, the complexity was still there waiting, deferred and disguised but not dissolved.\u003c/p\u003e\n\u003cp\u003eThat pattern will hold this time too. The interesting question isn\u0026rsquo;t whether complexity will reassert itself. It will. The interesting question is: when it does, will your team have the skills and the discipline to handle it? Or will you have spent two years in a mode where nobody had to think that hard, and you\u0026rsquo;re now facing a hairball that nobody really understands?\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s not a question for your engineers. That\u0026rsquo;s a question for you.\u003c/p\u003e\n\u003ch2 id=\"what-id-actually-change\"\u003eWhat I\u0026rsquo;d Actually Change\u003c/h2\u003e\n\u003cp\u003eIf I were designing this from scratch today, three things would be non-negotiable.\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003e\u003cstrong\u003eFirst\u003c/strong\u003e: every meaningful service or domain gets a living spec document, written in plain language, that engineers are expected to read before touching the code and update before merging changes. Not a wiki page nobody has opened in a year. A document with a named owner, reviewed on a cadence. The act of writing down what a system should do is not bureaucracy. It\u0026rsquo;s the forcing function that makes verification possible.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eSecond\u003c/strong\u003e: code review checklists get updated to explicitly ask about behavioral alignment. Not just \u0026ldquo;does this work\u0026rdquo; but \u0026ldquo;does this still match what we said it should do.\u0026rdquo; That question forces someone to look at the spec. The spec forces someone to update it if the behavior changed intentionally. That loop, closed deliberately, is what keeps spec drift from compounding.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eThird\u003c/strong\u003e: I\u0026rsquo;d track verification debt the same way I\u0026rsquo;d track technical debt, named, visible, in the backlog. When tests are superficial, when specs are stale, when nobody can clearly articulate what a system is supposed to do, that gets surfaced explicitly. Not because I\u0026rsquo;m idealistic about backlogs, but because naming something changes how seriously a team takes it. Invisible debt grows. Named debt gets paid down.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eNone of this is complicated. None of it is new. It\u0026rsquo;s the work good engineering has always required. The difference is that without it, AI will surface the gap much, much faster.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eAmplifiers are neutral. What you point them at is not.\u003c/strong\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n","date_modified":"2026-04-15T09:17:11Z","date_published":"2026-04-15T09:17:11Z","id":"https://leadership.garden/ai-is-an-amplifier/","summary":"AI doesn't care about quality. It accelerates whatever direction your team was already heading. Here's what engineering leaders need to change.","tags":["ai","leadership","quality"],"title":"AI Is an Amplifier. What Are You Amplifying?","url":"https://leadership.garden/ai-is-an-amplifier/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThe bottleneck didn\u0026rsquo;t disappear when AI started writing code. It moved.\u003c/p\u003e\n\u003cp\u003eI used to deal with complaints about slow delivery. Tickets sat too long in development. Engineers were stuck, blocked, waiting on review. The work was the bottleneck. Fix the work, fix the speed.\u003c/p\u003e\n\u003cp\u003eNow I sit in planning sessions where we talk about how many agents we\u0026rsquo;re spinning up per engineer. Our output has visibly accelerated. PRs are flying in. Tickets close faster. And yet I have a quiet, growing feeling that something is off.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s not that the code is bad, exactly. It\u0026rsquo;s that I\u0026rsquo;m not sure anymore.\u003c/p\u003e\n\u003ch2 id=\"the-trap-inside-the-green-build\"\u003eThe Trap Inside the Green Build\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a term for what\u0026rsquo;s accumulating: \u003cstrong\u003everification debt\u003c/strong\u003e. \u003ca href=\"https://fazy.medium.com/agentic-coding-ais-adolescence-b0d13452f981\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eLars Janssen put it well in a recent post\u003c/a\u003e: it\u0026rsquo;s the gap between how fast you can generate output and how fast you can validate it. Every time someone approves a diff they haven\u0026rsquo;t fully understood, they\u0026rsquo;re borrowing against the future.\u003c/p\u003e\n\u003cp\u003eWhat makes this sneaky is that it doesn\u0026rsquo;t feel like debt. Technical debt announces itself. Slow builds, tangled modules, that one service nobody wants to touch. You feel it. Verification debt is quiet. The tests are green. The PR looks clean. The commit message is actually better than what your average human writes. It looks like progress.\u003c/p\u003e\n\u003cp\u003eAnd six months later you discover you built exactly what the spec said, and nothing the user actually needed.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve been there without AI. We\u0026rsquo;ve all shipped something \u0026ldquo;correct\u0026rdquo; that was wrong. AI just made it faster and easier to get there at scale.\u003c/p\u003e\n\u003ch2 id=\"everyones-50-more-productive-and-thats-the-problem\"\u003eEveryone\u0026rsquo;s 50% More Productive, And That\u0026rsquo;s The Problem\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s the math nobody wants to talk about. If AI makes every engineer 50% more productive, you don\u0026rsquo;t get 50% more output. You get 50% more pull requests. 50% more documentation. 50% more design proposals. And someone, somewhere, still has to review all of it.\u003c/p\u003e\n\u003cp\u003eWhen two or three early adopters start generating more PRs than before, the team absorbs it. No big deal. When everyone does it, review becomes the constraint. The bottleneck doesn\u0026rsquo;t vanish. It moves upstream, to the parts of the job that are irreducibly human: deciding what to build, defining \u0026ldquo;done,\u0026rdquo; understanding the domain, making judgment calls about risk.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve written about this pattern before: \u003ca href=\"https://leadership.garden/ai-the-work-moved/\"\u003ethe work didn\u0026rsquo;t disappear, it moved\u003c/a\u003e. What\u0026rsquo;s new here is that it moved specifically into verification - and most teams haven\u0026rsquo;t consciously staffed or structured for that yet.\u003c/p\u003e\n\u003cp\u003eAs an engineering leader, this is the thing I keep turning over. I\u0026rsquo;ve been thinking about team capacity in terms of writing capacity for years. Story points, cycle time, sprint velocity. All of those metrics were proxies for human time spent building. They\u0026rsquo;re not good proxies for a world where building is cheap.\u003c/p\u003e\n\u003cp\u003eThe question isn\u0026rsquo;t \u0026ldquo;how do we produce more code?\u0026rdquo; anymore. The question is \u0026ldquo;how do we verify more code?\u0026rdquo; And I don\u0026rsquo;t think most teams have a real answer to that yet.\u003c/p\u003e\n\u003ch2 id=\"what-im-actually-watching-for\"\u003eWhat I\u0026rsquo;m Actually Watching For\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve started framing verification as a first-class engineering skill, not a phase in the process.\u003c/p\u003e\n\u003cp\u003eThe checklist matters. Before anything ships: Is the agent implementing the right logic, or faithfully coding a flawed spec? What assumptions did it make about the domain? What permissions or side effects did this introduce? Would you stake your name on this doing what the user actually needs, not just what the ticket says?\u003c/p\u003e\n\u003cp\u003eThat last question is the one. \u0026ldquo;Probably\u0026rdquo; is not good enough.\u003c/p\u003e\n\u003cp\u003e(I\u0026rsquo;ve started asking this in code review discussions and the silence is instructive. Nobody wants to be the one to say \u0026ldquo;I pressed approve and moved on.\u0026rdquo;)\u003c/p\u003e\n\u003cp\u003eThe agents won\u0026rsquo;t question your intentions unless you explicitly ask them to. That asymmetry is the thing most people are still underestimating. The model is remarkably good at implementing what you described. It is not trying to tell you that you described the wrong thing.\u003c/p\u003e\n\u003ch2 id=\"the-skill-hasnt-shrunk-its-shifted\"\u003eThe Skill Hasn\u0026rsquo;t Shrunk, It\u0026rsquo;s Shifted\u003c/h2\u003e\n\u003cp\u003ePeople keep saying AI is making engineers dumber. I don\u0026rsquo;t think that\u0026rsquo;s the right frame.\u003c/p\u003e\n\u003cp\u003eWe stopped memorizing API signatures when search engines appeared. The cognitive load didn\u0026rsquo;t disappear. It shifted toward synthesis, architecture, judgment. The skill changed, but it didn\u0026rsquo;t shrink.\u003c/p\u003e\n\u003cp\u003eWhat I see with AI is the same pattern, one level up. The skill isn\u0026rsquo;t \u0026ldquo;write code.\u0026rdquo; It\u0026rsquo;s \u0026ldquo;understand what the code should do and verify that it does it.\u0026rdquo; That requires knowing the domain. Reading the diff and actually following the logic. Catching the places where the agent made a confident wrong assumption.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s harder, not easier. The volume of output to understand has gone up. The quality bar for review has gone up. The penalty for rubber-stamping has gone up.\u003c/p\u003e\n\u003cp\u003eMost of my day is asking agents questions and then validating their answers. It sounds efficient. In practice it\u0026rsquo;s a different kind of exhausting.\u003c/p\u003e\n\u003ch2 id=\"what-this-means-for-how-you-run-your-team\"\u003eWhat This Means for How You Run Your Team\u003c/h2\u003e\n\u003cp\u003eIf you\u0026rsquo;re managing engineers right now, I\u0026rsquo;d argue the most valuable thing you can do is resist the instinct to measure AI impact through output metrics. PRs per engineer, velocity, closed tickets. Those numbers will go up. They should go up. They\u0026rsquo;re not the thing to watch.\u003c/p\u003e\n\u003cp\u003eWatch the things that tell you whether the output is right. Review latency. Defect escape rate. Incidents that trace back to \u0026ldquo;we shipped something that looked fine.\u0026rdquo; Those will tell you whether your team is accumulating verification debt or actually managing it.\u003c/p\u003e\n\u003cp\u003eBuild review capacity explicitly. Don\u0026rsquo;t assume it scales with generation capacity. It doesn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eAnd create space for engineers to say \u0026ldquo;I don\u0026rsquo;t fully understand what this does.\u0026rdquo; That admission is worth a lot more than a fast approval.\u003c/p\u003e\n\u003chr\u003e\n\u003cp\u003eThe agents make output cheap. They don\u0026rsquo;t make responsibility cheap.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s the job now: keeping those two things from drifting too far apart. I have since written about \u003ca href=\"https://leadership.garden/typing-was-the-safety-harness/\"\u003ethe practical side of this\u003c/a\u003e, the schemas, interfaces, and tests you have to hand-roll to recreate the QA that used to come along with typing.\u003c/p\u003e\n","date_modified":"2026-04-08T09:16:54Z","date_published":"2026-04-08T09:16:54Z","id":"https://leadership.garden/verification-debt/","summary":"Verification debt is accumulating quietly in AI-assisted codebases. What engineering leaders need to watch for.","tags":["ai","engineering","quality"],"title":"Verification Debt Is Your Next Headache","url":"https://leadership.garden/verification-debt/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eEvery job description for an Engineering Manager reads roughly the same. Lead a team. Drive delivery. Grow people. Collaborate with product. Own the technical roadmap.\u003c/p\u003e\n\u003cp\u003eIt\u0026rsquo;s fiction.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve been an Engineering Manager at multiple companies. The role has never been the same twice - not even close. And I\u0026rsquo;m not just talking about startup-versus-enterprise differences. I mean two managers at the same company, same level, same title, doing completely different jobs.\u003c/p\u003e\n\u003cp\u003eThe standard definition is a myth we keep telling ourselves because it makes hiring easier. The reality is messier and more interesting.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-four-pillars-nobody-told-you-about\"\u003eThe Four Pillars Nobody Told You About\u003c/h2\u003e\n\u003cp\u003eIn every context I\u0026rsquo;ve worked in, the EM role pulls across four areas: \u003cstrong\u003eProduct, Process, People, and Programming\u003c/strong\u003e. The mistake is assuming they\u0026rsquo;re balanced equally. They never are.\u003c/p\u003e\n\u003cp\u003eWhat changes - radically - is which pillar consumes your week.\u003c/p\u003e\n\u003cp\u003eLarge team? Programming disappears. You\u0026rsquo;re building careers, coordinating across teams, and navigating the organization to secure resources. Your calendar looks like a war zone of 1:1s and stakeholder meetings. That\u0026rsquo;s not a failure of time management. That\u0026rsquo;s the job.\u003c/p\u003e\n\u003cp\u003eSmall team? Suddenly you\u0026rsquo;re managing scope against reality, trimming the roadmap, and - if the stars align - actually writing some code. The communication overhead is lower. You have breathing room.\u003c/p\u003e\n\u003cp\u003eNo product manager? You\u0026rsquo;re the PM now. Validating features, prioritizing the backlog, sitting in on client calls. This takes over everything else, and it should. Shipping features nobody wants makes everything else pointless. I\u0026rsquo;ve seen teams work beautifully on the inside while slowly dying on the outside because nobody was checking whether the work mattered.\u003c/p\u003e\n\u003cp\u003eReporting directly to the CEO? You\u0026rsquo;re suddenly the interface to sales, operations, and clients. You\u0026rsquo;ll spend more time explaining engineering tradeoffs to non-engineers than you ever expected. Your ability to translate is the job.\u003c/p\u003e\n\u003cp\u003eNone of this is surprising in isolation. But somehow we still treat the EM role as if there\u0026rsquo;s a canonical version of it.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-real-job-is-bottleneck-detection\"\u003eThe Real Job Is Bottleneck Detection\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what I\u0026rsquo;ve come to believe after years of doing this: \u003cstrong\u003ethe Engineering Manager\u0026rsquo;s primary job is to identify where the team\u0026rsquo;s bottleneck sits in the software development lifecycle, and fill it.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot permanently. Not because you\u0026rsquo;re the most qualified person for it. But because the team\u0026rsquo;s ability to move forward depends on someone owning that constraint right now.\u003c/p\u003e\n\u003cp\u003eSometimes that bottleneck is technical leadership. Sometimes it\u0026rsquo;s product clarity. Sometimes it\u0026rsquo;s someone willing to have hard conversations with stakeholders. Sometimes - honestly - it\u0026rsquo;s someone sitting down and writing the spec nobody else will write.\u003c/p\u003e\n\u003cp\u003eThe pillar you focus on shifts as circumstances change. That\u0026rsquo;s not role ambiguity. That\u0026rsquo;s the design.\u003c/p\u003e\n\u003cp\u003eWill Larson has \u003ca href=\"https://lethain.com/good-eng-mgmt-is-a-fad/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ewritten\u003c/a\u003e about how \u0026ldquo;good engineering management\u0026rdquo; is essentially a series of fads - each era of the industry redefines what a manager should be based on business realities, then retrospectively frames the change as moral progress. He\u0026rsquo;s right. In hypergrowth, the manager was a talent magnet and coach. Post-ZIRP, suddenly managers need to be hands-on contributors again. The definition moves with the market.\u003c/p\u003e\n\u003cp\u003eWhat doesn\u0026rsquo;t move is this: your team has a constraint somewhere, and your job is to find it and resolve it. That stays true across every era, every company size, every reporting structure.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-interview-trap\"\u003eThe Interview Trap\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s a mistake I see managers make, especially early in their careers: asking the interviewer \u0026ldquo;what do you expect from an Engineering Manager here?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eIt sounds like a thoughtful question. It isn\u0026rsquo;t.\u003c/p\u003e\n\u003cp\u003eMost managers believe their own experience is the industry standard. They\u0026rsquo;ve been doing the job a certain way for years. If you ask what they expect, you\u0026rsquo;ll get a description of what they\u0026rsquo;ve seen - not what the role actually requires in that specific context. The answer will be confident and incomplete.\u003c/p\u003e\n\u003cp\u003eAsk instead about their daily life. What\u0026rsquo;s taking up most of their time right now? What problems keep coming back? Where does the team get stuck?\u003c/p\u003e\n\u003cp\u003eThat conversation will tell you more about what the role actually is than any job description or generic answer about \u0026ldquo;ownership\u0026rdquo; and \u0026ldquo;technical leadership.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eYou\u0026rsquo;re not just evaluating fit. You\u0026rsquo;re doing early bottleneck detection.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-uncomfortable-part\"\u003eThe Uncomfortable Part\u003c/h2\u003e\n\u003cp\u003eAccepting that the role is context-defined rather than fixed puts the burden on you.\u003c/p\u003e\n\u003cp\u003eYou can\u0026rsquo;t just get good at \u0026ldquo;being an EM\u0026rdquo; in the abstract. You have to get good at reading your situation, identifying the constraint, and shifting your focus accordingly - even when that means spending six months deep in product work when you\u0026rsquo;d rather be building engineering culture. Even when it means giving up coding for a year because the team needs a different kind of leadership right now.\u003c/p\u003e\n\u003cp\u003eThe managers who struggle most are the ones who have a fixed idea of what their job looks like and try to impose it on every context. I\u0026rsquo;ve done it. It doesn\u0026rsquo;t end well.\u003c/p\u003e\n\u003cp\u003eThe role requires flexibility not as a soft skill, but as a core operating principle.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s not what the job descriptions say. But it\u0026rsquo;s what the job is.\u003c/p\u003e\n","date_modified":"2026-04-02T09:16:36Z","date_published":"2026-04-02T09:16:36Z","id":"https://leadership.garden/there-is-no-standard-em-role/","summary":"There is no standard Engineering Manager role. The job is defined by your team's biggest bottleneck - and it shifts constantly. Here's what that actually looks like.","tags":["career","management","leadership"],"title":"There Is No Standard EM Role","url":"https://leadership.garden/there-is-no-standard-em-role/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThere is a Buddhist idea that has lived in my head for decades now. The image is simple: a teacher raises their finger to point at the moon. The student stares intently\u0026hellip; at the finger.\u003c/p\u003e\n\u003cp\u003eThe teaching isn\u0026rsquo;t about the finger. The finger is pointing at something. But the student, eager and well-intentioned, has confused the pointer with the thing being pointed at. They are sucking the finger, \u003ca href=\"https://taylor.town/finger-moon\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eas Alan Watts put it\u003c/a\u003e, for comfort - instead of looking at where it points.\u003c/p\u003e\n\u003cp\u003eI keep thinking about this because I keep watching it happen. Not in meditation halls. In engineering organizations.\u003c/p\u003e\n\u003ch2 id=\"we-are-very-good-at-optimizing-the-wrong-thing\"\u003eWe Are Very Good at Optimizing the Wrong Thing\u003c/h2\u003e\n\u003cp\u003eEngineers are trained to measure. To make things precise. To track. This is a superpower in the right context and a slow-moving catastrophe in the wrong one.\u003c/p\u003e\n\u003cp\u003eThe problem is that almost every useful practice in engineering leadership is a finger. Scrum is a finger. OKRs are a finger. 1:1s are a finger. Career ladders are a finger. Code coverage targets are a finger. Post-mortems are a finger. The finger is real; it has value, and at some point someone designed it carefully to point at something genuinely important.\u003c/p\u003e\n\u003cp\u003eBut fingers are concrete. You can measure a finger. You can report on a finger. You can build a dashboard for a finger. The moon - the actual outcome or underlying concept the practice was supposed to serve - is harder. It requires judgment. It requires you to hold ambiguity. It can\u0026rsquo;t be automated.\u003c/p\u003e\n\u003cp\u003eSo we optimize the finger. And after long enough, the finger becomes the point.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve done this. More than once.\u003c/p\u003e\n\u003ch2 id=\"the-agile-ceremony-that-eats-your-team\"\u003eThe Agile Ceremony That Eats Your Team\u003c/h2\u003e\n\u003cp\u003eI inherited a team a few years ago that ran textbook Scrum. Standups every morning at 9:45, retrospectives every two weeks, planning sessions that started on time, and burndown charts updated religiously. The team\u0026rsquo;s Jira hygiene was impeccable.\u003c/p\u003e\n\u003cp\u003eThe team was miserable and shipping slowly.\u003c/p\u003e\n\u003cp\u003eWhen I actually talked to people, the standups had become status theater: three sentences for the PM, delivered without real communication. The retros produced action items that lived in a Confluence page no one revisited. Planning was a negotiation over story points with no connection to what actually mattered. The velocity metric was healthy; the team\u0026rsquo;s sense of purpose was not.\u003c/p\u003e\n\u003cp\u003eThe ceremonies had been the moon once. Someone put them in place to create rhythm, transparency, and continuous improvement. But they had calcified into the finger. The team was performing Agile instead of being agile.\u003c/p\u003e\n\u003cp\u003eThis is the most common form of finger-worship I see. It\u0026rsquo;s particularly hard to spot because the ceremonies \u003cem\u003elook\u003c/em\u003e like discipline. From the outside, from a director\u0026rsquo;s report, from a maturity assessment - everything checks out. The process is healthy. The patient is dying. There\u0026rsquo;s even a name for it: \u003ca href=\"https://www.scrum.org/resources/blog/breaking-out-agile-theater-communicating-strategic-value\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eAgile theater\u003c/a\u003e - when teams adopt all the motions of agility while optimizing for ceremonies instead of outcomes.\u003c/p\u003e\n\u003cp\u003eAsk yourself when a ceremony last actually changed something. Not when it produced an action item. When it changed behavior, direction, or understanding in a way that mattered. If you can\u0026rsquo;t remember, you\u0026rsquo;re probably managing the finger.\u003c/p\u003e\n\u003ch2 id=\"okr-season-as-performance-art\"\u003eOKR Season as Performance Art\u003c/h2\u003e\n\u003cp\u003eI have a complicated relationship with OKRs\u0026hellip;\u003c/p\u003e\n\u003cp\u003eThe idea is genuinely good: write down what matters, make it measurable enough to know if you achieved it, and let teams figure out how. Separate goals from tasks. Think in outcomes, not outputs. John Doerr\u0026rsquo;s pitch is compelling, and I\u0026rsquo;ve seen OKRs work. Will Larson\u0026rsquo;s \u003ca href=\"https://lethain.com/goals-and-baselines/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003etake on goals and baselines\u003c/a\u003e captures the real intent well: \u003cem\u003egoals should decouple the \u0026ldquo;what\u0026rdquo; from the \u0026ldquo;how,\u0026rdquo;\u003c/em\u003e not become a bureaucratic layer on top of them.\u003c/p\u003e\n\u003cp\u003eBut inside most engineering organizations, OKR season has become something else. It\u0026rsquo;s a quarterly ritual. Six weeks of workshops, alignment meetings, cascading conversations, spreadsheet templates, and final-hour wrangling over whether a metric is aspirational enough. Then the quarter starts, and the team works on whatever they were going to work on anyway (or the next \u0026ldquo;super important\u0026rdquo; project that a senior stakeholder pushes in from the side).\u003c/p\u003e\n\u003cp\u003eThe key results - the finger - consume enormous organizational energy. The actual performance shift that OKRs were supposed to unlock rarely materializes.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve sat in OKR review meetings where a team hit 80%+ on every key result, and nobody could tell me whether the product had actually improved for users. The number had become the thing. The thing had been forgotten.\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a version of this that\u0026rsquo;s even more insidious: \u003cem\u003eteams learn to set key results they know they can hit\u003c/em\u003e. The ambition drains out slowly. You end up with a rigorous process for measuring things nobody really cares about. The moon is now completely out of view. The finger is beautifully documented.\u003c/p\u003e\n\u003cp\u003eIf your OKR process mostly generates anxiety and alignment theater, it is pointing somewhere. Follow where it points. It usually points at a trust problem, or a strategy problem, or a prioritization problem that OKRs can\u0026rsquo;t actually fix.\u003c/p\u003e\n\u003ch2 id=\"the-11-that-doesnt-do-anything\"\u003eThe 1:1 That Doesn\u0026rsquo;t Do Anything\u003c/h2\u003e\n\u003cp\u003eI believe in 1:1s. I run them regularly, I prepare for them, and I think managers who skip them are making a mistake.\u003c/p\u003e\n\u003cp\u003eThat said, I\u0026rsquo;ve also sat in enough 1:1s - including ones I ran myself - that were essentially nothing. A status update. A venting session with no follow-up. A polite ritual that both people felt good about completing.\u003c/p\u003e\n\u003cp\u003eThe 1:1 is a finger pointing at something specific: the growth, wellbeing, and effectiveness of a person on your team. When it\u0026rsquo;s working, the person leaves the room slightly clearer, slightly more capable, slightly more connected to what matters. When it\u0026rsquo;s not working, it\u0026rsquo;s just a recurring calendar event.\u003c/p\u003e\n\u003cp\u003eThe failure mode I\u0026rsquo;ve noticed most is confusing \u003cem\u003ethe conversation\u003c/em\u003e with \u003cem\u003ethe outcome\u003c/em\u003e. A manager holds a 1:1, the report raises a concern, the manager listens empathetically, the meeting ends. The manager feels like they did the work. The concern goes unaddressed.\u003c/p\u003e\n\u003cp\u003eListening is the finger. The moon is the person actually growing and solving the problem. (And yes, I\u0026rsquo;ve done this too. The listening feels like the act because listening is where the effort is visible.)\u003c/p\u003e\n\u003cp\u003eThe other version: 1:1s that are entirely about the manager\u0026rsquo;s agenda. Status, blockers, updates. The manager walks away informed. The report walks away feeling managed. This is also finger-worship, just from a different angle.\u003c/p\u003e\n\u003cp\u003eAfter your 1:1s, are the people you manage measurably more capable over time? Are they solving problems they couldn\u0026rsquo;t solve before? Are they more confident in their judgment? If not, the recurring invite is just a recurring invite.\u003c/p\u003e\n\u003ch2 id=\"career-ladders-and-the-level-theater\"\u003eCareer Ladders and the Level Theater\u003c/h2\u003e\n\u003cp\u003eCareer frameworks are useful. I\u0026rsquo;ve helped build a few. Done right, they create shared language, reduce subjectivity, and give engineers a map for their own development.\u003c/p\u003e\n\u003cp\u003eDone wrong, they create a new game to play.\u003c/p\u003e\n\u003cp\u003eYou\u0026rsquo;ve seen this: the engineer who spends 18 months optimizing their promotion case rather than doing great work. The senior engineer who carefully documents their \u0026ldquo;cross-team impact\u0026rdquo; in language that mirrors the level rubric. The staff engineer candidate who leads exactly the kind of project that happens to be described as a \u0026ldquo;staff-level initiative\u0026rdquo; in the framework, regardless of whether that project is the highest-leverage thing they could be doing.\u003c/p\u003e\n\u003cp\u003eThe level is not the career. The career ladder is pointing at something: actual growth, actual capability, and actual impact. The number is a proxy. But the proxy becomes the target, and \u003ca href=\"https://en.wikipedia.org/wiki/Goodhart%27s_law\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGoodhart\u0026rsquo;s Law\u003c/a\u003e does the rest: when a measure becomes a target, it ceases to be a good measure.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve managed engineers who were technically underpromoted by their rubric score and doing extraordinary work. I\u0026rsquo;ve managed engineers who hit every level criteria and were not particularly good. The map is not the territory. The ladder is not the growth. Will Larson documents this well in his piece on \u003ca href=\"https://lethain.com/promo-pathologies/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003epromotion pathologies\u003c/a\u003e - the recurring ways that level systems develop a life of their own, disconnected from the actual performance they were meant to reflect.\u003c/p\u003e\n\u003cp\u003eThe fix is not to abandon career frameworks. They\u0026rsquo;re necessary at scale. The fix is to hold them lightly - to remember that when the level rubric says \u0026ldquo;leads projects with ambiguity,\u0026rdquo; the \u003cem\u003emoon\u003c/em\u003e is actually \u0026ldquo;comfortable and effective in ambiguous situations\u0026rdquo;. Not someone who has learned to narrate ambiguity well in a promo doc.\u003c/p\u003e\n\u003ch2 id=\"the-post-mortem-that-closes-itself\"\u003eThe Post-Mortem That Closes Itself\u003c/h2\u003e\n\u003cp\u003ePost-mortems might be the clearest example of finger-worship in engineering culture.\u003c/p\u003e\n\u003cp\u003eThe original moon: learn from failures, prevent recurrence, and build psychological safety so people share what went wrong. \u003ca href=\"https://sre.google/sre-book/postmortem-culture/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eGoogle\u0026rsquo;s SRE book\u003c/a\u003e describes the aspiration perfectly: a postmortem is not written as a formality to be forgotten, but as an opportunity to make the organization more resilient as a whole.\u003c/p\u003e\n\u003cp\u003eThe finger: a document. A structured template. A meeting with a facilitator. A list of action items assigned with due dates.\u003c/p\u003e\n\u003cp\u003eThe moon disappears very quickly. The finger is what we have meetings about.\u003c/p\u003e\n\u003cp\u003eI have read countless post-mortem documents. The ones that change anything have a clear owner for the root cause, real organizational will to fix it, and someone who follows up three months later. These are rare. More commonly, the post-mortem document is written, reviewed, stored in Confluence, and quietly forgotten. The same incident happens again six months later. A new post-mortem is written.\u003c/p\u003e\n\u003cp\u003eWe are very good at running the process. The process is not working.\u003c/p\u003e\n\u003cp\u003ePost-mortem culture that actually learns requires something that can\u0026rsquo;t be templated: leadership that treats the findings seriously, that changes roadmaps based on reliability problems, and that funds the unglamorous work that prevents the next incident. The document can\u0026rsquo;t do that. The document is just the finger.\u003c/p\u003e\n\u003ch2 id=\"what-mentoring-gets-wrong\"\u003eWhat Mentoring Gets Wrong\u003c/h2\u003e\n\u003cp\u003eThis one is personal.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve been mentored well and mentored badly. The bad mentoring had something in common: the mentor was more invested in sharing their perspective than in the mentee\u0026rsquo;s actual development.\u003c/p\u003e\n\u003cp\u003eGood advice is a finger. It points at a capability, a mindset, a way of seeing problems that the mentee doesn\u0026rsquo;t yet have. The moon is the mentee developing that capability themselves - internalizing it, making it their own, and applying it in contexts the mentor never anticipated.\u003c/p\u003e\n\u003cp\u003eBut advice feels good to give. It feels like helping. The mentor leaves the session feeling useful. The mentee leaves with a list of things the mentor would do.\u003c/p\u003e\n\u003cp\u003eThe failure pattern: the mentee keeps coming back with the same types of problems, and the mentor keeps providing answers. It feels like a productive relationship. What it actually is: dependency. The finger is being pointed, and the mentee is staring at the finger.\u003c/p\u003e\n\u003cp\u003eReal mentoring is less comfortable. It involves sitting with the mentee\u0026rsquo;s discomfort longer than feels natural. Asking questions instead of answering them. Resisting the urge to solve, because solving trains someone to be solved-for.\u003c/p\u003e\n\u003cp\u003eI have a mentor who does this better than anyone I know. Early in our relationship, I would describe a situation and wait for his read. He would ask me what I thought. I found this frustrating. (I was there for his opinion, not mine.) Over time I realized what he was pointing at: my own judgment. He was trying to make me trust it. The answer was never the moon. My developing ability to find answers was the moon.\u003c/p\u003e\n\u003ch2 id=\"the-diagnostic\"\u003eThe Diagnostic\u003c/h2\u003e\n\u003cp\u003eHere is the question I now ask myself when I\u0026rsquo;m running a process, a ceremony, a framework, or a practice that I believe in:\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eIf this process disappeared tomorrow, what would get worse?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eIf the answer is \u0026ldquo;the process would disappear,\u0026rdquo; you\u0026rsquo;re worshipping the finger. The finger is its own justification.\u003c/p\u003e\n\u003cp\u003eIf the answer is \u0026ldquo;the team would lose clarity, rhythm, or growth opportunity,\u0026rdquo; you\u0026rsquo;re probably still connected to the moon. The process is doing what it\u0026rsquo;s supposed to do.\u003c/p\u003e\n\u003cp\u003eThe second question: \u003cem\u003eWhen did this practice last change something?\u003c/em\u003e Not produced something. Changed something. Altered behavior, direction, understanding, or outcomes in a way that mattered to someone outside the room.\u003c/p\u003e\n\u003cp\u003eIf you can\u0026rsquo;t answer that, the practice may have drifted. Not because it was bad. Because practices drift. Because the organization changed. Because what once pointed helpfully now just points.\u003c/p\u003e\n\u003ch2 id=\"the-harder-problem\"\u003eThe Harder Problem\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what makes this genuinely difficult: you cannot see the moon without the finger.\u003c/p\u003e\n\u003cp\u003eThe ceremonies, the frameworks, the 1:1s, the post-mortems - they are not the enemy. They are necessary. A team with no ceremonies has no rhythm. A manager with no framework has no consistency. A mentor with no structure helps no one.\u003c/p\u003e\n\u003cp\u003eThe finger is how you find the moon in the first place. That\u0026rsquo;s the whole point of the Buddhist image. Without the pointing, you wouldn\u0026rsquo;t know where to look.\u003c/p\u003e\n\u003cp\u003eThe discipline is holding the finger lightly. Using it as long as it serves and letting it go when it stops pointing at anything real. This is harder than it sounds, because organizations develop immune systems around their fingers. The sprint ceremony has been running for four years. The OKR template is the way we do things. Suggesting that the post-mortem process isn\u0026rsquo;t working feels like attacking culture.\u003c/p\u003e\n\u003cp\u003eBut the question isn\u0026rsquo;t whether the finger is legitimate. The question is whether it\u0026rsquo;s still pointing at anything.\u003c/p\u003e\n\u003cp\u003eRyokan, the Zen poet, wrote something that has stayed with me:\u003c/p\u003e\n\u003cp\u003e\u003cem\u003eRelying upon a finger, we see the moon. Relying upon the moon, we understand the finger.\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003e(The \u003ca href=\"https://dogeninstitute.wordpress.com/2021/09/26/ryokan-interpreted-finger-pointing-at-the-moon/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003efull poem and context\u003c/a\u003e from Okumura Roshi are worth sitting with.) The relationship goes both ways. You need the finger to find the moon, and you need the moon to know what the finger was actually for.\u003c/p\u003e\n\u003cp\u003eMost engineering organizations stop at the finger. The work of leadership - the actual work, the hard part - is keeping the moon in view even when you can\u0026rsquo;t measure it. Even when the dashboard shows green. Even when the quarterly report looks fine.\u003c/p\u003e\n\u003cp\u003eLook up from the finger. See where it\u0026rsquo;s pointing. Go there.\u003c/p\u003e\n","date_modified":"2026-03-26T10:16:18Z","date_published":"2026-03-26T10:16:18Z","id":"https://leadership.garden/the-finger-is-not-the-moon/","summary":"The finger is not the moon. A guide for engineering leaders on recognizing when your ceremonies, OKRs, and 1:1s have become performance instead of practice.","tags":["management"],"title":"The Finger Is Not the Moon","url":"https://leadership.garden/the-finger-is-not-the-moon/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eThere\u0026rsquo;s a \u003ca href=\"https://news.ycombinator.com/item?id=47386284\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethread\u003c/a\u003e on Hacker News asking what breaks first when an engineering team grows from 10 to 50 people. The answers are predictable: \u003cem\u003edocumentation, communication overhead, tribal knowledge, early hires having identity crises\u003c/em\u003e. All true. All missing the point.\u003c/p\u003e\n\u003cp\u003eThe thing that actually breaks first is \u003cstrong\u003e\u003cem\u003eyou\u003c/em\u003e\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"the-invisible-routing-layer\"\u003eThe invisible routing layer\u003c/h2\u003e\n\u003cp\u003eAt 10 people, a good engineering leader is the connective tissue of the entire org. Not because they\u0026rsquo;re a control freak (well, some are), but because it\u0026rsquo;s just efficient. Someone asks you about a product decision from six months ago: you remember it. Two engineers are building on conflicting assumptions: you catch it in a one-on-one and fix it before it becomes a PR conflict. A new hire doesn\u0026rsquo;t know who owns the auth service: they ask you, and you tell them in thirty seconds.\u003c/p\u003e\n\u003cp\u003eYou are the \u003cstrong\u003econtext routing layer\u003c/strong\u003e. Every ambiguous question eventually reaches you, gets resolved, and you carry the resolution forward in your head. This works extraordinarily well at a small scale. It requires almost no process overhead, it\u0026rsquo;s fast, and it produces consistent decisions because one brain is making most of them.\u003c/p\u003e\n\u003cp\u003eThe problem is that the team has no idea this is happening. To them, things just\u0026hellip; work. Decisions get made. Context flows. Problems resolve.\u003c/p\u003e\n\u003cp\u003eThey think the org is functional. It\u0026rsquo;s not. It\u0026rsquo;s \u003cstrong\u003e\u003cem\u003eyou\u003c/em\u003e\u003c/strong\u003e.\u003c/p\u003e\n\u003ch2 id=\"when-the-routing-layer-saturates\"\u003eWhen the routing layer saturates\u003c/h2\u003e\n\u003cp\u003eI remember the moment I understood this clearly back in 2010. We had grown from a single team I could hold in one meeting room to three teams with their own leads. I was excited - this was the goal. More people, more scope, more output.\u003c/p\u003e\n\u003cp\u003eWhat I hadn\u0026rsquo;t prepared for: suddenly there was an entire team whose daily context I no longer carried. Their lead was solid. But the questions that used to reach me invisibly - the ones I\u0026rsquo;d answer while walking to get coffee - now either got escalated through a whole chain, sat unanswered, or got answered wrong by someone filling the gap with their best guess.\u003c/p\u003e\n\u003cp\u003eThe org felt slow. Decisions felt inconsistent. I kept getting pulled into things I thought I\u0026rsquo;d delegated. I blamed the leads at first. (I was wrong. And yes, I\u0026rsquo;ve done that too.)\u003c/p\u003e\n\u003cp\u003eWhat had actually happened: the team had grown beyond my cognitive bandwidth, and nobody - including me - had built anything to replace what I was doing unconsciously.\u003c/p\u003e\n\u003ch2 id=\"what-you-were-doing-unconsciously\"\u003eWhat you were doing unconsciously\u003c/h2\u003e\n\u003cp\u003eIt\u0026rsquo;s worth being specific, because the fix depends on naming it accurately.\u003c/p\u003e\n\u003cp\u003eTanya Reilly\u0026rsquo;s \u003ca href=\"https://noidea.dog/glue\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u0026ldquo;Being Glue\u0026rdquo;\u003c/a\u003e is the closest thing I know to a map of this territory. She wrote it for individual contributors - engineers who spend most of their time in meetings, unblocking people, noticing what got dropped - but the description fits small-team EMs almost exactly. The work is real. It\u0026rsquo;s high-impact. And it\u0026rsquo;s almost entirely invisible on a good day.\u003c/p\u003e\n\u003cp\u003eWhen you were the routing layer, you were doing at least four things that now need explicit structure:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDecision logging.\u003c/strong\u003e You remembered why things were decided the way they were. Now that history lives in your head and nowhere else. The minute a decision maker is out of the loop - on vacation, in back-to-back meetings, running a different team - that institutional memory is inaccessible.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSynchronizing assumptions.\u003c/strong\u003e You knew what each team believed about the system, the product, and the customer. When two beliefs diverged, you corrected it. Nobody else was doing this work. It was invisible because you did it continuously and informally.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eAbsorbing ambiguity.\u003c/strong\u003e Every organization produces ambiguous situations constantly. At 10 people, you resolved most of them fast, in conversation, before they turned into real problems. At 30, ambiguity piles up in corners you no longer visit.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSocial cohesion.\u003c/strong\u003e You knew everyone. You knew who was frustrated, who was thriving, who needed more challenge. You maintained the team\u0026rsquo;s social fabric without anyone calling it that. (This one is the last to break, and the hardest to rebuild once it does.)\u003c/p\u003e\n\u003ch2 id=\"the-wrong-fix-and-the-right-one\"\u003eThe wrong fix and the right one\u003c/h2\u003e\n\u003cp\u003eThe standard advice at this point is: document everything. Write it down. Build a Notion wiki. That advice isn\u0026rsquo;t wrong, but it\u0026rsquo;s treating a symptom while the disease progresses.\u003c/p\u003e\n\u003cp\u003eDocumentation without ownership decays into archaeology within months. I\u0026rsquo;ve seen teams build enormous wikis that new hires learn to ignore within their first week, because they quickly discover the pages are stale and the real answers still live in someone\u0026rsquo;s head. You haven\u0026rsquo;t solved the routing problem - you\u0026rsquo;ve just created a fake routing system that gives everyone false confidence.\u003c/p\u003e\n\u003cp\u003eThe real fix is to \u003cstrong\u003eexternalize the four functions above\u003c/strong\u003e into lightweight, maintained systems - and then get out of the way enough that those systems actually get used.\u003c/p\u003e\n\u003cp\u003eWill Larson has a useful frame for this he calls \u003ca href=\"https://lethain.com/model-document-share/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u0026ldquo;Model, Document and Share\u0026rdquo;\u003c/a\u003e: start doing the thing yourself, document what you learned, then share it so others can adopt it without a mandate. It was written for influencing without authority, but it applies here just as well. The goal is the same: take something that lives in one person\u0026rsquo;s head and make it reproducible.\u003c/p\u003e\n\u003cp\u003eSome of what that looks like in practice:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cstrong\u003eDecision logs\u003c/strong\u003e that live in the work artifacts themselves, not a separate document: in the PR, the ticket, the RFC. The closer the context is to the change, the more likely it gets read and updated.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eTeam leads\u003c/strong\u003e who are explicitly responsible for assumption synchronization between their team and adjacent teams - not because it\u0026rsquo;s on a job description, but because you\u0026rsquo;ve talked about why it matters and they\u0026rsquo;ve internalized it.\u003c/li\u003e\n\u003cli\u003e\u003cstrong\u003eA lightweight escalation habit\u003c/strong\u003e: when something is ambiguous, the right move is to write down the ambiguity and make it visible, not resolve it silently and move on.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eNone of this is novel. What\u0026rsquo;s novel is understanding \u003cem\u003ewhy\u003c/em\u003e you\u0026rsquo;re doing it: not because scale requires process, but because you were doing all of this yourself and it needs a new home.\u003c/p\u003e\n\u003ch2 id=\"the-thing-worth-naming-to-your-team\"\u003eThe thing worth naming to your team\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what I\u0026rsquo;ve started doing that I wish I\u0026rsquo;d done earlier: telling teams explicitly what used to happen and what needs to happen now.\u003c/p\u003e\n\u003cp\u003eNot as a lecture, just as a fact. Something like: \u0026ldquo;When we were smaller, I held a lot of context that let us move fast without much coordination overhead. We\u0026rsquo;re past the point where that scales. Here\u0026rsquo;s what I need from each of you to replace it.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eMost engineers find this clarifying rather than alarming. They suspected something was off. They just didn\u0026rsquo;t have the frame.\u003c/p\u003e\n\u003cp\u003eWhat they didn\u0026rsquo;t know - and what most managers never say out loud - is that the org\u0026rsquo;s apparent smoothness was load-bearing on one person. Once you name it, you can share the weight.\u003c/p\u003e\n\u003cp\u003eThe HN thread will keep producing answers about documentation and communication bandwidth and \u003ca href=\"https://leadership.garden/dunbars-numbers/\"\u003eDunbar\u0026rsquo;s number\u003c/a\u003e. Those aren\u0026rsquo;t wrong.\u003c/p\u003e\n\u003cp\u003eBut if you\u0026rsquo;re an EM watching things crack as your team grows, start by asking a harder question: \u003cstrong\u003e\u003cem\u003ewhat was I doing that nobody else knew I was doing\u003c/em\u003e\u003c/strong\u003e?\u003c/p\u003e\n\u003cp\u003eThe answer is usually longer than you expect.\u003c/p\u003e\n","date_modified":"2026-03-21T16:49:26Z","date_published":"2026-03-21T16:49:26Z","id":"https://leadership.garden/what-actually-breaks-at-30-people/","summary":"When your engineering team grows past 15-20, what breaks first isn't documentation. It's that you were the routing layer and nobody knew it.","tags":["management","leadership","teams"],"title":"What Actually Breaks at 30 People","url":"https://leadership.garden/what-actually-breaks-at-30-people/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cblockquote\u003e\n\u003cp\u003e\u003cem\u003eThe Cone of Uncertainty, Fibonacci scale, and Cynefin walk into a sprint planning session\u0026hellip;\u003c/em\u003e\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eA product manager walked into a refinement session a few years back, dropped a one-pager on the table, and said: \u0026ldquo;How long will this take?\u0026rdquo; The team I was leading had been through enough of these moments to know the ritual. Someone would say a number. That number would get written down. Two weeks later, it would become a deadline.\u003c/p\u003e\n\u003cp\u003eI stopped the session. I told her we couldn\u0026rsquo;t answer that question yet - not because we were hiding something, but because the honest answer was \u0026ldquo;\u003cem\u003esomewhere between three weeks and five months, and I\u0026rsquo;m not joking.\u003c/em\u003e\u0026rdquo; What followed was an uncomfortable thirty minutes that probably saved us three months of political fallout. We talked about what we actually knew versus what we were assuming. We agreed on what had to be true before the estimate could meaningfully narrow. We walked out with a plan to answer the question - not an answer.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s the conversation most engineering teams never have. And it\u0026rsquo;s the conversation the #NoEstimates movement, for all its righteous frustration, accidentally makes harder to have.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-problem-noestimates-actually-solved\"\u003eThe Problem #NoEstimates Actually Solved\u003c/h2\u003e\n\u003cp\u003eI want to be fair here. The people who built the #NoEstimates movement weren\u0026rsquo;t being irresponsible. They were reacting to something real and genuinely damaging: the industrial-scale misuse of estimates as performance targets.\u003c/p\u003e\n\u003cp\u003eThe pattern they were fighting goes like this. A team, knowing very little about a problem, is asked for an estimate. They give one - probably optimistic, because there\u0026rsquo;s social pressure to be bold. That number gets written into a Confluence document, escalated to a VP, packaged into a roadmap, and committed to a customer. Six months later, when reality diverges from the estimate (as it always does), the team gets blamed for \u0026ldquo;missing\u0026rdquo; a deadline they never agreed to. The estimate was not a forecast. It was, from the moment it left their mouths, a commitment - they just didn\u0026rsquo;t know it yet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThat pathology is real. I\u0026rsquo;ve lived it. The frustration is valid.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eBut the solution - don\u0026rsquo;t estimate - is like responding to a broken thermometer by deciding temperature doesn\u0026rsquo;t exist. The thermometer was the problem. Not the concept of heat.\u003c/p\u003e\n\u003cp\u003eWhat often gets lost in that frustration: \u003cem\u003eyour estimate doesn\u0026rsquo;t change the actual work\u003c/em\u003e. Maarten Dalmijn puts it well in \u003ca href=\"https://mdalmijn.com/p/11-laws-of-software-estimation-for-complex-work\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ehis writing\u003c/a\u003e on estimation - reality is unaffected by your guess (really great article btw., you should read it). The jar contains whatever number of pennies it contains, regardless of what you said. \u003cstrong\u003eDelivering a feature takes as long as it takes\u003c/strong\u003e. What the estimate influences is not the work itself but the \u003cstrong\u003e\u003cem\u003eexpectations\u003c/em\u003e\u003c/strong\u003e around it - and managing those expectations, honestly and clearly, is \u003cem\u003every much\u003c/em\u003e worth doing (and it\u0026rsquo;s part of the job).\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"why-organizations-actually-need-estimates\"\u003eWhy Organizations Actually Need Estimates\u003c/h2\u003e\n\u003cp\u003eHere is the thing that the #NoEstimates literature almost always sidesteps: \u003cstrong\u003eestimates are not primarily for the team doing the work.\u003c/strong\u003e They are for the organization around the team.\u003c/p\u003e\n\u003cp\u003eThree specific situations make estimation non-negotiable for anyone operating inside a larger organization.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eExternal commitments.\u003c/strong\u003e When your product is part of a customer contract, when a launch is tied to a marketing campaign, when a regulatory deadline exists that your company cannot move: someone has to make a call about what\u0026rsquo;s feasible. That call requires some model of how long things take. \u0026ldquo;We don\u0026rsquo;t estimate\u0026rdquo; is not an answer a business can give a customer. It\u0026rsquo;s a sentence that ends contracts.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eInter-team dependencies.\u003c/strong\u003e As soon as you have more than one team, you have coordination problems. Team B cannot start their work until Team A finishes theirs. If Team A refuses to give any forecast of when they\u0026rsquo;ll be done, Team B cannot plan. Not because planning is sacred, but because people - real people - need to make decisions about where to point their attention next. A rough signal (\u0026ldquo;probably six weeks, could be eight\u0026rdquo;) is infinitely more useful than silence. This is not about control. It\u0026rsquo;s about \u003cem\u003erespect\u003c/em\u003e \u003cem\u003efor the humans downstream of you\u003c/em\u003e.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eROI calculations.\u003c/strong\u003e Every product decision is implicitly a resource allocation decision. Should we build Feature X or Feature Y? To answer that, you need some model of relative cost. If everything is unknowable, you cannot make reasoned trade-offs - you\u0026rsquo;re just guessing. And if you\u0026rsquo;re going to guess anyway, you might as well make it a structured guess with explicit assumptions attached.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eNone of these needs require \u003cem\u003eprecise\u003c/em\u003e estimates. They require \u003cem\u003euseful\u003c/em\u003e ones. That distinction is everything.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-joseph-pelrine-showed-us-about-why-this-is-hard\"\u003eWhat Joseph Pelrine Showed Us About Why This Is Hard\u003c/h2\u003e\n\u003cp\u003eJoseph Pelrine is Europe\u0026rsquo;s first Certified Scrum Trainer (and someone with really-really down-to-earth, no-BS talks!) and spent years researching software agility through the lens of social complexity science. In \u003ca href=\"https://www.youtube.com/watch?v=XnaVsiqLPwQ\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethis talk\u003c/a\u003e, he describes a fascinating exercise he ran with over 300 people working in Agile software development. Using the \u003ca href=\"https://en.wikipedia.org/wiki/Cynefin_framework\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCynefin framework\u003c/a\u003e - Dave Snowden\u0026rsquo;s sense-making model that classifies problems into domains: Clear, Complicated, Complex, and Chaotic - he asked participants to place their everyday work activities into the appropriate domain.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/estimation/cynefin_hu_2935ba01851c342a.png\"\n    srcset=\"/estimation/cynefin_hu_a0b7b3dc7497189.webp 640w, /estimation/cynefin_hu_f5a590938145306d.webp 960w, /estimation/cynefin_hu_4fcff655ed9b4786.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"1024\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003eThe Cynefin framework\u003c/p\u003e\n\u003cp\u003eTask estimation, consistently and repeatedly, landed in the \u003cstrong\u003eComplex\u003c/strong\u003e domain.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003e\u003cem\u003eNot Complicated. Complex.\u003c/em\u003e\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis distinction matters enormously. In the Complicated domain, cause and effect are knowable - you might need an expert to trace the relationship, but it\u0026rsquo;s traceable. A bridge engineer can calculate load tolerances. A surgeon can estimate recovery time based on procedure type and patient profile. Expertise produces reliable forecasts.\u003c/p\u003e\n\u003cp\u003eIn the Complex domain, cause and effect are only knowable \u003cem\u003ein retrospect\u003c/em\u003e. The system is too entangled, too context-dependent, too sensitive to small changes. You don\u0026rsquo;t analyze and then act. You probe, observe what happens, and respond. Your knowledge is inherently local and temporary.\u003c/p\u003e\n\u003cp\u003eTask estimation sits here because software development is not manufacturing. We are, almost always, building something that has never existed before, on top of a codebase that is unique, with a team whose dynamics are unique, solving a problem that is slightly different from every previous problem. The carpenter analogy doesn\u0026rsquo;t work: cabinets are roughly like other cabinets. Features are not roughly like other features.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eWhat Pelrine\u0026rsquo;s work tells us is not \u0026ldquo;don\u0026rsquo;t estimate.\u0026rdquo; It tells us: \u003cstrong\u003eyou are applying an ordered-domain tool to an unordered-domain problem.\u003c/strong\u003e The answer is not to throw away the tool. It\u0026rsquo;s to use it with the appropriate epistemic humility - and to stop pretending the output is a commitment.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eThis also reframes an honest truth that most estimation advice dances around. \u003cstrong\u003e\u003cem\u003eEven great teams only produce mediocre estimates\u003c/em\u003e\u003c/strong\u003e. Not because they\u0026rsquo;re not skilled, but because there\u0026rsquo;s a hard ceiling on how accurate you can be in a Complex domain. The goal is not to get estimates right. The goal is to make useful decisions despite their inherent inaccuracy. Confusing those two goals is where most estimation dysfunction begins.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-cone-doesnt-lie-but-youre-ignoring-what-its-saying\"\u003eThe Cone Doesn\u0026rsquo;t Lie, But You\u0026rsquo;re Ignoring What It\u0026rsquo;s Saying\u003c/h2\u003e\n\u003cp\u003eSteve McConnell\u0026rsquo;s \u003ca href=\"https://www.construx.com/books/the-cone-of-uncertainty/\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eCone of Uncertainty\u003c/a\u003e is one of those concepts that everyone nods at and almost no one actually applies.\u003c/p\u003e\n\u003cp\u003eThe basic shape is simple: early in a project, your estimates can be off by a factor of 4x in either direction (and this number is still just an estimate). That\u0026rsquo;s a 16x total range. As the project progresses and unknowns get resolved - requirements clarify, architecture solidifies, the hard problems surface and get solved - the cone narrows. By the time you\u0026rsquo;re close to done, your estimates are nearly exact. (You also, at that point, no longer need them.)\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/estimation/cone-of-uncertainty-graphic_hu_3560979287bda868.jpg\"\n    srcset=\"/estimation/cone-of-uncertainty-graphic_hu_347dde12fa6fdbfb.webp 640w, /estimation/cone-of-uncertainty-graphic_hu_b0ba2ad6c3f0a035.webp 960w, /estimation/cone-of-uncertainty-graphic_hu_819bae3a68da8c40.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"998\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003cp\u003eThat last part is the irony: estimates become more reliable closer to completion, which is also when they\u0026rsquo;re least useful. Early on, when you\u0026rsquo;d most benefit from knowing the effort involved - when you can still change course or kill the project without wasted months - is precisely when you know the least. Most organizations make their firmest commitments at exactly that point.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTwo more things are worth sitting with.\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFirst: \u003cstrong\u003ethe cone represents the best case for skilled estimators.\u003c/strong\u003e It is not describing average teams with average practices. It\u0026rsquo;s describing what\u0026rsquo;s possible when you\u0026rsquo;re actually good at this. Most teams do worse. If your team commits to a date at the initial concept stage, \u003cem\u003eyou are not making a plan. You are making a wish - and then arranging your calendar around it.\u003c/em\u003e\u003c/li\u003e\n\u003cli\u003eSecond: \u003cstrong\u003ethe cone narrows only when you make decisions that eliminate variability.\u003c/strong\u003e Time alone does not narrow it. Defining scope narrows it. Resolving architectural unknowns narrows it. Actually writing code and discovering what\u0026rsquo;s hard narrows it. Spending three weeks in meetings does not. Building something teaches you more about its complexity than any amount of pre-work analysis. You quickly hit diminishing returns trying to reason your way to certainty. The real problems only surface when you start.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe practical consequence is something I\u0026rsquo;ve started saying long ago explicitly to stakeholders: \u003cstrong\u003ethe quality of our estimate depends on how far we are in the cone.\u003c/strong\u003e I won\u0026rsquo;t give you a two-week number in week one. I will give you a range, and I\u0026rsquo;ll tell you what has to be true for us to narrow it.\u003c/p\u003e\n\u003cp\u003eMost stakeholders, when you explain the cone to them, accept this. They\u0026rsquo;re not asking for false precision because they enjoy it. They\u0026rsquo;re asking because nobody ever told them they were allowed to ask for a range.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"why-fibonacci-and-not-hours\"\u003eWhy Fibonacci and Not Hours\u003c/h2\u003e\n\u003cp\u003eWhen teams do estimate, the Fibonacci scale - 1, 2, 3, 5, 8, 13, 21 - often gets taught as a quirky Agile ritual without an explanation that actually satisfies anyone. Let me try to give you one.\u003c/p\u003e\n\u003cp\u003eThe non-linearity is doing epistemic work.\u003c/p\u003e\n\u003cp\u003eWhen you estimate something as a 2 versus a 3, you\u0026rsquo;re saying: \u0026ldquo;I have a rough sense of the difference, but it\u0026rsquo;s marginal.\u0026rdquo; When you jump from 8 to 13, you\u0026rsquo;re encoding something much more important: \u003cstrong\u003ethe uncertainty band around this estimate is wider than the estimate itself.\u003c/strong\u003e A 13-point story doesn\u0026rsquo;t mean \u0026ldquo;I know exactly how big this is, and it\u0026rsquo;s 13.\u0026rdquo; It means \u0026ldquo;I think this is in a category of work that is significantly more uncertain than an 8, and probably not as uncertain as a 21. Don\u0026rsquo;t ask me to be more precise than that.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe gaps between Fibonacci numbers grow in a way that mirrors how complexity actually scales. Small things are roughly estimable. Large things become exponentially harder to predict because they contain more unknowns, more integration points, more opportunities for surprise. By the time a story is a 21 (or, some would say, 13), the honest conversation is: \u0026ldquo;This story should probably be split, because an estimate of 21 is essentially us saying we don\u0026rsquo;t understand the work yet.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThe other underappreciated function of Fibonacci estimation is what happens \u003cem\u003eduring\u003c/em\u003e the estimation conversation. When one person says 3 and another says 13, the point value is almost irrelevant. What matters is why two people on the same team, looking at the same story, saw it so differently. Maybe one saw a dependency the other missed. Maybe one knew about a technical constraint that wasn\u0026rsquo;t in the ticket.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThat conversation - the one forced by disagreement - is often where the real work of refinement happens.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cstrong\u003eThe biggest value in estimating isn\u0026rsquo;t the estimate. It\u0026rsquo;s checking whether there is a common understanding.\u003c/strong\u003e The number is almost a side effect. Remove the forcing function, and that shared understanding often doesn\u0026rsquo;t form until someone is three days into a task and hits the hidden complexity.\u003c/p\u003e\n\u003cp\u003eThis is why I find the #NoEstimates argument that \u0026ldquo;estimation meetings are waste\u0026rdquo; unpersuasive. Done right, those conversations are where alignment happens. You can absolutely run them badly - and most teams do. But the answer to a badly run meeting is not to cancel the meeting.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-commitment-trap-and-how-to-avoid-it\"\u003eThe Commitment Trap (And How to Avoid It)\u003c/h2\u003e\n\u003cp\u003eThe deepest dysfunction the #NoEstimates movement was responding to is this: \u003cstrong\u003eestimates become commitments through social pressure, not logic.\u003c/strong\u003e Nobody in a healthy organization should be able to take an estimate made under uncertainty and treat it as a promise. But it happens constantly, for understandable reasons: people need to plan, plans need dates, and dates need to come from somewhere.\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a related failure mode that\u0026rsquo;s just as damaging, and it\u0026rsquo;s about \u003cem\u003ewho\u003c/em\u003e creates the estimate. When people who aren\u0026rsquo;t doing the work invent a timeline and throw it over the fence to the teams, you get the worst of all worlds: an inaccurate estimate \u003cem\u003eand\u003c/em\u003e a team with no ownership of the number. Now, when reality diverges - and it will - nobody knows whose fault it is, so everyone blames everyone. The people executing the work must always own the estimate. Imposing estimates on others is not optimism. It\u0026rsquo;s a blame-game waiting to happen.\u003c/p\u003e\n\u003cp\u003eWhen deadline obsession takes hold, something else happens too. Like a mirage in the desert, the looming date becomes the only thing anyone can see. Every conversation collapses into \u0026ldquo;how do we hit the deadline?\u0026rdquo; The question of whether you\u0026rsquo;re building the right thing - whether the work is actually good - slides quietly out of view. The deadline wasn\u0026rsquo;t wrong because the estimate was imprecise. It was wrong because the estimate became the mission.\u003c/p\u003e\n\u003cp\u003eThe way I\u0026rsquo;ve navigated this is by separating three things (and working with my stakeholders to have agreement on this) that most organizations conflate:\u003c/p\u003e\n\u003col\u003e\n\u003cli\u003eAn \u003cstrong\u003eestimate\u003c/strong\u003e is a probabilistic forecast made under current levels of uncertainty. It should come with a range and an explicit statement of what assumptions it rests on. \u0026ldquo;We think this is 4-6 weeks, assuming requirements don\u0026rsquo;t change and we get answers on the API question by next Friday.\u0026rdquo;\u003c/li\u003e\n\u003cli\u003eA \u003cstrong\u003eplan\u003c/strong\u003e is a commitment to a process, not an outcome. \u0026ldquo;We will work for two weeks, review progress, and give you an updated forecast.\u0026rdquo; Plans are things you can keep. Estimates are things you can only be more or less accurate about.\u003c/li\u003e\n\u003cli\u003eA \u003cstrong\u003ecommitment\u003c/strong\u003e is a promise with consequences. It should be made rarely, deliberately, and only when the cone has narrowed enough to warrant it. Committing at the initial concept stage is not bold. It\u0026rsquo;s reckless. When somebody forces you to commit to something, try only committing to priorities, not timelines. If that doesn\u0026rsquo;t work, make the level of confidence part of the commitment.\u003c/li\u003e\n\u003c/ol\u003e\n\u003cp\u003eThe dysfunction happens when organizations treat estimates as commitments from the moment they\u0026rsquo;re spoken. The political solution to that - which is what #NoEstimates often actually is, in practice - is to never speak a number at all. I understand the instinct. But the cost is that your organization loses its ability to reason about resource allocation, sequence dependencies, or have honest conversations with external stakeholders.\u003c/p\u003e\n\u003cp\u003eThe better solution is to teach the cone. Teach the stakeholders. Make the distinction between estimate and commitment explicit every single time you give a number. It\u0026rsquo;s harder than refusing to estimate, and it takes longer to work. But it builds trust, instead of just avoiding the situations where trust could be broken.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"what-good-estimation-practice-actually-looks-like\"\u003eWhat Good Estimation Practice Actually Looks Like\u003c/h2\u003e\n\u003cp\u003eI won\u0026rsquo;t pretend I have a perfect system. I don\u0026rsquo;t. But across the teams I\u0026rsquo;ve managed, a few patterns have consistently made estimation more honest and more useful.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eEstimate late, not early.\u003c/strong\u003e The cone narrows only through learning. Do spikes. Write some exploratory code. Talk to the teams whose systems you\u0026rsquo;ll integrate with. Work with what you do know to discover what you don\u0026rsquo;t know. Resist the pressure to give numbers before you\u0026rsquo;ve done the learning that would make them meaningful.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDon\u0026rsquo;t over-decompose before starting.\u003c/strong\u003e This one is counterintuitive, and I\u0026rsquo;ve watched teams fall into it repeatedly. The instinct when facing uncertainty is to break the work down into ever-smaller pieces, hoping that enough decomposition will produce a reliable estimate. It won\u0026rsquo;t - and the time spent in those sessions is time you\u0026rsquo;re not spending learning from actual work. There\u0026rsquo;s a real cost here that\u0026rsquo;s easy to miss: elaborate pre-work plans also calcify. Teams cling to them past the point where they reflect reality, which makes the eventual divergence more disorienting, not less. Start with simpler plans that are easier to adjust.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eGive ranges, not points.\u003c/strong\u003e \u0026ldquo;Three to five weeks\u0026rdquo; is more honest than \u0026ldquo;four weeks\u0026rdquo; and almost as actionable. If someone says they can only work with a single number, give them the midpoint of your range - but tell them it\u0026rsquo;s a midpoint. Never let a range collapse into a point estimate in their mind without your knowledge. Agree on using the cone of uncertainty with your stakeholders and refer to it whenever you\u0026rsquo;re communicating estimates.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eMake your assumptions visible.\u003c/strong\u003e An estimate is only as good as what it assumes. If the estimate assumes no scope changes, say so. If it assumes a particular technical approach, say so. If it assumes someone else\u0026rsquo;s team delivers something by a certain date, say so. Assumptions that live in your head become misunderstandings that surface at the worst moment.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTrack accuracy over time - without punishment.\u003c/strong\u003e Not to blame people. To calibrate. Teams that have been estimating together for six months and reviewing their accuracy develop a shared sense of where they systematically over- or underestimate. That calibration is genuinely useful, and it compounds over time. But punishing inaccurate estimates achieves the opposite: it teaches teams to pad estimates defensively, and padded estimates are even less useful than honest uncertain ones. Wrong estimates in a complex domain are not a character failing. They\u0026rsquo;re a property of the domain.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSplit anything over 8.\u003c/strong\u003e A story that\u0026rsquo;s a 13 or a 21 on the Fibonacci scale is almost always a story that contains hidden complexity you haven\u0026rsquo;t surfaced yet. The act of splitting it forces you to articulate what you actually know. Often, you discover that two of the three sub-stories are actually small, and one is where all the uncertainty lives. Now you have useful information.\u003c/p\u003e\n\u003chr\u003e\n\u003ch2 id=\"the-uncomfortable-truth-for-both-camps\"\u003eThe Uncomfortable Truth for Both Camps\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s what I think is actually true, and I\u0026rsquo;ve found it unpopular in equal measure with both estimation enthusiasts and #NoEstimates advocates.\u003c/p\u003e\n\u003cp\u003eEstimates are a form of communication, not calculation. Their purpose is to enable coordination and decision-making under uncertainty - not to predict the future. The failure modes of estimation are not random. They are systematic: estimating too early, treating ranges as points, treating estimates as commitments, ignoring what the Cone of Uncertainty tells you about epistemic position, imposing estimates on the people who have to execute them.\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a trap worth naming here - what Dalmijn calls the \u003ca href=\"https://mdalmijn.com/p/11-laws-of-software-estimation-for-complex-work\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u003cem\u003eComplex Work Estimation Fallacy\u003c/em\u003e\u003c/a\u003e: the belief that by estimating more often, refining the process, and working together longer, a team will eventually produce accurate estimates. It won\u0026rsquo;t. The ceiling on estimation accuracy in a Complex domain is not a function of team maturity. It\u0026rsquo;s a function of the domain itself. You can get better. You will not get accurate. Confusing those two outcomes is how organizations end up punishing teams for things that are fundamentally outside their control.\u003c/p\u003e\n\u003cp\u003eRefusing to estimate doesn\u0026rsquo;t fix any of this. It just opts out of the coordination game. For a team that truly operates independently, ships constantly, and has no external commitments - that might work. Those teams exist. I\u0026rsquo;ve been on one. It was a specific organizational context that most of us will not be in for most of our careers.\u003c/p\u003e\n\u003cp\u003eFor everyone else, the choice is not between \u0026ldquo;bad estimates\u0026rdquo; and \u0026ldquo;no estimates.\u0026rdquo; The choice is between \u003cstrong\u003eunconscious, low-quality estimates\u003c/strong\u003e (which your organization will make anyway, with or without you) and \u003cstrong\u003eexplicit, humble, range-based, assumption-visible estimates\u003c/strong\u003e that give the people around you something real to work with.\u003c/p\u003e\n\u003cp\u003eJoseph Pelrine was right that task estimation lives in the Complex domain. That\u0026rsquo;s exactly why we need to approach it with a complexity mindset: probe, observe, respond. Estimate, track, calibrate. Do it again. The cone doesn\u0026rsquo;t narrow by waiting. It narrows by learning.\u003c/p\u003e\n\u003cp\u003eStop trying to get out of estimating. Start getting better at it - and clear-eyed about how good \u0026ldquo;better\u0026rdquo; can actually get.\u003c/p\u003e\n","date_modified":"2026-03-19T10:16:00Z","date_published":"2026-03-19T10:16:00Z","id":"https://leadership.garden/estimation/","summary":"Why refusing to estimate doesn't solve your team's coordination problems - and what to do instead. For engineering leaders who are tired of broken planning.","tags":["estimation","communication","conflict"],"title":"Why Estimates Fail (And Why You Still Need Them)","url":"https://leadership.garden/estimation/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eA few years ago I was convinced we had a delivery problem. The evidence was everywhere. Features took weeks longer than estimated. The team was visibly busy, always in motion, always context-switching. Sprint reviews felt like triage sessions. My instinct was to look at the board, find where work was piling up, and fix that stage in the pipeline. I identified a bottleneck in code review. Senior engineers were overloaded. We redistributed review assignments, set \u003ca href=\"https://kanbanize.com/kanban-resources/getting-started/what-is-wip\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eWIP limits\u003c/a\u003e, started tracking review cycle time. It helped, a little, for a few sprints.\u003c/p\u003e\n\u003cp\u003eThen the same symptoms came back. Just upstream now.\u003c/p\u003e\n\u003cp\u003eIt took me longer than I\u0026rsquo;d like to admit to realize I was solving the wrong problem. The real constraint wasn\u0026rsquo;t on anyone\u0026rsquo;s Jira board. It was in a recurring meeting I ran every Tuesday, where nothing got decided without my sign-off. It was in a deployment process that required three approvals, two of which routed to me. It was in the implicit rule, never written down, that architectural decisions needed to go through my inbox before moving forward.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eI was the constraint.\u003c/strong\u003e And I was the last person to see it.\u003c/p\u003e\n\u003cp\u003eThis post is about the \u003ca href=\"https://en.wikipedia.org/wiki/Theory_of_constraints\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eTheory of Constraints\u003c/a\u003e and why most engineering teams apply it too shallowly. If you manage a team or run an engineering organization, you\u0026rsquo;ve almost certainly read about TOC at the five-steps level. You\u0026rsquo;ve heard about identifying your bottleneck, exploiting it, and subordinating everything else.\u003c/p\u003e\n\u003cp\u003eWhat I want to talk about is the class of constraints that never appears in your metrics, never shows up in a retrospective, and is actively invisible to the person who created it: \u003cstrong\u003epolicy constraints\u003c/strong\u003e and the leadership behaviors that produce them.\u003c/p\u003e\n\u003ch2 id=\"what-toc-actually-says-briefly\"\u003eWhat TOC actually says, briefly\u003c/h2\u003e\n\u003cp\u003e\u003ca href=\"https://en.wikipedia.org/wiki/Eliyahu_M._Goldratt\" target=\"_blank\" rel=\"noopener noreferrer\"\u003eEliyahu Goldratt\u003c/a\u003e introduced the Theory of Constraints in 1984 through a novel called \u003ca href=\"https://en.wikipedia.org/wiki/The_Goal_%28novel%29\" target=\"_blank\" rel=\"noopener noreferrer\"\u003e\u003cem\u003eThe Goal\u003c/em\u003e\u003c/a\u003e. The core idea is simple enough to fit in one sentence: every system has exactly one primary constraint limiting its throughput, and improving anything that isn\u0026rsquo;t that constraint produces no real improvement in overall output.\u003c/p\u003e\n\u003cp\u003eThe \u003ca href=\"https://en.wikipedia.org/wiki/Theory_of_constraints#The_five_focusing_steps\" target=\"_blank\" rel=\"noopener noreferrer\"\u003efive focusing steps\u003c/a\u003e follow from this: identify the constraint, exploit it (squeeze more out of it without adding resources), subordinate everything else to it, elevate it if needed, then repeat because a new constraint will always emerge.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m not going to walk you through each step in detail. That content exists in abundance. What I want to focus on is what the framework says about \u003cem\u003etypes\u003c/em\u003e of constraints, because this is where most engineering teams stop reading too early.\u003c/p\u003e\n\u003cp\u003eGoldratt distinguished between physical constraints, resource constraints, and \u003ca href=\"https://en.wikipedia.org/wiki/Theory_of_constraints#Types_of_constraints\" target=\"_blank\" rel=\"noopener noreferrer\"\u003epolicy constraints\u003c/a\u003e. Physical and resource constraints are the ones everyone talks about: the single DBA, the slow CI build, the overwhelmed QA engineer. Policy constraints are different. They\u0026rsquo;re written or unwritten rules, explicit or implicit, that prevent the system from achieving higher performance. They don\u0026rsquo;t show up as a queue building somewhere. They show up as decisions that can\u0026rsquo;t get made, work that can\u0026rsquo;t start, and autonomy that never quite materializes.\u003c/p\u003e\n\u003cp\u003ePolicy constraints are almost always the hardest to identify and the most common in mature engineering organizations. They\u0026rsquo;re also almost always created, sustained, and invisible to leadership.\u003c/p\u003e\n\u003ch2 id=\"the-visible-bottleneck-is-not-the-real-problem\"\u003eThe visible bottleneck is not the real problem\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s a pattern I\u0026rsquo;ve seen repeatedly. A team identifies slow code review as their bottleneck. They fix it: better tooling, clearer standards, review rotation. Throughput improves for a sprint or two. Then it stalls. They look again and find a new bottleneck: integration testing, or handoff to QA, or waiting for product clarification before the next feature can begin.\u003c/p\u003e\n\u003cp\u003eThey celebrate fixing bottlenecks and keep moving them downstream. The team feels productive. The metrics actually improve. But delivery time stays stubbornly long and nobody can quite explain why.\u003c/p\u003e\n\u003cp\u003eThe explanation, usually, is that the technical bottlenecks were real but secondary. The primary constraint was sitting somewhere else: in approval structures, in unclear ownership, in a process where certain decisions require a certain level of sign-off that isn\u0026rsquo;t available on the team\u0026rsquo;s timescale. Fixing code review speeds up work flowing into the constraint. It does nothing to the constraint itself.\u003c/p\u003e\n\u003cp\u003eGoldratt\u0026rsquo;s point was precise: \u003cstrong\u003eany improvement made anywhere besides the constraint is an illusion\u003c/strong\u003e. Not a small win, not progress with caveats. An illusion. That\u0026rsquo;s a strong claim and it\u0026rsquo;s worth sitting with.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve spent time mapping delivery pipelines in detail, tracking cycle times at each stage, building dashboards that show where work queues up. The honest lesson I came away with is that the data almost always points to a symptom rather than a root cause. The queue in front of QA is a symptom. What\u0026rsquo;s causing the queue? Sometimes it\u0026rsquo;s QA capacity. Often it\u0026rsquo;s that tickets arrive without adequate acceptance criteria because the product process is broken. Sometimes it\u0026rsquo;s that certain work bypasses normal flow entirely because a senior leader wants it fast-tracked, which shunts everything else backward without anyone noticing at the aggregate level.\u003c/p\u003e\n\u003cblockquote\u003e\n\u003cp\u003eThese causes don\u0026rsquo;t appear on your Jira board. They require a different kind of investigation.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003e\u003cimg\n    src=\"/theory-of-constraints/viz3_wait_vs_work_1_hu_c41998d1ee0cb06e.png\"\n    srcset=\"/theory-of-constraints/viz3_wait_vs_work_1_hu_8f5bd152fb36ba2f.webp 640w, /theory-of-constraints/viz3_wait_vs_work_1_hu_592424d84795013b.webp 960w, /theory-of-constraints/viz3_wait_vs_work_1_hu_cf2ceefa0b83b685.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"592\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"how-to-actually-find-policy-constraints\"\u003eHow to actually find policy constraints\u003c/h2\u003e\n\u003cp\u003eThe technique I find most useful is what I think of as the \u0026ldquo;why can\u0026rsquo;t we just\u0026rdquo; test. Walk through your delivery process and ask that question at every point of friction.\u003c/p\u003e\n\u003cp\u003eWhy can\u0026rsquo;t we just deploy when the feature is ready? \u0026ldquo;We need a release window sign-off.\u0026rdquo; Why does that sign-off exist? \u0026ldquo;Because a VP wants visibility before anything goes to production.\u0026rdquo; Why does that VP want visibility at that point rather than earlier? \u0026ldquo;Because there was an incident three years ago and they added the step.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s a policy constraint. Nobody intended to slow the team down. The incident was real. The response felt proportionate at the time. But the policy outlived the situation that created it and is now a permanent drag on throughput.\u003c/p\u003e\n\u003cp\u003eThe questions to ask systematically:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eWhere do teams wait for a decision from someone not on the team?\u003c/li\u003e\n\u003cli\u003eWhere does work require approval from someone unavailable during normal working hours?\u003c/li\u003e\n\u003cli\u003eWhat cannot happen without a specific person\u0026rsquo;s involvement, not because of expertise, but because of authority?\u003c/li\u003e\n\u003cli\u003eWhat process exists because of a past incident, and has anyone evaluated whether it still makes sense?\u003c/li\u003e\n\u003cli\u003eWhat would the team do differently if the leader weren\u0026rsquo;t watching?\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThat last question is the most revealing. In my experience, engineers are exceptionally good at working around policy constraints when the alternative is shipping nothing. They find informal paths. They batch decisions to minimize approval wait time. They under-document to avoid triggering a review process. These adaptations are rational responses to a system that doesn\u0026rsquo;t trust them. The workarounds are the signal.\u003c/p\u003e\n\u003ch2 id=\"the-leader-as-constraint\"\u003eThe leader as constraint\u003c/h2\u003e\n\u003cp\u003eI want to be direct here, because most writing on this topic stays diplomatic.\u003c/p\u003e\n\u003cp\u003eSenior engineering leaders are among the most common constraints in their own organizations. Not because they\u0026rsquo;re bad leaders. Not because they don\u0026rsquo;t care about throughput. Because the same instincts that make someone good at leading a small team, being involved, having standards, wanting visibility, become system-level bottlenecks as the organization scales.\u003c/p\u003e\n\u003cp\u003eThe approval that gave a junior team confidence at 10 people becomes a queue at 50. The architectural opinion that produced good decisions when one person could hold the whole system in their head becomes a gatekeeping mechanism when the system is too large for that. The \u0026ldquo;quick sync before we finalize this\u0026rdquo; that saved a project once is now a recurring tax on every decision.\u003c/p\u003e\n\u003cp\u003e(I\u0026rsquo;ve caught myself doing all of these. None of it felt like creating a constraint in the moment. It felt like being a responsible leader.)\u003c/p\u003e\n\u003cp\u003eThe TOC framework applied honestly to leadership behavior asks a specific question: what decisions and activities require my unique capability, and which ones just require my permission? The former are genuinely hard to delegate. The latter are almost always policy constraints you can dissolve.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe test is simple: if you were unavailable for two weeks, what would stop?\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot what would go worse. Not what would benefit from your input. What would actually, operationally stop? Those are your constraints. Everything that would continue, perhaps differently than you\u0026rsquo;d like but continue, is subordination you\u0026rsquo;ve imposed on the system unnecessarily.\u003c/p\u003e\n\u003ch2 id=\"why-subordination-is-politically-hard\"\u003eWhy subordination is politically hard\u003c/h2\u003e\n\u003cp\u003eGoldratt\u0026rsquo;s third step, subordinating everything else to the constraint, is the one most organizations skip or misapply. The instruction is straightforward: align all non-constraint activities to support the constraint\u0026rsquo;s maximum throughput, even if that means deliberately operating some resources below full capacity.\u003c/p\u003e\n\u003cp\u003eIn practice, this is deeply uncomfortable.\u003c/p\u003e\n\u003cp\u003eIt means telling a high-performing team to slow their output because feeding work faster into the constraint doesn\u0026rsquo;t help, it just builds a queue. It means some people look less busy. It means local efficiency metrics get worse for the sake of global throughput. And it means someone has to explain to an ambitious engineer or a driven team lead why they should do less.\u003c/p\u003e\n\u003cp\u003eMost engineering organizations reward local optimization. The team that ships most features, the individual who closes most tickets, the service with the best uptime. These metrics are visible and feel meaningful. TOC says they are often measuring the wrong thing, and that optimizing them can actively hurt overall system performance by hiding where the real work needs to happen.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve tried to make this concrete by reframing the goal explicitly with my teams. The goal is not utilization. The goal is throughput. A team that is \u0026ldquo;only\u0026rdquo; 60% utilized but consistently unblocking the constraint is contributing more than a team running at 100% on work that queues behind a bottleneck they\u0026rsquo;re not helping to fix.\u003c/p\u003e\n\u003cp\u003eThat\u0026rsquo;s a hard sell. It requires trust. It requires people to believe you\u0026rsquo;re measuring what matters rather than what\u0026rsquo;s easy. And it requires that the constraint actually gets fixed, not just identified and left.\u003c/p\u003e\n\u003ch2 id=\"identifying-your-real-constraint-a-practical-approach\"\u003eIdentifying your real constraint: a practical approach\u003c/h2\u003e\n\u003cp\u003eI want to give you something concrete you can do after reading this.\u003c/p\u003e\n\u003cp\u003eMap your \u003ca href=\"https://en.wikipedia.org/wiki/Value-stream_mapping\" target=\"_blank\" rel=\"noopener noreferrer\"\u003evalue stream\u003c/a\u003e. Not the happy path. The actual, messy path that work takes from idea to production. Include the informal steps: the Slack message asking for clarification, the meeting scheduled to get alignment, the ticket that waits because the relevant engineer is in planning all week. Include wait time, not just active work time. In my experience, the ratio of wait time to active work time in most software organizations is somewhere between 3:1 and 10:1. The bottleneck is almost always in the waiting, not the doing.\u003c/p\u003e\n\u003cp\u003eThen look for decisions that require specific authority. Not expertise: authority. These are almost always policy constraints rather than resource constraints. A resource constraint can be addressed by adding capacity or redistributing work. A policy constraint requires someone with the authority to change the policy to do so, and that person is frequently the one who benefits from the policy existing.\u003c/p\u003e\n\u003cp\u003eThen run the \u0026ldquo;why can\u0026rsquo;t we just\u0026rdquo; exercise from the end of the pipeline backwards. Start at deployment, work back toward ideation. Every friction point is either a genuine technical constraint, a resource constraint, or a policy constraint. Label them. You\u0026rsquo;ll find that the policy constraints cluster around the middle of the process, around the points where decisions cross team or organizational boundaries.\u003c/p\u003e\n\u003cp\u003eFinally, and this is the uncomfortable part: \u003cstrong\u003eask someone junior to do this analysis for you\u003c/strong\u003e. Engineers two or three levels below you see the constraint with perfect clarity. They\u0026rsquo;ve been adapting to it for months. They\u0026rsquo;ve built workarounds. They have opinions about exactly what would change if leadership removed itself from the critical path. They often won\u0026rsquo;t volunteer this information unprompted because doing so feels presumptuous or unsafe.\u003c/p\u003e\n\u003cp\u003eAsk directly. Create conditions where the honest answer is welcome. The information is already in your organization. It\u0026rsquo;s just waiting for permission to surface.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/theory-of-constraints/viz2_policy_map_hu_4e00e189e8160493.png\"\n    srcset=\"/theory-of-constraints/viz2_policy_map_hu_386f78154e180685.webp 640w, /theory-of-constraints/viz2_policy_map_hu_f473a71cfd082fa8.webp 960w, /theory-of-constraints/viz2_policy_map_hu_f6fe158335f282d6.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"745\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"what-actually-changes-when-you-fix-a-policy-constraint\"\u003eWhat actually changes when you fix a policy constraint\u003c/h2\u003e\n\u003cp\u003eWhen I eventually addressed the approval chain that was running through me, the change felt smaller than I expected and larger than I could have predicted.\u003c/p\u003e\n\u003cp\u003eThe immediate effect was that certain decisions got made faster. Not dramatically faster, within the span of a few hours rather than a day or two. It didn\u0026rsquo;t feel revolutionary. But the compounding effect over several months was significant. Engineers started making decisions earlier in the process rather than waiting until the last moment to ask permission. They took more ownership of outcomes because they bore more responsibility for choices. The quality of the decisions, to my pleasant surprise, was fine.\u003c/p\u003e\n\u003cp\u003eThe second-order effect was the one I hadn\u0026rsquo;t anticipated: teams started surfacing problems earlier. When the path from \u0026ldquo;I see an issue\u0026rdquo; to \u0026ldquo;we can address it\u0026rdquo; is short and doesn\u0026rsquo;t require escalation, people bring things up when they\u0026rsquo;re small. When every decision requires approval, people solve what they can locally and escalate only when a problem has grown large enough to justify the overhead. You end up discovering problems later, when they\u0026rsquo;re more expensive to fix.\u003c/p\u003e\n\u003cp\u003eGoldratt described this dynamic as the constraint suppressing information about the system\u0026rsquo;s actual state. When you remove a policy constraint, you don\u0026rsquo;t just increase throughput. You improve the quality of your organizational signal. You find out earlier what\u0026rsquo;s actually happening.\u003c/p\u003e\n\u003ch2 id=\"the-constraint-will-move-be-ready\"\u003eThe constraint will move. Be ready.\u003c/h2\u003e\n\u003cp\u003eOne thing TOC gets right that most improvement frameworks ignore: the constraint moves when you fix it. This is not a failure. This is the system working.\u003c/p\u003e\n\u003cp\u003eWhen you remove a policy constraint from your own behavior, you should expect a new constraint to emerge somewhere else in the system. Maybe QA actually does become the bottleneck once the approval overhead is removed. Maybe the team\u0026rsquo;s architectural decision quality drops because they\u0026rsquo;ve been operating inside tight guardrails for so long that the muscle for independent judgment hasn\u0026rsquo;t developed. These are real and solvable problems, and they\u0026rsquo;re much better problems to have than a permanent constraint baked into leadership behavior.\u003c/p\u003e\n\u003cp\u003eThe mistake is treating constraint resolution as a project with an end state. You removed the bottleneck, you declare victory, you move on. A few months later the same symptoms reappear and leadership is confused. TOC is a process of ongoing improvement, not a one-time fix. The five steps are a cycle, not a checklist.\u003c/p\u003e\n\u003cp\u003eI try to run a lightweight constraint review every quarter. Not a formal process. Just a structured conversation with team leads: where is work consistently getting stuck, and why? What decisions require input from outside the team that could be made inside the team if the right guardrails were in place? What permissions are people waiting for that could be pre-granted through a clearer policy?\u003c/p\u003e\n\u003cp\u003eThis is the practice that makes TOC useful rather than just interesting as a framework.\u003c/p\u003e\n\u003cp\u003e\u003cimg\n    src=\"/theory-of-constraints/viz4_constraint_moves_hu_11258cde523c5ae.png\"\n    srcset=\"/theory-of-constraints/viz4_constraint_moves_hu_e9d97a8d6baca742.webp 640w, /theory-of-constraints/viz4_constraint_moves_hu_a5c7082e9d34343d.webp 960w, /theory-of-constraints/viz4_constraint_moves_hu_f586fe8d900f60fc.webp 1280w\"\n    sizes=\"(min-width: 1024px) 896px, 100vw\"\n    alt=\"\"\n    width=\"1280\"\n    height=\"609\"\n    loading=\"lazy\"\n    decoding=\"async\"\n  /\u003e\u003c/p\u003e\n\u003ch2 id=\"on-not-confusing-busyness-with-throughput\"\u003eOn not confusing busyness with throughput\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a deeper idea underneath all of this that I want to name explicitly, because it affects how engineering leaders think about their job.\u003c/p\u003e\n\u003cp\u003eMost of us were promoted because we were individually effective. We solved problems, shipped features, made good technical decisions. The incentives that shaped us rewarded doing: output, velocity, completion. Management asks us to shift that orientation toward \u003cem\u003eenabling\u003c/em\u003e rather than \u003cem\u003edoing\u003c/em\u003e, but it doesn\u0026rsquo;t always give us a clear signal for when we\u0026rsquo;re succeeding.\u003c/p\u003e\n\u003cp\u003eTOC provides one such signal: throughput. Not the throughput of any individual or team, but of the whole system from idea to delivered value. If that number is improving, something is working. If it\u0026rsquo;s stagnant despite local improvements, you have a constraint you haven\u0026rsquo;t found yet.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eThe most important question an engineering leader can ask isn\u0026rsquo;t \u0026ldquo;Is the team busy?\u0026rdquo; It\u0026rsquo;s \u0026ldquo;Is value flowing?\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eTOC even offers a concrete accounting lens for this: \u003ca href=\"https://en.wikipedia.org/wiki/Throughput_accounting\" target=\"_blank\" rel=\"noopener noreferrer\"\u003ethroughput accounting\u003c/a\u003e, which shifts focus from cost-cutting to measuring how fast value moves through the whole system. It\u0026rsquo;s a different way of evaluating decisions, and it reframes what \u0026ldquo;good\u0026rdquo; looks like for a leader.\u003c/p\u003e\n\u003cp\u003eThose two things can look identical from the outside and produce completely different outcomes. A team generating a lot of local activity while work piles up at an unaddressed constraint is busy and low-throughput at the same time. It\u0026rsquo;s an exhausting and demoralizing place to work, even if the sprint burndown looks healthy.\u003c/p\u003e\n\u003cp\u003eWhen I\u0026rsquo;ve been most effective as a leader, it wasn\u0026rsquo;t because I was maximally involved. It was because I had identified where my involvement was a bottleneck and deliberately removed it. That felt, at first, like doing less. It was actually doing the right thing.\u003c/p\u003e\n\u003ch2 id=\"start-here\"\u003eStart here\u003c/h2\u003e\n\u003cp\u003eIf you want to apply this, start with one question this week.\u003c/p\u003e\n\u003cp\u003ePick the last feature or project that took significantly longer than it should have. Map, informally and honestly, where time was spent. Not just active development time: total elapsed time, from the decision to start to the moment it was delivered. Find the longest wait. Ask why that wait existed. Follow the answer until it reaches either a person, a process, or a rule.\u003c/p\u003e\n\u003cp\u003eIf it reaches a person: is that a capacity problem, or is that person a decision chokepoint? If the latter, that\u0026rsquo;s a policy constraint.\u003c/p\u003e\n\u003cp\u003eIf it reaches a process: who created the process, and does it still solve the problem it was created to solve?\u003c/p\u003e\n\u003cp\u003eIf it reaches a rule: where is the rule written down, and when was it last revisited?\u003c/p\u003e\n\u003cp\u003eThe answer is already in your organization. You don\u0026rsquo;t need a consultant, a new tool, or a workshop. You need to ask honestly and then be willing to hear what comes back.\u003c/p\u003e\n\u003cp\u003eThe constraint you\u0026rsquo;re looking for probably isn\u0026rsquo;t on any board. But the people on your team know exactly where it is. They\u0026rsquo;ve been working around it for months.\u003c/p\u003e\n\u003cp\u003eGo ask them.\u003c/p\u003e\n","date_modified":"2026-03-14T14:14:28Z","date_published":"2026-03-14T14:14:28Z","id":"https://leadership.garden/theory-of-constraints/","summary":"Your Jira board shows process bottlenecks. It won't show you the approval chains, implicit rules, and leadership behaviors killing your team's throughput.","tags":["productivity","teams","process"],"title":"The Constraint You Won't Find on a Jira Board","url":"https://leadership.garden/theory-of-constraints/"},{"authors":[{"name":"Csaba Okrona"}],"content_html":"\u003cp\u003eMost engineering managers I\u0026rsquo;ve worked with have the same problem, and it\u0026rsquo;s not the one they think.\u003c/p\u003e\n\u003cp\u003eThey think they need to coach more. They\u0026rsquo;ve read the books, attended the workshops, internalized the message that great managers ask questions instead of giving answers. They\u0026rsquo;ve been told, repeatedly, by people they respect, that their job is to \u0026ldquo;unlock potential\u0026rdquo; and \u0026ldquo;empower their teams.\u0026rdquo; If someone on their team is struggling, the prescription is always the same: ask better questions. Be curious. Hold space. Coach.\u003c/p\u003e\n\u003cp\u003eI think a lot of them are coaching too much. And I think many of them are doing it for themselves, not for the people they manage.\u003c/p\u003e\n\u003cp\u003eThis is a post for engineering managers, new and experienced, who have a nagging feeling that something about the coaching-first orthodoxy doesn\u0026rsquo;t quite fit. Who have sat in a 1:1, asked a string of open-ended questions, and watched their report\u0026rsquo;s face go from hopeful to frustrated. Who suspect that sometimes, the most helpful thing they could do is just \u003cem\u003esay the thing\u003c/em\u003e.\u003c/p\u003e\n\u003ch2 id=\"how-we-got-here\"\u003eHow we got here\u003c/h2\u003e\n\u003cp\u003eThe coaching-first movement in management isn\u0026rsquo;t wrong. It emerged from a real problem.\u003c/p\u003e\n\u003cp\u003eFor decades, the default management style, especially in engineering, was command and control. Managers hoarded context, made decisions unilaterally, and treated their reports as executors of their vision. The senior engineer would come to their manager with a technical problem, and the manager would say \u0026ldquo;do it this way\u0026rdquo; without understanding the constraints. Or worse, the manager had been promoted out of their technical depth and was directing work they couldn\u0026rsquo;t actually evaluate.\u003c/p\u003e\n\u003cp\u003eThe coaching model was a corrective to this. And it\u0026rsquo;s a good corrective. When you ask questions instead of giving answers, you force yourself to listen. You help people develop their own judgment instead of creating dependency on yours. You learn things about the problem that you wouldn\u0026rsquo;t have learned if you\u0026rsquo;d just started talking.\u003c/p\u003e\n\u003cp\u003eI practiced this heavily at my last two companies, and it genuinely made me a better manager. I learned to shut up in 1:1s. I learned to ask \u0026ldquo;what have you tried?\u0026rdquo; before jumping to solutions. I learned that the best outcome of a conversation is often the other person arriving at an insight they own, rather than one I handed them.\u003c/p\u003e\n\u003cp\u003eBut here\u0026rsquo;s what I\u0026rsquo;ve also learned: \u003cstrong\u003ethe coaching model has become so dominant that questioning it feels almost heretical.\u003c/strong\u003e It\u0026rsquo;s the water we swim in. Every management book, every leadership course, every conference talk reinforces the same message. Coach, don\u0026rsquo;t tell. Ask, don\u0026rsquo;t direct. Empower, don\u0026rsquo;t decide.\u003c/p\u003e\n\u003cp\u003eAnd when something becomes orthodoxy, people stop thinking about when it doesn\u0026rsquo;t apply.\u003c/p\u003e\n\u003ch2 id=\"the-three-failure-modes\"\u003eThe three failure modes\u003c/h2\u003e\n\u003cp\u003eI\u0026rsquo;ve seen coaching go wrong in three distinct ways. Each one is common enough that I\u0026rsquo;d bet most engineering managers reading this have done at least one of them in the past month.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFailure mode 1: Coaching when someone needs an answer.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eAn engineer comes to you and asks: \u0026ldquo;Should I use approach A or approach B for this migration?\u0026rdquo; They\u0026rsquo;ve thought about it. They have context. They\u0026rsquo;re not stuck because they lack critical thinking skills. They\u0026rsquo;re stuck because they lack a piece of information you have, or because they need someone with authority to make a call so the team can move forward.\u003c/p\u003e\n\u003cp\u003eAnd instead of answering, you say: \u0026ldquo;Well, what do you think? What are the tradeoffs of each approach?\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve done this. It feels like good management. It feels like you\u0026rsquo;re developing their decision-making skills. But from the other side of the table, it often feels like something else entirely: \u003cem\u003eWhy won\u0026rsquo;t my manager just tell me what they think?\u003c/em\u003e\u003c/p\u003e\n\u003cp\u003eThere\u0026rsquo;s a particular look people get when they\u0026rsquo;re being coached and they didn\u0026rsquo;t want to be coached. It\u0026rsquo;s subtle. A slight deflation, a beat of silence before they gamely try to answer your question. I\u0026rsquo;ve learned to watch for it. It means I\u0026rsquo;ve misread the situation.\u003c/p\u003e\n\u003cp\u003eSometimes people need information. Sometimes they need a decision. Sometimes they need your opinion, not as a coaching prompt, but as actual input from someone they respect who has more context than they do. Responding to those moments with questions isn\u0026rsquo;t coaching. It\u0026rsquo;s withholding.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFailure mode 2: Coaching as avoidance.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis one is harder to see in yourself, because it feels so much like doing the right thing.\u003c/p\u003e\n\u003cp\u003eAn engineer on your team is underperforming. Their code quality has dropped. They\u0026rsquo;re missing commitments. Other team members are starting to notice and compensate. You know you need to address it.\u003c/p\u003e\n\u003cp\u003eSo you set up a 1:1. And you open with: \u0026ldquo;How do you feel things are going?\u0026rdquo; You ask about their goals. You ask what obstacles they\u0026rsquo;re facing. You ask what support they need from you. You\u0026rsquo;re coaching.\u003c/p\u003e\n\u003cp\u003eExcept what you\u0026rsquo;re actually doing is hoping they\u0026rsquo;ll say the hard thing so you don\u0026rsquo;t have to.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve evolved my thinking on this a lot over the years. I used to think coaching through performance issues was more respectful than direct feedback. I thought I was treating people like adults by letting them self-diagnose. What I eventually realized is that I was being a coward. I was using coaching as a way to avoid the discomfort of telling someone, clearly and directly, that their work wasn\u0026rsquo;t meeting the bar.\u003c/p\u003e\n\u003cp\u003eThe engineer in that conversation often knows something is wrong, but they don\u0026rsquo;t know \u003cem\u003ehow wrong\u003c/em\u003e, because you haven\u0026rsquo;t told them. They walk out of a coaching conversation thinking it was a normal 1:1. They walk out of a direct conversation knowing exactly where they stand.\u003c/p\u003e\n\u003cp\u003eWhich one is actually more respectful?\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eFailure mode 3: Coaching as status performance.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eThis is the subtlest one. It\u0026rsquo;s when managers adopt coaching behaviors because it signals a particular kind of leadership identity (thoughtful, empowering, modern) rather than because it\u0026rsquo;s what the situation calls for.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve sat in skip-levels where an engineering manager spent 45 minutes asking me Socratic questions about a problem I\u0026rsquo;d already solved. They weren\u0026rsquo;t trying to help me think. They were performing the role of \u0026ldquo;leader who coaches.\u0026rdquo; The questions weren\u0026rsquo;t curious. They were procedural. They were going through the motions of a coaching framework they\u0026rsquo;d learned somewhere.\u003c/p\u003e\n\u003cp\u003eThe tell is this: if your questions have predetermined right answers, you\u0026rsquo;re not coaching. You\u0026rsquo;re giving a quiz.\u003c/p\u003e\n\u003ch2 id=\"your-manager-is-not-your-coach\"\u003eYour manager is not your coach\u003c/h2\u003e\n\u003cp\u003eHere\u0026rsquo;s the thing nobody in the coaching literature wants to talk about: \u003cstrong\u003ethe relationship between a manager and their report is not a coaching relationship.\u003c/strong\u003e It has a fundamental asymmetry that no amount of psychological safety can erase.\u003c/p\u003e\n\u003cp\u003eYour manager decides your compensation. They influence your promotion. They choose what projects you get. They can fire you. A real coach, an external coach, has none of that power. That\u0026rsquo;s what makes coaching work. You can be fully honest with a coach because there are no consequences to vulnerability. You can say \u0026ldquo;I have no idea what I\u0026rsquo;m doing\u0026rdquo; to a coach. Saying that to your manager carries risk, no matter how good your manager is.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;m not saying managers shouldn\u0026rsquo;t use coaching techniques. They absolutely should. The question-asking, the active listening, the \u0026ldquo;keep the thought bubble over their head\u0026rdquo; approach: these are valuable skills. But we should be honest about what we\u0026rsquo;re doing. When a manager coaches a report, it\u0026rsquo;s management that borrows from coaching. It\u0026rsquo;s not coaching.\u003c/p\u003e\n\u003cp\u003eThe distinction matters because when managers fully inhabit the \u0026ldquo;coach\u0026rdquo; identity, they sometimes abdicate the parts of management that coaching doesn\u0026rsquo;t cover. A coach doesn\u0026rsquo;t need to give you a performance rating. A coach doesn\u0026rsquo;t need to make a decision about headcount. A coach doesn\u0026rsquo;t need to tell you that your project is being cancelled. Those are management acts. They require directness, clarity, and the willingness to be the person with authority.\u003c/p\u003e\n\u003cp\u003eSome of the worst managers I\u0026rsquo;ve worked with were the most \u0026ldquo;coach-like.\u0026rdquo; They created an environment that felt warm and supportive and psychologically safe, but they never told you where you actually stood. They never made the hard calls. They facilitated endlessly. And their teams drifted.\u003c/p\u003e\n\u003ch2 id=\"when-managing-is-the-generous-act\"\u003eWhen managing is the generous act\u003c/h2\u003e\n\u003cp\u003eThere\u0026rsquo;s a framing I keep coming back to: \u003cstrong\u003esometimes the most generous thing you can do is be direct.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eI had a report once, a senior engineer, smart, capable, who was agonizing over whether to accept a tech lead role. They\u0026rsquo;d been going back and forth for weeks. In our 1:1s, I\u0026rsquo;d been coaching: asking about their fears, exploring what they wanted from their career, helping them think through the tradeoffs.\u003c/p\u003e\n\u003cp\u003eAfter the third conversation that covered the same ground, I stopped and said: \u0026ldquo;I think you should take it. You\u0026rsquo;re ready. The reason you\u0026rsquo;re hesitating isn\u0026rsquo;t that you don\u0026rsquo;t know the answer. It\u0026rsquo;s that the answer is scary. But you\u0026rsquo;re going to be good at this.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThey took the role. Months later, they told me that conversation was the most helpful one we\u0026rsquo;d ever had. Not the coaching. The moment I dropped the questions and just told them what I saw.\u003c/p\u003e\n\u003cp\u003eI think about this a lot. Coaching assumes that the person has the answer inside them and just needs help finding it. That\u0026rsquo;s often true. But sometimes people don\u0026rsquo;t have the answer. Sometimes they have the answer but need someone they trust to confirm it. Sometimes they need permission, or a push, or just the simple reassurance of someone with more experience saying \u0026ldquo;yes, this is the right call.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCoaching helps people find their own path. Managing sometimes means pointing at the path and saying \u0026ldquo;that one, go.\u0026rdquo;\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNeither is inherently better. The skill is reading which one the moment requires.\u003c/p\u003e\n\u003ch2 id=\"engineers-are-not-generic-employees\"\u003eEngineers are not generic employees\u003c/h2\u003e\n\u003cp\u003eMost of the coaching-vs-managing literature is written for a generic corporate context. It assumes a median employee in a median role at a median company. It doesn\u0026rsquo;t account for the specific culture and communication norms of engineering teams.\u003c/p\u003e\n\u003cp\u003eIn my experience, engineers tend to value a few things that the coaching orthodoxy sometimes conflicts with:\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eDirectness.\u003c/strong\u003e Most engineers I\u0026rsquo;ve managed prefer clear, direct communication over Socratic dialogue. They want to know what you think. They want your opinion to be on the table alongside theirs, not hidden behind a series of questions. When I ask \u0026ldquo;what do you think?\u0026rdquo; an engineer will often answer, then immediately follow up with \u0026ldquo;but what do \u003cem\u003eyou\u003c/em\u003e think?\u0026rdquo; They want the exchange, not the facilitation.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eSpeed.\u003c/strong\u003e Engineering work often has genuine time pressure. When there\u0026rsquo;s an incident, when a deadline is real, when a decision is blocking three other teams: that\u0026rsquo;s not the moment for coaching. That\u0026rsquo;s the moment for clarity. \u0026ldquo;Here\u0026rsquo;s what we\u0026rsquo;re doing. Here\u0026rsquo;s why. Let\u0026rsquo;s go.\u0026rdquo; You can debrief and coach after.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eTechnical respect.\u003c/strong\u003e Engineers notice when you ask questions you could answer yourself. If you know the answer to a technical question and you withhold it to \u0026ldquo;let them discover it,\u0026rdquo; many engineers will read that as condescension, not empowerment. They\u0026rsquo;d rather you share what you know and have a real discussion about the tradeoffs.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eHonesty about uncertainty.\u003c/strong\u003e I\u0026rsquo;ve found that engineers respond well to \u0026ldquo;I don\u0026rsquo;t know, let\u0026rsquo;s figure it out together,\u0026rdquo; which is neither coaching nor directing, but collaborating. The coaching model doesn\u0026rsquo;t have a great mode for this. It assumes the manager is the facilitator, not a participant. But some of the best engineering conversations happen when the manager drops the facilitator role and just thinks alongside their team.\u003c/p\u003e\n\u003cp\u003eNone of this means coaching doesn\u0026rsquo;t work with engineers. It does. But the vanilla coaching playbook (open-ended questions, reflective listening, GROW model) needs significant adaptation for an engineering context where people expect and respect directness.\u003c/p\u003e\n\u003ch2 id=\"a-framework-for-reading-the-room\"\u003eA framework for reading the room\u003c/h2\u003e\n\u003cp\u003eSo how do you know when to coach and when to manage? I don\u0026rsquo;t have a perfect model, but I\u0026rsquo;ve developed some heuristics over the years.\u003c/p\u003e\n\u003cp\u003e\u003cstrong\u003eCoach when:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe person has the skills and context to solve the problem, but hasn\u0026rsquo;t connected the dots yet\u003c/li\u003e\n\u003cli\u003eThe goal is long-term development, not immediate output\u003c/li\u003e\n\u003cli\u003eThere\u0026rsquo;s genuine room for multiple good answers, and you want them to develop judgment\u003c/li\u003e\n\u003cli\u003eThe person is explicitly asking for help thinking through something (not asking for an answer)\u003c/li\u003e\n\u003cli\u003eYou honestly don\u0026rsquo;t know the best answer and believe they\u0026rsquo;re closer to it than you are\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eDirect when:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eThe person is missing context or information that you have\u003c/li\u003e\n\u003cli\u003eThere\u0026rsquo;s time pressure and a decision needs to happen now\u003c/li\u003e\n\u003cli\u003eThe person has been going in circles and needs someone to break the loop\u003c/li\u003e\n\u003cli\u003eYou\u0026rsquo;re addressing a performance issue. Be clear, be specific, be kind, but be direct\u003c/li\u003e\n\u003cli\u003eThe person is new and needs orientation, not exploration\u003c/li\u003e\n\u003cli\u003eThere is a genuinely right answer and you know what it is\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003e\u003cstrong\u003eCollaborate when:\u003c/strong\u003e\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eNeither of you has the full picture\u003c/li\u003e\n\u003cli\u003eThe problem is genuinely novel and requires real-time thinking together\u003c/li\u003e\n\u003cli\u003eYou want to model how you reason through hard problems\u003c/li\u003e\n\u003cli\u003eThe person is senior enough that the manager-report dynamic matters less than the \u0026ldquo;two smart people working on a hard problem\u0026rdquo; dynamic\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThe mistake most managers make isn\u0026rsquo;t being in the wrong mode. It\u0026rsquo;s being in the same mode all the time. The manager who always coaches is as limited as the manager who always directs. Flexibility is the actual skill.\u003c/p\u003e\n\u003ch2 id=\"the-coaching-question-you-should-ask-yourself\"\u003eThe coaching question you should ask yourself\u003c/h2\u003e\n\u003cp\u003eIf I had to distill this into one piece of advice, it would be this: \u003cstrong\u003ebefore you coach, ask yourself why you\u0026rsquo;re coaching.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eIs it because this is genuinely the best way to help this person, right now, with this specific problem? Or is it because coaching is your default, the mode that feels safe, the approach that makes you feel like the kind of manager you want to be?\u003c/p\u003e\n\u003cp\u003eIf it\u0026rsquo;s the former, great. Coach away.\u003c/p\u003e\n\u003cp\u003eIf it\u0026rsquo;s the latter, if you\u0026rsquo;re reaching for questions because making a statement feels risky, because you\u0026rsquo;re not sure of your own opinion and coaching lets you hide that, because directing feels \u0026ldquo;old school\u0026rdquo; and you\u0026rsquo;d rather be the cool, empowering manager: then you owe your report more than that.\u003c/p\u003e\n\u003cp\u003eI\u0026rsquo;ve been that manager. I\u0026rsquo;ve sat in 1:1s where I coached someone through a problem I could have just helped them solve in five minutes, because I thought coaching was always the right answer. I\u0026rsquo;ve watched people flounder while I asked open-ended questions, telling myself I was developing their skills when really I was avoiding the harder work of having a real opinion and sharing it.\u003c/p\u003e\n\u003cp\u003eThe best managers I\u0026rsquo;ve worked for, the ones I learned the most from, weren\u0026rsquo;t the ones who coached me. They were the ones who \u003cem\u003esaw me clearly\u003c/em\u003e and responded to what I actually needed. Sometimes that was a question. Sometimes it was an answer. Sometimes it was \u0026ldquo;I disagree, and here\u0026rsquo;s why.\u0026rdquo; Sometimes it was \u0026ldquo;I trust you, go do it.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eThey weren\u0026rsquo;t performing a management style. They were paying attention.\u003c/p\u003e\n\u003ch2 id=\"managing-is-not-a-dirty-word\"\u003eManaging is not a dirty word\u003c/h2\u003e\n\u003cp\u003eI think we\u0026rsquo;ve accidentally created a culture, especially in tech, where \u0026ldquo;managing\u0026rdquo; has become a slightly pejorative term. It implies control, bureaucracy, micromanagement. \u0026ldquo;Coaching\u0026rdquo; and \u0026ldquo;leading\u0026rdquo; are the aspirational words. Nobody puts \u0026ldquo;I\u0026rsquo;m a great manager\u0026rdquo; on their LinkedIn bio. They say \u0026ldquo;servant leader\u0026rdquo; or \u0026ldquo;people-first leader\u0026rdquo; or \u0026ldquo;I grow teams.\u0026rdquo;\u003c/p\u003e\n\u003cp\u003eBut managing is the job. It includes coaching, sure. It also includes deciding. Prioritizing. Saying no. Giving feedback that makes people uncomfortable. Making calls that not everyone agrees with. Owning outcomes, not just facilitating processes.\u003c/p\u003e\n\u003cp\u003eThe best engineering managers I\u0026rsquo;ve known weren\u0026rsquo;t the best coaches or the best directors. They were the most \u003cem\u003esituationally aware\u003c/em\u003e. They could read a room, read a person, read a moment, and respond with whatever that situation actually needed. Sometimes it was a question. Sometimes it was an answer. Often it was something in between: sharing context, thinking aloud, being honest about uncertainty.\u003c/p\u003e\n\u003cp\u003eIf you take one thing from this post, let it be this: your job isn\u0026rsquo;t to coach. Your job isn\u0026rsquo;t to manage. Your job is to help your team do their best work. Coaching is one tool for that. Managing is another. The fixation on one over the other is what gets people into trouble.\u003c/p\u003e\n\u003cp\u003ePay attention to the person in front of you. Respond to what they need, not to what your management philosophy prescribes. That\u0026rsquo;s the whole thing.\u003c/p\u003e\n","date_modified":"2026-03-08T00:00:00Z","date_published":"2026-03-08T00:00:00Z","id":"https://leadership.garden/youre-coaching-too-much/","summary":"Most engineering managers coach too much, not too little, and they often do it for themselves, not their reports. Here's when managing is the more generous act.","tags":["coaching","management","feedback"],"title":"You're Coaching Too Much","url":"https://leadership.garden/youre-coaching-too-much/"}],"language":"en","title":"Leadership Garden","version":"https://jsonfeed.org/version/1.1"}