Rich Hickey had published a short piece called “‘AI’ is Not a Tool”, 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’d just done the thing the essay is about. I didn’t read the threads. Something else read them, and I read its summary.

(I went back and read the parts that mattered. That ate the evening anyway.)

If you run an engineering org, you’ve heard “it’s just a tool” 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.

What Hickey actually argues

Most of the angry replies argue with an essay he didn’t write. On HN, people demanded rulings on gdb, cameras, catapults and ffmpeg, as if he’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.

His test for a tool is narrow on purpose: “A tool is something you wield.” 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.

He 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 “tool” hides it.

Where the objections are fair

I went through both threads looking for pushback that actually lands, and some of it does.

Power tools misbehave too. Several people pointed out that a table saw isn’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’t shape.

“It depends on how you use it” 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’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.

I believe both of them, and I’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.

Managers already made this trade

Hickey’s essay describes the move I made when I went into management.

When 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.

I don’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 “out of touch”. We built rituals against it too, like skip-levels and the occasional week spent back on the on-call rotation.

Two HN commenters got to the same place from opposite directions. One said an agent is closer to an employee than to rm, 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’ve stopped working. I’d call both of those delegation, the one skill managers get trained on, badly, in their first year. Delegation buys you output and costs you contact with the work. And it only holds up while the person delegating can still tell good output from plausible output.

That last condition is the one that worries me.

The judgment has to come from somewhere

My judgment came from years of wielding. 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.

Hickey’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’s first three years. It’s also the stock every delegator draws down later.

When a senior engineer hands a task to an agent, she’s spending judgment she already has. When a junior does it, there’s nothing to spend yet, and the task that would have built some just got done by something else. “Just a tool” flattens those two cases into one.

One 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. Every engineering org I know does. Somebody has to catch the bug the agent keeps putting back. Somebody has to hold a whole system in their head when the agent’s context runs out, and notice when a confident answer is wrong.

Why the word matters in a rollout

One HN commenter dismissed the whole essay as a stipulated definition followed by a “so what?” Inside a company, the “so what” is easy to find.

Another 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.

The 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.

Call it automation, or delegation, and different questions show up:

• What does this team stop practicing if the rollout works?
• Who still needs to do the task by hand, and how do they keep that ability?
• When the output is wrong in a plausible way, who notices, and what experience lets them notice?
• If the vendor swaps the model next quarter, what do we lose?

You’d ask these before automating any other workflow. Calling it a tool is how a team gets to skip them.

What I’d ask of other leaders

I’m not going to ban anything, and I doubt the no-AI Fridays fix much.

Start by naming the mode, task by task. The same product can sit anywhere on Hickey’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’re doing, and to have picked it.

For 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’d still rather they build the judgment now than find out in five years that they never did.

Count 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.

And drop “just a tool” from your own vocabulary. When someone on my team reaches for it, I’d rather hear what they’re automating and what it costs.

Hickey 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’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.

It 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.

Then 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.)

If you run managers who run teams, there’s a decent chance you have a slide like that open somewhere right now. I don’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.

Paulo André’s essay Quick to Build, Slow to Know is the best thing I’ve read on this, and I’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 “the system” does, which is true and lets everyone inside it off a little easy.

I 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’ll try to answer from my chair.

Speed reports itself

Every 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 “AI impact” tab within a quarter. I didn’t ask for any of it, and all of it updated daily.

Nothing in our stack updates daily on whether the work mattered.

Think 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’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.

So the evidence is lopsided before anyone decides anything. I don’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.

The overshoot climbs the org chart

The 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’s throughput jump and mentions it in her monthly update. She’s careful about it. She notes that review load on her two seniors has gone up and that she isn’t sure the extra PRs are the ones that matter. Her director pulls together five of those updates. The caveats don’t survive the merge. What survives is “throughput roughly doubled across the group.” The head of engineering turns that into a planning assumption: if we ship twice as much, next half’s roadmap can absorb more. The roadmap goes to the business with dates on it. Sales starts mentioning features to customers.

Nobody in that chain did anything wrong. Go back and read the manager’s original update, and her line about the two seniors is still the most important sentence in it. It just didn’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.

(I’ve been the director in that story, and I’ve been the head of engineering. The caveats are always the first thing to go. I’ve cut them myself, because the slide had room for one line.)

Some companies go one step further and wire the fast signal straight into incentives. Managers at JPMorgan reportedly track how often developers use AI coding tools 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’s review, you’ve told the whole org which signal keeps score, and people will play to it. I would too.

Scarcity was doing your prioritization

I’ve sat in a lot of planning meetings where the most useful sentence anyone said was “that’s three engineers for six weeks.”

It was a bad mechanism, and I don’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.

But 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.

That price has mostly disappeared. A PM asks whether we can try something, and the honest answer is “sure, it’s an afternoon.” The answer is accurate. It also answers the wrong question, because the afternoon was never the expensive part.

Most of what a yes costs shows up after the code exists, usually as somebody’s on-call shift or somebody’s help article, a year after the person who said yes has moved on to other things. AI made none of that cheaper. There’s just more of it.

I 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.

These 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’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.

Just Ship Faster fails

Stay SaaSy would tell me I’m overthinking this. In The Best Prioritization Is No Prioritization they argue that scoring frameworks are theater and nobody can prove they prioritized well, so you’re better off spending that time getting faster and letting shipping teach you. It’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.

I agree with more of that than I’d like to. Most scoring frameworks I’ve watched in practice were a way to dress up a decision someone had already made. I’ve also watched a team spend a month ranking a backlog that one week of building would have settled.

But 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’ll find out before it costs much.

Now 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’t know whether it worked for six months, maybe longer. Meanwhile you’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.

The rule I’ve landed on: speed can stand in for judgment only when time-to-know is shorter than the time between your decisions. 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.

Time-to-know is a number

I used to treat “will we ever find out if this worked” as a philosophical question. I now treat it as something you can estimate, roughly, before you start.

For any bet worth a conversation, I want these written down before work starts:

• What would tell us this worked? I want a behavior, something like “the forty accounts that asked for this export use it at least twice a month.” “Engagement” doesn’t count.
• When is the earliest we could see that?
• Who is going to look, and is it already on their calendar?

The 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’d bet on two quarters, and I’ve rarely lost that bet.

When we started writing this down, a surprising number of proposals couldn’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’t be able to judge until spring, so we stopped doing it.

You can also shorten it, and right now I’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’t the first time anyone looks. The underrated version is shipping to five customers you can phone before shipping to five hundred you can’t. Much of what we used to call velocity work, I’d now call time-to-know work, and given the choice I’d fund it over another round of seat licenses.

Write down what is enough before you start

One of the questions Paulo ends on is how long the “enough” signal takes to show up. My worry is that most teams never decided what “enough” would look like in the first place. They decide afterward, once they’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. “If fewer than fifteen of the accounts that requested this use it by the end of February, we remove it.” Put the review on the calendar on the day you approve the work.

The 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’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’t. A removal that was planned from the start is the slow signal doing its job.

Will Larson makes the case that quick, good, and durable decisions are what lets a team cash in on AI’s pace. I’d push on “durable”, which most people hear as “permanent”. A decision with a review date on it lasts longer in practice, because reversing it later is a calendar item, not a political fight.

What I report upward now

The 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’d know whether it worked and what we’d be looking at. Three rows said January. One said “we don’t yet know how to measure this,” which was the most honest line in the deck.

My manager asked about that row more than any other. Good. That’s the conversation I wanted to be having.

I’ve kept a few habits from that quarter, and I’d push them on anyone in a similar seat:

• Pair 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.
• When your managers send caveats up, keep at least one when you summarize. If the template only has room for one line, change the template.
• Argue against putting AI usage into performance reviews. If the people above you insist, at least make sure they understand they’re rewarding the fast signal on purpose.

A column full of “pending” is not a comfortable thing to present when every peer in the room is reporting green. The alternative is committing next half’s roadmap on the strength of a number that measures typing.

The leader this needs

Paulo’s closing question was what kind of leader this system needs. My answer is less grand than I’d like: someone who can wait for the slow signal without pretending it already arrived.

In practice that’s fairly unglamorous. You’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’ doubts survive your summaries. And when your boss asks whether the big bet worked, you can say “we’ll know in January” and then stop talking, without filling the silence with a projection you don’t believe. (That last one is the hardest for me. I’m working on it.)

This isn’t a case for slower teams, and I’d be annoyed if anyone used it as one. I want the speed. I just don’t want an org that takes how fast it builds as proof of how fast it learns, and then makes promises on the difference.

We got dramatically faster at building this year, and I can’t point to a single week we saved in finding out whether any of it mattered. That gap is most of the job now.

What 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.

I think most of them are tracking the wrong number. They count how current they are: which launch threads they’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’ve seen handle change well are mostly good at the second one.

React less

A Reddit post in r/AI_Agents 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’t keep up, and judging by the replies, nobody else could either.

Leaders 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’ve done both. Each reaction looked responsible at the time.

The 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’t change what anyone should do on Monday, and the ones that did were still there two weeks later, easier to read.

The 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’s “I don’t know yet”, and then I wait until I do. Only an answer that names a specific decision gets action.

“Keep up or get left behind” 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’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’t miss.

Master principles, not tools

I’ve written production code in Python, Ruby, OCaml, Clojure, C#, Go, Rust, TypeScript, PHP, Java, and Haskell. Today I’d need a reference open for half of them. What carried over between them was everything that wasn’t syntax: how to model state, where to draw a boundary, how a failure travels through a system, why the boring option usually wins.

Tools have always expired. What’s new is how fast. Sean Goedecke pointed out in August that “make working changes to large codebases” was on his list of things models couldn’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’s tools, your edge has a shelf life of about a quarter.

Goedecke would push back on part of this. His short-term advice is to squeeze every advantage out of the tools, and he’s right that refusing them is a losing position. I’d go one step further. Fluency in this month’s agent doesn’t compound. The two durable skills he names, knowing your own system deeply and explaining it clearly, don’t live inside any tool, and they’re exactly what makes the next tool cheap to pick up.

Principles 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’s config file, every release is a new world, and you’re back to reading everything.

The same holds one level up. Every reorg I’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.

Ship more than you read

Reading 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’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.

Most 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’d throw the agent’s output away, and how often my own taste was the only thing between the codebase and a pile of defensive code nobody needed.

My 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.

For a leader, shipping doesn’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’t, is navigating it. The manager who forwards the announcement with “more details soon” is still reading about it.

Pick fewer changes

Change will keep arriving faster than anyone can read about it. That’s the one forecast in this post I’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.

Everything else is staying informed. Being informed was never the job.

This 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.

First, the part I’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.

But the tool lowered the barrier to creating software. It didn’t hand anyone the knowledge, experience, and judgment needed to draw sound conclusions about engineering it. A lot of the current methodology talk comes from people who haven’t noticed that those are two separate things.

Why the recipes sound right

Taken on their own terms, the recipes make sense, and the people pushing them aren’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.

Then again, nobody asks the architect to add three floors every quarter to a building people already live in, while keeping the lifts running.

They also answer a real frustration. Anyone who has watched an agent wander off, rename half a module, and call an API that doesn’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.

Spec 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.

Follow that logic without a brake and you get what François Zaninotto at Marmelab described when a developer used Spec Kit to show the current date in a time-tracking app. The output was eight files and roughly 1,300 lines of text. That’s an extreme case, and I wouldn’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.

The trouble is that most of the uncertainty in software doesn’t live in the part you can write down in advance.

Week one and month nine

Most 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.

Manny Lehman 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’s roadmap, usually as the reason everything else got slower.

I don’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’t met the conditions the older practices were built to survive.

AI 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.

Producing something that works is not the same as showing that we know how to keep it working.

The recipe is older than its authors

These ideas are older than most of the people now presenting them as a discovery.

The paper usually cited as the origin of waterfall is Winston Royce’s 1970 “Managing the Development of Large Software Systems.” Royce drew the sequential diagram, requirements to design to code to test, and then called that approach “risky” and said it “invites failure.” 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. The industry kept the diagram and dropped the argument.

Five 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 “A Rational Design Process: How and Why to Fake It.” 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.

That 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.

Tests are how you find out

The 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.

In practice a test is one of the cheapest ways to find out that your understanding was wrong. Kent Beck’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.

Watch 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.

Sometimes the agent doesn’t even get that far. In the same Marmelab write-up, the agent ticked off its “verify implementation” task without writing a single unit test. It produced manual testing instructions instead, and the checklist still showed done.

Confidence is cheap to acquire in this setup. In METR’s 2025 study, 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’t read that as proof that AI slows people down, since the study was small and the tools have moved on since early 2025.

I read it as a measurement of how far someone’s sense of progress can drift when nothing pushes back.

Challenging a practice versus dismissing it

None 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’d worry about any engineering leader who defends every current practice on the grounds that it’s current.

So I don’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. Chesterton’s Fence much?

The strongest version of the other side goes like this:

“The old practices existed because code was expensive to write. Code is now cheap. So the practices can go.”

That argument is half right. Writing code did get cheaper. Being wrong didn’t. 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.

When a recipe lands in your inbox, three questions separate the two cases quickly:

1. What problem was the practice you’re replacing designed to solve?
2. Where does that problem go in the new approach? Does it disappear, or does something else absorb it?
3. What’s the evidence from after the system had to change? The second and the fifth change, not the first build.

Someone who answers the first question well is usually worth listening to, even when I disagree with where they end up. Someone who can’t answer it is guessing, however good the demo looks.

If you’re the one deciding whether your organization adopts a recipe, don’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.

What we could be doing with it

This 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. Agents took most of that cost away, and so far we’re spending the savings on volume.

Take Brooks’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’s mostly a guess with good formatting.

Most teams point their agents at the code. I’d point more of them at the spec because that’s where the expensive assumptions live. Ask the agent for the inputs the spec doesn’t handle, the requirements that contradict each other, and the questions a skeptical colleague would raise in review. You don’t have to accept any of it. You get the argument earlier, when it costs a paragraph instead of a data migration.

Verification 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. Agents can write them now, cheaply. 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’re back to one author agreeing with itself.

Understanding is where I see the most untapped value. Peter Naur argued in 1985 that the real product of programming is the programmer’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.

Sean Goedecke describes his own workflow 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’s what expertise looks like with these tools: plenty of output, most of it thrown away, and the throwing away is the skill.

Then there’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.

For leaders, most of this comes down to what you reward. Count the code your agents produced, and you’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’ll end up with a different kind of team.

That 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’s true before anything depends on it.

Confidently wrong, at scale

I’ve called AI an amplifier 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.

More 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.

We had a real chance to amplify our ability to learn, reason and engineer. So far we’re mostly amplifying our ability to be confidently wrong. I don’t think that’s settled. It won’t change on its own, though, and it won’t change because somebody writes a better recipe.

Judge the next one you’re forwarded by what happens on its tenth change. The first demo tells you almost nothing.

The first substantive comment came from someone in a different domain entirely. It opened with, “I ran this past Claude, and it flagged a few things.”

Nine things. Numbered, confidently worded, formatted better than the doc itself. Two were fair. One was a real catch, and I’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.

He answered all nine. It took him most of a day.

That day is what this post is about.

What you can do, and what you can judge

Start with two measures, not one.

You’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’t design our billing schema, produce a Figma file anyone would want to look at, or close the books for a quarter.

Now 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’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’s confidence about a migration isn’t supported by anything that has ever happened here.

The 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.

The band between the two, the work you can assess but not produce, is where management lives. A PM who can’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.

Every org chart I’ve ever drawn assumes that band exists and holds still.

Then 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.

You know that part. It’s been written a dozen times, and I don’t have a better version of it.

What I have is what comes after.

You can’t locate the edge of your own judgement

The comforting response is that sensible people know their limits and ask for help. I believed some version of that for years. The research isn’t kind to it.

Kahneman and Klein spent a long time disagreeing about expert intuition and then wrote a joint paper in 2009 about where they’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.

That second half is the one that should bother you if you run performance reviews, because it means I cannot see my engineers’ boundaries either. I have been rating people on judgement for a decade using a method that amounts to noticing when they sound sure.

Most writing on this reaches for Dunning-Kruger about here. I’d rather not, for two reasons.

The literature is genuinely contested and has been for twenty years. Gignac and Zajenkowski 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.

It’s also the wrong shape. Dunning-Kruger describes people at the bottom of a single domain. What I’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.

The part of the Kahneman and Klein paper I keep returning to is a smaller observation. Subjective confidence, they write, is driven by the internal consistency of the evidence a judgement rests on, rather than by the quality of that evidence. Evidence that’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.

Read that again as a description of what comes out of a language model.

Coherence is the thing it’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.

Your judgement isn’t fixed. It shrinks.

Here’s the assumption I hadn’t examined: that my judgement is a property of me, earned once, sitting there permanently.

Kahneman 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.

Your ability to judge a code review was built by writing code and then finding out what happened (FAFO, in other words). The ‘finding out’ is the part that did the work. Take it away, and the band narrows.

We now have a measurement of how fast, and it’s worse than I expected.

Anthropic ran a study 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: human catch rates ran near 17 percent early in a session and fell to about 5 percent after fifty prompts, while the classifier held flat.

Fifty prompts is one afternoon.

Treat it with the suspicion it deserves. This is vendor data supporting a vendor’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. I would rather have this study run by somebody with no product to ship. Until then, the direction agrees with everything else available. Sonar surveyed over 1,100 developers and found 96 percent don’t fully trust that AI-generated code is functionally correct, while only 48 percent always check it before committing. Thirty-eight percent said reviewing AI output takes more effort than reviewing a colleague’s.

The reviewing costs more, we do it less, and we get worse at it the more of it we do.

And then it happens to other people’s work

Everything above is about judging your own output. The version that cost my engineer a day is second-order, and I think it’s the more serious one.

The standard reassurance here is that people distrust machines, so a bot-sourced objection should land softer than a human one. Logg, Minson and Moore 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.

The 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.

The 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.

Sit with what that combination does to a room. The least qualified person’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’s close to the worst one available.

Then there’s volume, and the workslop research covers that well enough that I won’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’t.

The cost of generating a plausible objection has gone to roughly zero. The cost of answering one hasn’t moved at all. Anyone in the company can now open an unbounded line of credit against a specialist’s week, and the specialist has no standing to refuse.

That asymmetry is what cost my engineer his day. The quality of the AI output barely mattered.

What I’m actually doing about it

Eighteen months in, I’m running experiments rather than reporting results. Some have earned their place.

Predict, then look

The 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.

Concretely, on my team: before you open the agent’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’s benchmark, write the number you expect. Keep them in a file with dates on them.

Look 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’s the only version of it you’ll ever get, because subjective confidence is measuring the wrong thing.

The failures teach more than the hits. If you sit down to write the prediction and find you’ve got nothing to write, you’ve located the edge of your competence precisely in about fifteen seconds, without needing anyone’s permission or a framework or a workshop. That blank line is the entire diagnostic.

There’s a companion question I now ask before approving anything: what would have made me reject this? When I couldn’t answer, what I did was processing rather than review. I’ve been on the wrong side of that distinction plenty of times, usually on a Friday.

Calibrate the machine before trusting it as a judge

Using AI to review AI is the obvious move, and it isn’t automatically wrong. Look again at why Anthropic’s classifier beat their humans. It’s a different model from the one proposing the action; it evaluates a tool call it didn’t generate, and it was measured against 1,053 planted known-bad commands. Independence and ground truth.

Most in-house AI reviews have neither. It’s the same model family reading its own output, and nobody has ever checked whether it catches anything.

The failure mode there is not that the reviewer misses things. Researchers at Emory and Tokyo watched code models 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.

The 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’ve never run that test, what you have isn’t a reviewer; it’s a reassurance generator. The same test works on your test suite, incidentally, and there it’s called mutation testing.

Write down who decides

This 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.

For most of my career, the right to overrule someone was rationed by a friction nobody ever wrote down. You didn’t challenge the database expert on index strategy because assembling a credible counter-argument would have cost you a week you didn’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.

It’s gone. Ninety seconds now buys a credible-looking counter-argument on any topic in the company.

So 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.

And one rule attached to it, which is the part that actually helps: an AI-generated critique is an input to the owner, not a claim on the owner’s time. The owner reads it and decides. No point-by-point rebuttal is owed to anyone, and silence on item seven is not a concession.

That reads like bureaucracy. In practice, it’s permission to not respond, which is currently the scarcest resource your specialists have.

The strongest objection

A tech lead I work with pushed back on all of this, and her version was sharp enough that I’ve changed my mind about part of it.

Her argument: this is gatekeeping with better manners. Experts have always deflected challenges with “you don’t have the context,” 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’s the head of engineering, explaining why their objections should be easier to dismiss.

She’s right about the old system. I’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’t right. He was faster and had more standing, and she didn’t have the vocabulary to defend a good instinct. I said nothing at the time. I’ve thought about it a lot since.

The repair for that was never to make objections free, though. Free objections don’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’t the person with the sharpest read on the system. What she was actually asking for was that the decision-maker’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.

Where this leaves me

I don’t have a number for how often I’m right about work I couldn’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.

Start measuring it on yourself. Write the prediction down before you look. You’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.

Then 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.

Charlie Munger put it better in 1995: “Show me the incentive, and I will show you the outcome.” 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.

It matters most when you are trying to fix something in the culture.

The town hall does not work

The 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.)

None of it moved anything, and not because anyone disagreed with me.

They agreed. They also knew who got promoted last cycle.

An 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.

Then 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.

What you actually control

Most writing on this ends at “align the incentives,” which in practice means redesign the ladder and the compensation plan. If you run a domain rather than a company, you usually own neither.

What you do own is attention. Attention is an incentive, and because it costs nothing on any budget line, leaders treat it as decoration.

So 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.

Once 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.

The test for whether the path is real

The 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.

That objection is correct, and it gives you the test.

Ask 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.

Do not turn it into a metric

The next instinct is to measure the thing. Put tech health on the scorecard, count refactors, attach a number to reliability, and review it monthly.

Then 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.

Keep recognition a judgment call. 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.

Read your own signals

If you do not like what you are seeing in your team, the answer is rarely in what you have been saying.

Look 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.

Mostly I didn’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.

Then 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.

That is where the word “driven” is doing work nobody has audited.

If you run an engineering org, someone is going to ask you this quarter whether you’re “doing SDD.” 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.

The defenders describe something the diagrams do not show

Start with the strongest version, because the weak version is easy, and I don’t want to spend a post beating up a LinkedIn article.

Marc Brooker works on Kiro at AWS and has written the best defence of SDD I’ve read. His line is that specs aren’t about pulling designs up-front; they’re about “pulling designs up”. 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’s right, and the sentence I’d underline in his piece is that you shouldn’t develop the whole specification upfront. Hold onto that one. It’s a concession the tools he’s defending have not made.

Birgitta Böckeler at Thoughtworks did the most careful hands-on evaluation I know of, 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’d take the first rung happily, the second with a named maintainer, and the third not at all, for reasons I’ll get to. Note that almost everything marketed as SDD is sitting on rung one while quoting the brochure for rung three.

Yuval Yeret adds the sharpest diagnosis. The spec is a target for an adaptive loop, and the failure mode isn’t sequencing; it’s batch size.

Every one of those defenses describes a loop.

Now go look at any SDD marketing diagram. Specify, plan, tasks, implement. One direction, and no arrow comes back.

The 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’s an accurate drawing of the claim.

Böckeler has the right word for what’s happening to the term: it is already semantically diffused, Fowler’s name for a phrase that spreads faster than its meaning. Thoughtworks’ own Technology Radar 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’t draw that line, you should be slow to reorganize around it.

What “driven” is smuggling

Every “X-driven development” name makes the same kind of assertion. When two artifacts disagree, X wins.

Test-driven development gets away with it because the test lives inside the loop. It’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.

A specification does. It has been reviewed by product and engineering; it sits in the repo, and somebody’s name is on it.

So here’s the question I’d put to any team proposing this before the tooling conversation starts. When the running system and the spec disagree, which one is wrong?

Answer “the code, we regenerate it” and you have a governing document, along with every failure mode of the last fifty years of upstream-artifact processes. Answer “usually the spec, we go update it” and the spec isn’t driving anything. It’s documentation. Useful documentation is a fine thing to want, and most orgs are bad at it. But then there’s no methodology here, just a practice with an overclaiming name.

The best-practice list in that article gives the game away, and I don’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.

If the spec has to chase reality, reality is the source of truth.

The spec doesn’t govern the agent either

There’s a second problem with “source of truth,” and this one isn’t philosophical.

A compiler is bound by its input. An LLM is not.

Bö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.

So the spec’s authority over the implementation is a probability, not a guarantee, and it decays as the document grows.

Thoughtworks put spec-driven development in the Assess ring of the Technology Radar in November 2025, which is roughly “interesting, go look at it.” 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’t always clear who those are for. Then they land on the actual worry: we may be relearning the bitter lesson, that “handcrafting detailed rules for AI ultimately doesn’t scale.”

That’s the sentence I’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.

That 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’t, so you review the spec and then review the code anyway to find out whether the spec was honored.

Böckeler reaches for the German word: Verschlimmbesserung. Making something worse in the attempt to make it better.

Verification is not validation, and only one of them has an owner

The strongest practical claim for SDD is that acceptance criteria hand you tests almost for free. True, and worth having.

It’s also verification. Does this software obey the rules we wrote down?

Validation 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.

The objection I get here is that the criteria came from a stakeholder, so checking them is validation by proxy. It isn’t. A stakeholder signing off on a rule in February tells you what they believed in February about a system they had not used.

That’s a hypothesis with a signature on it, and treating a signature as evidence is how a good process turns into a bad one.

Most of what’s written about SDD uses those two words interchangeably, including the article I started with, which puts “validation” in its lifecycle diagram and then describes nothing but verification for three thousand words. Call that pedantry if you like. It’s the difference between building the thing right and building the right thing, and we are blurring the one distinction the discipline most needs to keep sharp.

The reason it matters to you and not just to essayists is that only one of those questions has an owner.

Verification 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’s spread across a PM’s judgment, a designer’s instinct, and whether anyone remembered to look at the funnel three weeks after launch.

The most expensive quarter I’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.

Adopt a vocabulary that calls verification “validation” and you get an organization that believes the second question is handled because the first one is green.

Take the example that article uses, chosen to demonstrate the method’s strength. “Users can upload files” 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.

It leaves enormous room. 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?

Someone defending the example will say a better analyst catches those with more effort. I don’t think so. They’re questions generated by contact with reality, and contemplation doesn’t produce them in advance at any level of diligence.

Precision about the wrong answers is not an improvement over vagueness about them. You don’t escape that by specifying harder. You escape it by making the discovery cheap.

The economics moved, and the methodology went the wrong way

Every development process is an answer to one question. What does it cost to be wrong?

Big 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. Correct arithmetic, wrong century.

AI broke that arithmetic, and not slightly.

An 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’s to build it, put it in front of somebody, and watch what they do with it. Prototypes are disposable now. Being wrong is truly cheap now, as long as you find out quickly.

Look at what SDD does with that. It takes the first change in our field’s history that makes feedback loops dramatically cheaper and spends the windfall on making the phase before any feedback exists longer and more ceremonial.

The 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’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.

Brooker and Yeret would both broadly agree with that paragraph, which is exactly my point.

The defensible version of this is iterative development with good context hygiene, and that is not what the word “driven” is claiming.

What it will cost your org

Start with review capacity, which is already your constraint whether or not you’ve named it as one. Faros AI spent two years watching telemetry from 22,000 developers across more than 4,000 teams, and their 2026 report is the least comfortable thing I’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.

Böckeler’s account of spec-kit is that it produced a lot of markdown, repetitive with each other and with code that already existed. She’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.

If human attention on the way out is your bottleneck, adding a review stage on the way in doesn’t help. It piles more work in front of the constraint. I’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.

Brownfield makes it worse, and brownfield is where you live. 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.

Then there’s the fact that spec review has no failing state. A code review can say, “This doesn’t work.” 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’s no principled ground to reject one; rejecting it means the feature slips, and everyone in the room can do that math.

The last cost is ownership. If PMs write the acceptance criteria that agents build against, you’ve relocated a lot of technical judgment to people who don’t carry the pager. Yeret thinks expecting product managers to write the specs makes very little sense, and I agree with him. That doesn’t mean PMs stay out of it.

It means the person accountable for the system being correct has to be the person whose judgment ends up in the artifact the agent obeys.

What I’d actually do

I’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.

• Cap the spec by the thing it describes: one change, not one feature. If the spec takes longer to write and review than the change takes to build and try, you’ve picked the wrong artifact for the work in front of you. That’s a rule you can apply on a Tuesday without running a workshop about it.
• Measure time to first contradiction. 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’re fine. It’s the only metric in this post I’d put on a dashboard.
• Give validation a name. One person per initiative, accountable for the question “Was this worth building,” 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’t name them for your biggest current project, that’s the finding, and you can stop reading here.
• Keep the spec after the change only if someone maintains it. Böckeler’s spec-anchored level is genuinely valuable, and it’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.
• And stop saying “driven” internally. Say, “We write a spec first.” Four words longer, accurate, and it doesn’t quietly assert that a document outranks a production system.

The question nobody asked

That 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?

There’s no general answer, which is the problem with selling this as a methodology. Payroll rules, tax logic, a protocol implementation: specify heavily, because the what is genuinely knowable in advance and feedback won’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’t delegable to a process, which is precisely why processes sell so well.

Royce drew the single-pass diagram in 1970 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’t stick for him either, so I’m not expecting much.

Write the spec. Then keep it small enough that reality can overrule it.

The 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.

The second build was the same feature inside the actual product. It took most of a quarter.

Nothing 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.

If 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 “enterprise is complicated,” because that answer sounds like an excuse and half the time it is one.

The claim is smaller than the headline

Every 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.

But look at what got measured. A specified problem went in, and code came out. The specification was the input.

Somebody 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.

What actually happened to the CSV button

The 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.

An 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.

Legal 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.

The 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.

Then 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.

An 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.

We named the discipline after its most expensive part

For 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.

That 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.

I 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.

Four layers, and one of them got cheap

Any change worth shipping has to survive four questions, and they do not all live in the same place.

At 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?

Models are becoming excellent at the bottom question. They are useful at the second one, if you tell them enough, but they usually can’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.

The fourth question has not moved at all.

That 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.

Context is everything that the repository does not contain

What separated the weekend build from the product build was not talent, and it was not tooling.

An 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.

Almost 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.

A 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.

So 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.

That 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.

What I would actually do with this

None of what follows is about tool selection.

Stop 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.

Move 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.

Write 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.

“So write the context down”

The 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.

Try it and watch what surfaces.

You 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 “basically” in it.

Writing 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.

Every layer gets its turn

There 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.

I 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.

Which 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.

Code is the medium

Nobody 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.

We 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.

So 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.

Go and look at where your last quarter actually went. If the answer is not “writing the code,” and I do not think it will be, then you already know which part of the job to get better at.

Covering 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.

What 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.

The published advice answers a different question

Almost everything written about splitting teams answers one question. Is this team too big?

Chase Seibert states the default position most cleanly, in a post whose title is the whole argument: don’t split the team until you have to. 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.

Will Larson 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.

Both of them are describing a split that happens backwards. Something hurts, and you relieve it.

Nothing 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.

Larson does have an answer for my situation, and it is the strongest objection to everything below. In How to evolve an engineering organization 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.

That 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 “this is your mandate for the next three years” sense. When the quarter gets tight, a workstream loses to the team’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’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.

The constraint is leads

My 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.

That 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).

Every 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.

So the earliest honest split date is set by lead readiness. Everything after that is scheduling.

Once 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.

What lead-ready actually means

I 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.

What I watch for now is narrower.

Can 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.

Do 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.

Conflict 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.

None 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.

Two quarters of that tells me more than two years of strong code review.

You 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.

The rules I do not negotiate

Before any scenarios, the constraints I bring into every one of these rooms:

• One team, one area. A team can carry two workstreams if each is staffed to survive on its own. Never three.
• Only 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.
• Every 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.
• Every new team gets at least one established engineer, ideally two. A team of new hires and good intentions ships nothing for six months.

Those four did most of the filtering before I drew a single box.

Find the fault line before you write scenarios

Two 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.

If 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.

Do this part before the workshop. Otherwise you spend two hours debating combinations that were never viable, and the debate feels rigorous while producing nothing.

Scenario 0: stay one team, sequence the streams

One team of six growing to eight, under the existing lead, working one stream at a time in priority order.

Maximum 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.

I put it on the table as a real option with a review date attached, and I would do that again. Most workshops treat “not yet” 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.

Scenario 1: three teams now

The org chart the vision implies. One team per stream, everything funded, everybody happy for about ten days.

This 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.

I 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.

Scenario 2: data plus platform, defer the third stream

Two teams of roughly four. The specialised stream and the foundation stream both start now. The most operations-facing stream waits.

This 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.

Both 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.

Scenario 3: platform plus the third stream, defer data

Same two-team shape, different pairing. Both teams sit on the same substrate and share infrastructure, design and vocabulary.

Lowest context-switching cost of anything on the list, and it removes a technical dependency on another team’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.)

I 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’s delivery date.

The menu is not there so the room can vote

Scenarios 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.

If 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.

Two questions could have flipped my recommendation, and I said so in the room rather than presenting the analysis as finished.

Who 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.

Which 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.

Watch where the bottleneck lands

One thing I nearly missed, and Seibert had already written it down years ago. The product side had a single PM across the whole area.

Split engineering into two teams under one PM and the coordination cost relocates to that person’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.

Seibert 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.

So 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.

Before you draw the boxes

Count 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.

And 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.

Then somebody outside the domain asked what had changed for the business, and I did not have an answer worth saying out loud.

That team worked hard. They worked hard on something any competent team at any competent company could have worked hard on.

The test

Justin Jackson published a post in June called Do the hardest thing. 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.

He 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.

The test I use now: if I disappeared for six months, would the difficulty go away?

Hard-job difficulty is made of my effort and my team’s. Pull us out and it evaporates, because a replacement drops in and grinds the same grind. Hard-problem 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.

We measure the job

Sprint 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?

Nothing in that stack asks whether the work was worth choosing.

(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.)

Will Larson’s Work on what matters is the standard reference here, and it is good, but it aims at your calendar. Hunter Walk’s snacking, 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.

Your hardest problem is not technical

Ask 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.

Those are hard jobs. 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.

The problems that actually resist look more like this:

• A team that made sense two reorgs ago and now exists because dissolving it would embarrass the person who built it.
• The senior engineer everyone routes around, whose net output has been negative for a year, who is well liked.
• Two domains with a dependency that both leaders have agreed not to raise, because raising it means somebody loses headcount.
• A product surface nobody owns that generates a third of your support load.

Notice you did not have to go looking. You knew which one was yours before you finished the list.

Jesse Hanley, quoted in Justin’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.

The cost of touching an org’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.

You do not get to just pick it

This is where founder advice stops being portable, and where most attempts to translate it fall over.

Justin can decide to build podcast hosting. Nobody has to approve it. I cannot decide that my domain spends two quarters unwinding a team that reports to a peer.

So 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 it is the work.

Say 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. It becomes a thing that was said.

Turn it into a bet with a date and a number. “Operator onboarding is bad” gets nodded at and forgotten. “We take time to first value from eleven days to three by the end of Q3” 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.

Give 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.

Get one executive on the hook for the downside. Approval is not the same thing. 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.

Where this gets people hurt

Hanley spent seven years on Bento before it paid off. He could afford to, because he owned it.

You 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.

So pick hard problems that pay out in visible pieces. A bet that returns nothing until month twenty belongs to a founder. And accept that some hard problems are not worth your career. (I have walked past one I still think about. I would walk past it again.)

Walking 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.

Ask who else could do it

Look 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.

You 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.

By 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.

If 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.

Decisions become part of the organization

A 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.

The 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. “Improves scalability” 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.

That 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.

Why organizations keep going

The usual diagnosis is the sunk cost fallacy: we continue because we have already spent the money, time, and political capital. Barry Staw’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.

The Decision Lab 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.

A 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’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.

Stopping 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.

Ordinary 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.

Freek Vermeulen and Niro Sivanathan describe this as escalation of commitment to a once successful strategy. Their HBR article 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.

Record what must remain true

Most 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. “We need a new platform for scale,” for example, becomes “The current platform will exceed its tested transaction limit within eighteen months, based on the approved growth forecast.” 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.

Mark Hollingworth’s article on revisiting strategic assumptions 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.

I now want six things in a decision record:

1. The outcome we want, stated in terms a customer or operator would recognize.
2. The assumptions that connect the decision to that outcome.
3. The evidence available when we made the choice.
4. The signals that would require us to review it.
5. The expected cost of continuing, changing, or stopping.
6. The person who can call for a review, especially if the original sponsor disagrees.

This takes more effort than writing “approved” 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. “Customers will tolerate the migration” is too vague, while “our ten largest customers will accept one scheduled outage and no more than two required integration changes” gives a team something it can investigate before memory reshapes the original reasoning.

Review current evidence without retrying the past

Asking “Was this a bad decision?” 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.

This 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.

Isabelle Royer, writing about projects that organizations could not kill, argued for an “exit champion” 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.

Decide in advance what will trigger a review

Scheduled 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. Annie Duke calls the more decisive versions of these conditions kill criteria: 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.

The 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.

I 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.

Make the cost comparison honest

When 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:

• the remaining cost and likely value of continuing
• the switching cost and likely value of the best alternative
• the operating cost of delay
• obligations to customers, employees, and partners
• what the organization could do with the people, time, and attention released

Switching 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.

Opportunity cost deserves similar care because an imagined alternative has no defects yet. When somebody says, “We could use the team elsewhere,” 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.

The leader sets the price of changing course

Every 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’s decision has aged badly, the executive’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.

I try to begin with “What changed?” and “What do you recommend now?” 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: “I approved this based on the evidence we had. Two assumptions no longer hold, so I am reopening it.” That sentence names the decision maker without forcing an apology unless one is actually due.

Some 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.

A review needs a threshold

There 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.

A 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.

The 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.

A practical decision review

I 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:

1. What outcome did we intend, and what did we decide?
2. Which original assumptions still hold?
3. What material evidence has changed?
4. What options are available now, including the cost of switching?
5. What is the recommendation, owner, and next review trigger?

The 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.

The 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.

What happened to the migration

We 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.

The 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.

Six 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.

Since 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’s decision have an added responsibility to review it honestly today.

What 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.

Most 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.

The harder job is to make that judgment transferable.

Every 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.

The role moves

Engineering 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.

I 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?

Sometimes 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.

New managers often retreat toward technical work because they already know how to succeed there. Management remains the awkward work they do between coding sessions.

Three months later, I would ask one question: can more people make sound decisions without the manager stepping in?

Context is the first handoff

Managers 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.

That is task distribution. It creates activity, though it does little for judgment.

Product 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.

Before handing off meaningful work, I would want the person taking it to know:

• who has the problem and what they are trying to accomplish
• which constraints are real and which ones are habits
• what a poor outcome would cost
• which decisions are reversible
• when they should ask for help

This 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.

Process can preserve fear

Consider 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.

Managers 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.)

Before 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.

Process 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.

Mature teams need useful constraints, with old controls removed once their purpose has passed.

Communication teaches people how to think

Communicating down and communicating up require different kinds of discipline.

When 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.

Transparency 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.

Communication 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.

A 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.

After a few of these briefs, someone else on the team should be able to write one without you.

Follow-up is part of trust

Trust 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.

Trust 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.

Numbers 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.

Qualitative 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’s value appears between them.

Good 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.

Give away the next decision

Managers 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.

That hour is the work.

Each 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.

A 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.

Look 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?

Listen 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.

Managers 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.

If 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.

Deploy 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’t know if the engineering was good.

A writer who goes by german s. recently named the thing I was doing to myself. He calls it dopamine fracking: 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’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.

This 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’t the real risk, and that the thing actually at stake is something you won’t see on any chart until it’s already gone.

Goodhart’s Law with a body

We already have a sterile name for half of this. Goodhart’s Law: when a measure becomes a target, it stops being a good measure. Every engineering blog has covered it (including me, from a different angle). Lines of code get padded. Velocity gets inflated. Coverage hits ninety percent with tests that assert nothing.

All true, all known. The DORA team themselves tell you not to use their metrics for league tables. If gaming were the whole story we’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.

What “dopamine fracking” adds is the part Goodhart leaves out. Goodhart describes the mechanism. It doesn’t describe what the mechanism does to you after years of standing next to it.

The part everyone skips

german’s strawberry example is the one that stuck with me, so I’ll borrow it.

A 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’t tell. That’s the food industry. It’s also your metrics program.

The move that matters here isn’t the gaming. It’s what the synthetic version does to your palate over time.

First you stop noticing the difference. Then you start to prefer the concentrated hit because it’s cleaner and louder than the real thing. Then, eventually, you can’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.

Run 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’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.

Nobody games their way there. They taste their way there, one reasonable quarter at a time.

Your judgment is the most frackable thing you own

This 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.

Turn the rig around. Point it at yourself.

The least measurable substance in the entire building is leadership judgment. It has no dashboard. There’s no tile for “made a hard call that looks wrong for two quarters and right in year three,” or “spent six months developing someone’s taste,” or “killed a project everyone wanted.” So those are the things that get fracked hardest, precisely because they’re illegible. They can’t defend themselves with a number.

What you reach for instead is the concentrated hit. The status that goes green. The reorg you can announce. The “we shipped” 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.

I’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.

Running the rig and standing under it

The trap is that you’re doing both jobs at once.

You’re the operator. Every metric you choose to elevate is a drill you’re sinking into your own teams, training them toward the signal you reward. You’re also standing under someone else’s rig, reporting up, getting fracked by the dashboards your own leadership stares at. You optimize your teams for legibility because you’re being optimized for legibility. It runs all the way up.

Some people will say the answer is better metrics. SPACE instead of velocity. DORA done properly, three dimensions, qualitative balanced against quantitative. That’s true, and I use all of it. But it isn’t the interesting part, and on its own it won’t save you. A better proxy is still a proxy. It still trains your palate toward what’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.

The fix isn’t a cleaner dashboard. It’s keeping your palate alive on purpose, against the constant pull of the convenient version.

What I actually do now

Awareness is most of it, and I want to be honest that I haven’t got this solved. But a few things have helped.

I 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’s the one nobody charts. When the numbers and my gut agree, fine. When they disagree, that’s the most useful thing I’ll learn all week.

I 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’t say it, the org won’t value it, and the people doing it will stop.

I treat the clean hit as suspect. This is the habit I took straight from german’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’m tasting the synthetic version.

And 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.

The synthetic version always wins on cost and convenience. That’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’s the part that gets me. The window doesn’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’t any left.

The first time I had to end someone’s job, I rehearsed the sentence in the elevator.

Three lines, agreed with HR the day before. Clear, kind, final. I had the words. What I didn’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.

So I did the thing. Stared at my screen, clicked around, pretended to work. Left early. It sat with me for months.

Here is what that experience did to me, and it’s the only reason I’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 “probably fine,” I was the one who said no. Because I knew, in my body, what “probably fine” costs twelve months later.

That’s the real subject here. Not pain. Proximity to the consequences.

Pain is a proxy

There’s a popular version of this argument that I want to take apart before I make my own, because it’s half right in a way that’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.

I get the appeal. I’ve felt the thing it’s pointing at. But “you need pain” 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.

The thing that taught me wasn’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’t look away.

Plenty 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’s cost with no lesson attached.

So here’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.

Blame and distance are different dials

Almost 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.

Wrong argument. There are two dials here, not one.

The 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’ve welded these together in our heads, as if turning blame down requires turning distance up. It doesn’t.

You 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’s the good quadrant, and it’s available to anyone who wants it.

What actually happens in a lot of “mature” 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 “an incident.” The incident becomes “a learning.” The learning becomes a ticket. By the time it’s written up it has the emotional texture of a weather report. Nobody got blamed. Nobody got changed either.

Opt in to a generative organizational culture instead.

(The original blameless idea, the Etsy and Google SRE version, never argued for any of this. It said: don’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’s comfortable.)

Keep people close to the consequences

If proximity is the active ingredient, then the manager’s job is not to inflict pain and not to remove it. It’s to protect the signal. Keep people close to what their decisions do, and clear away the noise that makes them hide.

Start with the hard conversation. When you have to tell someone their performance isn’t working, or that the behavior in the last standup can’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’s an HR partner who will “lead the conversation.” There’s a script. Increasingly there’s a video call, which I’ve never had to do and hope I never do, because I’ve watched enough of them happen to other people to know that talking into a webcam strips out the exact part that teaches you. The discomfort of doing it in person is not a defect to be engineered away. It is the feedback. It’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.

I want to be careful here, because this is where the “no pain no gain” 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’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’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’re looking at by checking whether the person did the upstream work.

The same logic runs straight through engineering. The best thing I’ve seen for code quality is not a process. It’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 “some customers were impacted” is built, almost perfectly, to protect you from learning anything. Real names, real voices, real fallout. That’s what makes a team hold the line on quality past the point where holding it is convenient.

On-call 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’ve built a machine for producing things nobody has to live with.

The last one is about you, not your team. When a project starts to wobble, the tempting move is to swoop in and fix it yourself. Feels like leadership. It’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’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’t operate when I’m not in the room.

The machinery of distance is mostly invisible

Here’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.

Feature 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.

I’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’s job to notice it. So it becomes yours.

When 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’s a leak in the feedback loop. You should at least know the leak is there.

One open question

I’ll leave this one as a question, because I don’t think I have the answer yet.

The biggest distancing machine I have ever watched get installed is the one we’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’t think we’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’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.

Find 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 distance wearing mercy’s clothes. Learn to tell the two apart, and then stay in the room.

I 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.

The “we are all orchestrators now” 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 “your job is now to manage agents.” Your job is to recreate, on purpose, the safety pass that typing used to do for you for free.

Typing 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’t realized they still need it.

The bottleneck was never typing

This 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.

Most people would call the something else “thinking.” That is true but vague. The something else is a stack of activities that happen while you are writing code, that happen because you are writing code, and that you do not do at any other time.

You notice when the shape of the problem is wrong.

You realize the boundary between two modules is in the wrong place because filling in the second module makes the first one’s interface look stupid.

You 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.

You 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.

You read the previous engineer’s code while you are touching it and fix the bug you spot, the one nobody filed a ticket for.

You 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.

None of this is typing. But it was happening during typing, which is why we never separated the two, and which is why we are mostly surprised now that the work didn’t come along when the typing left.

The 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.

Slowness was load-bearing

The 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.

Take 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.

In the new workflow, you write a prompt that produces the data model. The model uses an optional. You scan the output, think “looks fine,” 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’t represent. Now you are debugging it as a runtime issue instead of catching it as a design issue.

Same 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.

Slowness 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.

We have always done stochastic engineering

One 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’t know what you’re going to get.

That 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’t have your model of the system in their head. Their version of “the right answer” 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’t have made, and you correct course in review.

This 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’t about typing, is a response to the stochastic nature of code produced by humans of varying experience working on the same system.

When 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.

The 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.

The shape an agent reaches for when nobody is watching

Here 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’t feel the difference. The human used to.

What 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’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.

I 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.

This is the same pattern I wrote about in No, AI didn’t break PRs. AI did not invent these failure modes. It amplified them and the speed at which they reach you.

The QA was hidden in the writing

I am not the first person to notice that “writing code” 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’t get any other way. We just never had to defend the practice, because the alternative wasn’t available.

Now the alternative is available, and the defense matters.

The QA that used to live in typing has to live somewhere now. If you don’t put it somewhere, you don’t have it.

This is the verification debt I’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.

In 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 “everyone is a tech lead now” 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.

Here 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.

Write your schemas by hand, 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.

Write your interface and API contracts by hand, 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.

Write the tests in a separate context from the implementation. 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.

The 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.

Some 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 somewhere, 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.

The shallow systems are not safer

It is tempting to read everything I have written so far as “this only applies to deep systems like databases and infra.” 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.

I want to push back on this, because the assumption that shallow systems are safer hasn’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.

I 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.

None 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.

The 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’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.

How the noticing gets learned

The 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, the senior engineer crisis arriving early and from an angle nobody planned for.

My answer is partial. Here it is.

The 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 not waving things through, of being willing to slow down at the artifacts that matter even when the agent is offering to skip them.

The 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’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’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.

What 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.

What changed is the price of one input

What 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.

Now code production is cheap. The other costs haven’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 toward: the shape of the answer, the contract of the interface, the test that proves it works.

Which 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.

Now we have to name it. We have to put it somewhere. We have to do it on purpose.

If 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’t build it in deliberately, the system doesn’t have it.

I 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.

Code is cheap. Being right is what is expensive, and that has always been the job.

Cycle 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.

Then the product lead asked what had changed for customers.

The 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.

I have been suspicious of speed ever since.

Speed 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.

Sometimes the system is working. More often, it is only moving.

The number was true

The annoying thing about bad productivity measures is that they are often accurate.

The 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.

They matter. They do not settle the question.

If 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.

This is why I still respect the SPACE framework, 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.

Activity is comforting because it looks like evidence. It only proves that activity happened.

The local optimum problem

Most speed improvements are local.

Code 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.

Local speed has a habit of dumping work somewhere else.

A 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.

The 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.

That is what most managers get wrong about productivity. They look for idle people. They should look for idle work.

The 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 “done enough” and “actually useful.”

Those checks are less pleasant than “how fast are we moving?”

They are also harder to game.

AI made the old mistake cheaper

AI has made this conversation more urgent. I do not think it changed the underlying mistake.

We already confused output with progress. AI just made output cheaper.

If your organization believes productivity means “more implementation in less time,” 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.

I do not trust any productivity claim that stops at generation speed.

Google’s 2025 DORA report 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.

That sounds right to me.

AI 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.

I do not read METR’s early-2025 study as “AI makes developers slower.” 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 changed its experiment design because measuring task-level productivity had itself become messy.

That revision feels like progress. The work is messy.

If 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.

Where the time went

When 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.

It 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.

I have made this mistake as a manager. More than once.

I 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.

This is why DORA’s own software delivery metrics 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.

The dashboard I want to see

I do not want fewer metrics. I want less self-deception.

The DevEx research 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.

A good dashboard should make the real delays harder to hide.

Show me how long work sits after it is “done” 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.

None of those numbers is perfect. Some are barely numbers.

That is fine. The point is to start a better conversation.

After a project lands, I like asking what got easier.

If nothing got easier, be careful.

The 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.

But 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.

The team is consuming work and producing artifacts.

That is not the same as progress.

What I would change as a leader

I would start smaller than most productivity programs start.

I 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.

I 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.

I 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?

I 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.

I 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 “quick question” interrupts. The dashboard says throughput improved. The senior engineer’s calendar says otherwise.

You 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.

What to say out loud

There is a sentence I wish more leaders would say in public:

“We are moving faster. I do not know yet whether we are more productive.”

That sentence creates the right kind of discomfort.

It 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.

Most 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.

Telling that team to go faster is lazy management.

The 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’s attention.

None of this is new. That is part of why it is annoying.

Productivity is not speed. It is what remains after the movement has been tested against something real.

Five 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.

Two said yes. They liked her. She was sharp, the conversation flowed, she “got it.” 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.

I 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.

I have run that meeting more times than I would like. So have you, probably.

This 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 “she seemed strong” was the strongest argument anyone in the room could muster.

There are two layers to the problem. Most posts about interviewing fix one and ignore the other. You need both.

The wrong layer of detail

By 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.

“Works independently on complex tasks.”

“Drives improvement in team processes and tools.”

“Influences technical direction across multiple teams.”

These sentences are correct. They are also useless to the person trying to design an interview around them.

The 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.

A framework tells you what a Senior Engineer should be capable of. It is silent on how to find out whether the person sitting across from you actually is one.

This 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.

The 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.

From statement to behaviour to question

The fix for this half of the problem is a translation step that almost no company does explicitly.

I 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.

Three steps:

1. Pick one statement from the framework at the level you are hiring for.
2. Ask: what does that look like as observable behaviour, in daily work, for this specific role?
3. Write a question that surfaces that behaviour.

Sounds obvious. Almost nobody actually does it.

Take the Senior Engineer line: “Drives improvement in team processes and tools.”

Step two forces you to get concrete. What does “driving improvement” 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.

That is observable. You can ask about it.

Step three is then almost mechanical. “Tell me about a piece of work you did that changed how your team or another team operates. How did that come about?”

Notice 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.

Compare it with the question most interviewers actually ask, which is some variant of: “Tell me about a time you showed leadership.” 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.

You 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.

Impressions are not evidence

Solving the first half only gets you so far.

Even 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.

I 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 Why I Dumped LeetCode Interviews, so I am not innocent.) We almost never argue about how interviewers record what they hear. And that is where the wheels come off.

Here 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?

In my experience, even thoughtful interviewers come back with notes that are 80% interpretation and 20% direct observation. Sentences like:

• “She seemed nervous in the system design round.”
• “He really knew his stuff on Postgres.”
• “They had a strong opinion on testing.”

None 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.

I came across a post by Dan North a while back called Interviewing for Evidence. 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.

The 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.

“She seemed nervous” is not evidence.

“She paused for almost twenty seconds before answering, then said she was not sure how she would approach it” 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.

Once 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.

That is a lot of decisions being made on vibes.

Four kinds of evidence

Dan’s post unpacks this further. There are four kinds of evidence you can collect in an interview, and each tells you something different.

In rough order of weight:

Experiential evidence. Things the candidate has actually done. “Tell me about a time when…” “Can you give me an example of…” “Then what happened?” 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.

Hypothetical evidence. What the candidate thinks they would do. “What would you do if…” “If you had to do that project again, what would you change?” 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.

Opinion evidence. What the candidate thinks about things. “What is your view on testing?” “What do you think makes a good code review?” 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.

Credential evidence. 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.

Most 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 “and then what did you do?” until the story either holds together or does not.

A 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 “and what is your view on microservices?” My next question should be “give me an example of a service migration you led.”

The calibrated interview

Now stitch the two halves together, because that is where the actual fix lives.

A 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.

If your framework says, for Senior level, “Influences technical direction across multiple teams”, you can build a small set of questions for that cell:

• Experiential: “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.”
• Hypothetical: “Suppose you joined our platform team and noticed two product teams had quietly built different solutions to the same problem. What would you do?”
• Opinion: “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?”

Three different angles on the same framework line. Each surfacing a different kind of evidence. Each grounded in something observable.

Now compare what your debrief looks like with this setup versus without it.

Without it: “I think she was a strong Senior. She seemed to get it.”

With it: “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.”

Those 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.

Worked example: a Senior Engineer loop

Let me make this less abstract.

Suppose you are hiring a Senior Software Engineer for a backend team. Your framework, summarised, says they should be able to:

1. Own a non-trivial system end to end.
2. Drive improvement in team processes and tools.
3. Mentor and grow more junior engineers.
4. Influence technical direction within the team and occasionally beyond.
5. Communicate clearly with non-engineering stakeholders.

You have a four-stage loop: hiring manager screen, technical deep-dive, system design, and a behavioural round.

Without translation, each interviewer picks up the framework, reads it, and goes “I will ask about ownership somehow.” 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.

With translation, the loop looks different. Each stage owns specific framework cells, and each question in that stage is mapped to an evidence type.

The hiring manager screen takes Ownership and Communication. The questions are mostly experiential and opinion. “Tell me about the last system you genuinely owned, end to end. Who else was involved? What did ‘owning’ actually mean day to day?” “How do you usually communicate technical risk to a product manager who is pushing for a deadline?”

The technical deep-dive takes Drive improvement and Mentoring. Hypothetical and experiential, mostly. “Walk me through a time you noticed something the team should change and made it happen.” “If you joined our team and saw a junior engineer repeatedly making the same mistake in their pull requests, what would you do?”

The system design takes Influence technical direction. Mostly hypothetical, with experiential pull-ins. “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.”

The behavioural round takes Mentoring, Communication, and Drive improvement, with deliberate cross-checks against earlier rounds. “Earlier you mentioned a refactor you led. Tell me how you brought your team along on it.” 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.

The 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.

Where this fails most often

A few things will break this if you let them.

The framework itself is terrible. 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 There Is No Standard EM Role, and the same logic applies to engineers: if you have not defined the role for your context, you cannot interview for it.)

One interviewer trying to cover everything. 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.

Treating “passes the bar” as the unit. 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 “I do not have evidence on cell X” 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.

Senior interviewers who refuse to write evidence. The ones who have been doing this for a decade sometimes treat the move from impressions to evidence as bureaucratic. “I just know when someone is a Senior.” 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.

Confusing the candidate’s smoothness with their level. 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 The Top 11 Technical Interview Myths, if any of you are on that side of the table right now.)

The standard

If 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.

Frameworks 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.

You 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.

This 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.

I 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.

Most 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.

That is the standard. Refuse to lower it.

LinkedIn is full of engineers who have just discovered that pull requests are impossible to review at the pace AI agents produce code.

Pull requests as a bottleneck. Imagine that.

Now they are searching for new ways of working to solve this brand new problem. New frameworks. New tools. New triage agents. New rituals.

There is nothing new about it.

I keep writing this argument in different shapes, 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.

That is most of the story. Everything below is about why teams keep refusing to see it.

The cost was always there

A 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.

I want to be careful here, because pull requests are not the villain. They were a perfectly good answer to a different question.

GitHub-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.

The 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.

Once 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.

Martin Fowler made this argument long before AI showed up. 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 “few”. Zero. The review never happened. The wait did.

Why the new tools cannot fix it

I am not against tooling. I have spent most of my career building it. But the current wave of “AI code review at scale” pieces are largely answers to the wrong question.

Look at where the energy is going. Cloudflare deploys seven specialized reviewer agents per merge request. Anthropic estimates roughly twenty-five dollars per AI review. Vendors compete on agent count, prompt sophistication, and policy coverage. None of this is unreasonable on its own terms.

It is also a remarkable amount of effort spent paving over an architectural choice that was already wrong before AI showed up.

You 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.

I wrote earlier that the bottleneck moved. This is what that actually looks like in the wild. And if you have read the post on Theory of Constraints, 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.

The objections are real, and they are not arguments for PRs

When I make this case, four objections come back, every time. They are real. I am not waving them away. They are arguments for designed collaboration, not for shipping work over a wall.

Compliance and four-eyes. 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 “LGTM” left at 6:47 pm by someone who scrolled to the bottom. (I know which one would hold up better in a postmortem.)

Distributed teams. 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.

Junior engineers need room to attempt things on their own. 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.

Audit trails. 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.

None of this is anti-PR. It is anti using PRs as a substitute for talking to each other.

What hasn’t changed in twenty years

The advice is not new. That is the entire point.

Pair, 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. Trunk-based development has a perfectly good handbook and has had one for years.

What changes when you do this is not subtle.

AI 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.

Throughput 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.

Reviews stop being choke points. They become conversations.

Tests 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. I have written before about verification debt, 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 why hand-rolling your schemas, interfaces, and tests matters more than people think, and how the slowness of typing was doing load-bearing QA work nobody invoiced for.

What this would have looked like

Imagine 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.

That team is having a different 2026 than the rest of us.

For 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’s planning.

They 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.

The 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.

(I have seen versions of this play out before. Every “new” engineering problem of the past decade had an answer that someone had already written down in 2003. The answer was usually unfashionable.)

A return, not a discovery

I 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.

For 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.

The fix is not a new workflow. The fix is the workflow we already knew worked.

It is not a discovery. It is a return.

She 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.

I asked her what it felt like. She paused. “Different than last time.”

She 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.

This time was nothing like that. She wasn’t tired. She was hollow. The work was technically fine. The team was fine. Nothing was on fire. She just couldn’t find a reason to care about any of it, and the absence of that reason was its own slow horror.

“I thought this was supposed to get better when I got senior,” she said.

It doesn’t. It just changes shape. And almost nobody tells you that.

That conversation has stayed with me, because I’ve had some version of it dozens of times now. Different titles. Different orgs. The same confusion: why does the burnout I’m experiencing right now look nothing like the burnout I’ve been trained to recognize?

The honest answer is in a piece Daisy Auger-Domínguez published in HBR earlier this month, which I think is the most useful thing I’ve read on burnout in years. Her central claim: burnout isn’t one illness. It’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.

I 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’t quite name.

Then 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’t have the authority to redesign the work?

This will be uncomfortable. Burnout coverage in our industry is overwhelmingly about either symptoms (the seven warning signs of engineering burnout, the 10 tips for engineers) or about exhortations to leadership to “fix the system.” Both are useful, and I have spent time on the symptoms angle myself in Demystifying Burnout. But neither tells you what to do at 11pm on a Thursday when you’ve just realized you’ve been in survival mode for nine months and the system has no plans to fix itself.

So let’s talk about the five faces. Then let’s talk about the AI overlay. Then let’s talk about what to do when you cannot redesign the design.

Face one: ambiguity (the burnout of the early-career engineer)

Auger-Domínguez calls this Invisible Overload. Her description: constantly guessing what “good” looks like. Spending more time decoding expectations than doing the work. Anxiety about being replaceable.

I have watched this play out in person more times than I can count.

The 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 “is this what you wanted?” 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 meaning of the change is unclear.

They 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 “fast enough” means here, modeling what their tech lead actually wants when they say “use your judgment.”

In 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.

In hybrid and remote engineering orgs, that absorption layer is gone, and we have not replaced it with anything. So the work doesn’t disappear. It moves into the engineer’s head, where it sits there draining cognitive energy 10 hours a day with no name.

Research consistently shows that lack of control and unclear expectations are stronger predictors of burnout than hours worked. The early-career engineer isn’t burning out from coding too much. They’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.

The cruel part is that this burnout is invisible to managers because the work is still getting done. They’re still shipping. They’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.

What actually helps at this layer:

• Make the implicit explicit. Write down decision rights. Say out loud who has authority for what. Tell people what “good” looks like with specifics, not vibes. The cost of explicit norms is some boring documentation. The cost of implicit ones is your team’s nervous systems.
• Cap weekly priorities at three. Not five. Not “everything is important.” Three. People can hold three things in their head and still feel like they’re winning. They cannot hold seven.
• Normalize asking. Demonstrate that asking “what do you actually want?” is a sign of engineering maturity, not weakness. Then catch yourself when you punish it.
• Real-time feedback, not review-cycle assessments. 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’s a postmortem.

Face two: compression (the burnout of the engineering manager)

Auger-Domínguez calls this Compression. 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.

In engineering, this is the EM and the senior EM, and it is the single most underappreciated burnout pattern in the industry.

The EM’s job, in practice, is to translate. From product into eng. From strategy into roadmap. From the VP’s vague directive into something the team can actually execute. They are the load-bearing wall between two layers of the org that don’t quite speak the same language.

The 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’t burn. When it breaks, the EM becomes a pressure-release valve with no exhaust.

The contract breaks in predictable ways. The reorg that adds two more teams to the EM’s portfolio without adding direct reports of their own. The new VP who wants to be looped into “all major technical decisions” but won’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’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.

One survey found middle managers report higher burnout (36%) than non-managers, and 71% report being “sometimes or always” overwhelmed. That gap isn’t because EMs are weaker. It’s because the role, as currently designed, is a structural burnout factory.

I 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.

The EM’s burnout doesn’t look like exhaustion. It looks like Sunday anxiety. It looks like checking Slack at 10pm because if you don’t, you’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 there is no quiet anywhere in the schedule for the kind of thinking strategy requires.

What helps:

• Reduce meeting load from the top. Not as an EM hack. As an explicit executive choice. If your EMs have eight hours of meetings a day, you don’t have managers, you have meeting attendees with managerial titles.
• Clarify decision rights so the EM doesn’t have to manufacture them. “You can spend up to X without approval.” “You can make the call on Y.” “Z escalates.” Specificity is a love language for managers.
• Build a regular check-in that asks about obstacles, not status. Status updates are theater. “What is in your way that you can’t move yourself?” is the only question that surfaces compression early enough to help.
• Stop calling availability commitment. 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.

Face three: the dual-ladder trap (the burnout HBR doesn’t quite name)

Here’s where the HBR framework needs an engineering-specific addition.

Engineering organizations have something most other professions don’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.

In 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’s other categories.

The 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’ worth of engineers. They are evaluated on impact, scope, and “tech leadership,” none of which are things they can do without authority over other people’s time and priorities. But they don’t have direct reports. They cannot say “do this.” They can only convince, persuade, model, write, and influence. And when the persuasion fails, the impact suffers, and they get told they need to “level up their tech leadership.”

This is moral injury without the title to absorb it. They see what’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’t have the executive authority to force the issue. The codebase they’re responsible for keeps degrading in a direction they predicted. Eventually they stop predicting, because what’s the point.

I 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 “they decided they’d rather just code.” From the inside, it’s grief. They cared. They tried. They got tired of their care being treated like a free resource.

The 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’t. They give Staff engineers visibility and weight, but reserve the actual decision rights for VPs and directors who have less context.

If 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’t a sign you’re insufficiently resilient. It is a signal that the role, as your org has structured it, is not actually possible. That doesn’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.

Face four: moral injury (the burnout of the executive)

Auger-Domínguez calls this Moral Injury, borrowing a term from Jonathan Shay’s research on combat veterans. The original definition: the lasting damage done by perpetrating, witnessing, or failing to prevent acts that violate one’s deeply held moral beliefs.

Inside 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 “strategy.” A sense of carrying consequences alone.

The 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’t happen.

You did not make the decision. You disagreed with it. You executed it anyway, because that is what the job requires. And you carry it.

That’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. Recent research on tech leadership notes that 26% of executives report symptoms consistent with clinical depression, compared to 18% in the general workforce. The gap is not because executives have it harder. It’s because their burnout is shaped by something most workplaces don’t even have a vocabulary for.

The cruel part of moral injury is that the standard burnout fixes make it worse. “Take a vacation” doesn’t help, because the moral residue doesn’t decay with rest. “Set boundaries” doesn’t help, because the problem isn’t volume of work, it’s the content of the decisions you’ve made. “Do more self-care” lands as condescension, because the executive knows perfectly well what self-care is. They are not in distress because they’re insufficiently rested. They’re in distress because they have done things that they can no longer pretend not to have done.

What helps, and this is genuinely hard:

• Trusted peer forums. Not your direct reports. Not your boss. Not your spouse, who shouldn’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’t have this, build it. Other CTOs are your peers in a way nobody inside your company can be.
• Slow the decision pace. Most executive burnout I’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.
• Name the values conflict explicitly. 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.
• Stop confusing composure with health. The fact that nobody can tell you are suffering is not a sign that you aren’t.

Face five: identity collapse (the burnout of the founder, and the head of engineering who acts like one)

The final shape Auger-Domínguez names is Identity Collapse, 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.

I want to extend this to a category she doesn’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’t take a real vacation because “what if something happens.” The VP of Eng who answers Slack from their kid’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.

This isn’t rare. It’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.

The signal is usually something a partner notices first. They can’t put their phone down. They go on vacation but they’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’s birthday party.

If 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. “If I rest, I worry no one will carry the mission” 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.

The ladder doesn’t cure burnout. It changes its shape.

This is the implicit truth in Auger-Domínguez’s framework, and it’s the part I think more engineers need to hear out loud.

The mid-level engineer who burns out from too many tickets often consoles themselves with: “this will get better when I’m senior. Senior engineers don’t get pulled into every fire.” Then they get to senior and the fires are different but they’re still on fire.

The senior who burns out from being on call for everything tells themselves: “this will get better when I’m Staff. Staff engineers get to focus.” 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.

The Staff engineer thinks: “this will get better when I move into management and have actual reports.” 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.

The EM thinks: “this will get better at director, when I’m shaping strategy instead of executing it.” Then they become a director and discover moral injury, and isolation, and the slow weight of decisions they cannot fully make.

The director thinks: “this will get better when I’m VP, when I have real authority.” And the VP, who has more authority than they’ve ever had, finds out that authority is the thing that creates moral injury, not the cure for it.

The ladder is not a treatment plan. Each rung is a different illness. Promotion does not heal you. It changes which symptoms you have.

This is not a counsel of despair. It’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.

The 2026 AI overlay

I want to add one piece the HBR framework doesn’t cover, because it’s relevant to anyone in engineering reading this in 2026.

AI is amplifying every layer of the burnout map. Not equally. Differently.

For the early-career engineer, AI has dramatically increased the ambient ambiguity. What does “good” look like when 80% of your code can be generated, and the remaining 20% is the part that requires judgment you don’t yet have? “Junior engineer” used to mean “person learning to code.” Now it means “person learning to evaluate code,” which is a much harder job to learn cheaply. The decoding load has gone up, not down.

For the EM, AI has multiplied the throughput of their team without multiplying their decision capacity. PR volume goes up. Review burden goes up. The number of small decisions per day goes up. The EM’s own brain stays exactly the same size. Compression intensifies.

For 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’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.

For 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’t fully understand the technology and employees who rightly fear what those decisions will mean for them. Layoffs framed as “AI efficiency.” Hiring freezes framed as “we’ll see what AI does.” Each of those is a moral-load decision, and there are now a lot more of them per quarter.

I’m not saying AI causes burnout. I’m saying the five faces are all currently being amplified by it. Anyone diagnosing their own burnout in 2026 should factor this in.

What to do when you can’t redesign the system

This is the question almost no one writes about honestly.

Most burnout coverage assumes you have the authority to fix the conditions producing it. “Cap priorities at three.” “Clarify decision rights.” “Reduce meeting load from the top.” Wonderful. What if you’re the EM whose VP has not heard of any of this and won’t?

Here is the honest answer, in three parts.

First, get accurate about which face you have. This sounds trivial. It isn’t. Most people I’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’re broken.

Read the HBR piece. 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 Maslach inventory I shared earlier is the standard tool for scoring it. Notice that the face you have is probably not the same one you had two years ago.

Second, do the things you can do, even when they feel insufficient. You may not be able to redesign your org. You can, almost always, do some of the following:

• Get your own decision rights in writing, even informally. “Just to confirm, I have authority on X up to Y. Anything beyond that, I’ll bring to you.” Send it as a Slack message. Save it.
• Cap your own priorities at three. Even if your boss has given you ten. You can only do three well, anyway.
• Pick one recurring meeting you can decline. Decline it.
• Have 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.
• Notice when you’re doing emotional labor that nobody asked for and nobody will reward. Stop doing some of it.

These 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.

Third, accept that some roles, as currently structured, are not survivable, and leaving is sometimes the correct fix. I am suspicious of every burnout post that ends with “and so I quit and started a substack.” I’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’s accurate.

That 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.

A final note

I 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.

I told her: the burnout you have right now is not the burnout you’ve been trained to recognize. The version you have is real. It has a name. It has a shape. The fact that it doesn’t look like the kind of exhaustion you’ve been taught to spot doesn’t mean you’re imagining it. It means the map you were handed was incomplete.

Engineering as an industry has gotten reasonably good at noticing the early-career version of burnout. We’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.

The five faces are all real. They are all happening at your company right now. They are all under-named, under-treated, and routinely misdiagnosed.

If 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’re responsible for. The fix that maps to the wrong burnout is the fix that doesn’t help. The fix that maps to the right one, even when it’s small, is the fix that buys you years.

The work is not to be more resilient. The work is to be more accurate.

It’s a reasonable question. But I think it’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’ve heard of. And most of those rooms are making the same call without realizing the long-term consequences.

I’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.

What follows is my honest attempt to think through where we’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’m going to be more specific than “it could go several ways.”

I have opinions. I’ll share them.

The pipeline nobody noticed

For decades, the junior-to-senior progression worked almost automatically.

Not because companies were particularly good at developing talent. Most weren’t. It worked because the environment 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.

I learned more in my first two years from reading other people’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.

Here’s what’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’s obviously good for output. It’s not obviously good for learning. When you skip the struggle, you skip the part where the mental model forms.

And simultaneously: there are fewer juniors to speak of. Entry-level tech job postings have dropped by more than 60% since 2022. Stanford researchers tracked a nearly 20% decline in employment for software developers aged 22-25 from late 2022 to mid-2025. A Harvard study found that in firms actively adopting AI tools, junior employment fell by nearly 8% relative to non-adopters within six quarters. These aren’t rounding errors. An entire cohort is missing.

So 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.

Why the optimistic reading keeps failing

The 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.

I find this argument genuinely compelling as history. I find it much less compelling as forecast.

The thing about previous abstraction layers is that they made programming accessible to more people, 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.

AI does something categorically different. It doesn’t lower the floor by making concepts easier to learn. It lowers the floor by letting you skip the concepts entirely. You can ship working software without understanding what it does. That is genuinely new (and harmful/dangerous on many levels, but that’s for another post…).

There’s a real version of the optimistic scenario where new entry points emerge that we haven’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.

But I don’t think you can bet a talent strategy on “maybe.” And more importantly, I think we need to be honest about what the data is already showing.

Three predictions, not three scenarios

Most writing on this topic offers you a menu of scenarios and declines to pick one. That’s intellectually safe. It’s also not very useful.

Here’s what I actually think is going to happen, in roughly the order I expect it to unfold.

First: a two-tier labor market, arriving faster than expected

This is already beginning. It won’t look like a sudden bifurcation. It will look like a gradual widening.

• On one side: engineers who have judgment, system intuition, the ability to debug things they’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. These people are already scarce. They will become scarcer.
• On the other side: 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’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.

The 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’t fully understand.

I want to be careful here. I’m not saying the AI-native engineers are less valuable. In many roles they’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.

Second: a talent war in 2029-2031 that makes 2021 look mild

The 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.

What 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’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.

I’ve been in that environment before, and it’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’ve developed walks out the door when someone offers them a 40% raise.

The 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’ll have mid-levels they grew into seniors. They’ll have seniors who know their systems deeply because they’ve been there long enough to accumulate the context. Everyone else will be competing for the same thin pool of external hires.

Third: a correction in how the industry thinks about AI and skill formation, probably around 2030-2032

I 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.

I expect something similar with AI and engineering skill formation. Not a rejection of the tools. The tools are genuinely transformative, and some productivity gains are real. But a serious reckoning with the second-order effects.

The evidence is already starting to accumulate. Stack Overflow’s data 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.

My 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’ll treat AI assistance and depth-of-understanding as separate axes to develop deliberately, rather than assuming the first produces the second.

The organizations that figure this out first will develop stronger engineers faster than the ones that don’t. Not because they reject AI, but because they use it with a clear model of what it does and doesn’t teach.

What the 2035 picture actually looks like

Put all three of these together and here’s what I think the engineering talent landscape looks like in ten years.

The 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 “democratization” reading will have come partially true.

But 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.

Charity Majors put it well: “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.” AI has accelerated code writing significantly. It has done very little for the rest of what seniority actually means.

The 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.

The thing that worries me most

I’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.

What got cut in many of those rounds wasn’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’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’re carrying the entire weight of technical decision-making alone, when the institutional knowledge that was being passed down just… stops.

The same dynamic is playing out at the junior level, and I think the timescales involved mean we won’t fully see the consequences for years. A 22-year-old who couldn’t get a job in 2024 didn’t disappear. Some of them found their way in eventually. Some changed careers. Some are brilliant engineers who just needed a different entry point.

But there’s a cohort - I genuinely don’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’t be reconstructed later.

I 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.

What I think you should actually do

The honest answer is that individual companies can’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.

A few things I think are worth doing now, not as a checklist but as a genuine shift in how you think about talent.

Treat junior hiring as risk mitigation. 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. “Here’s what we’ll be paying a senior engineer in 2029 if we haven’t grown any internally” lands differently than “we should invest in people.”)

Don’t assume the conditions for growth are present. 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’t anymore.

The 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.

So you have to reconstruct the friction deliberately. Not by withholding AI tools - that’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 a tool they’re steering, not a crutch doing the thinking.

I’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’re trying to build in each person, and they choose work assignments accordingly. They’re playing a longer game than the sprint.

Invest in making knowledge visible. The institutional knowledge in your most experienced engineers’ heads is the most irreplaceable asset you have. It can’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.

The 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.

Track your knowledge concentration. How many people on your team can independently debug your three most critical services? What’s your bus factor on your oldest, most important codebase? If the answer to either question is “one or two,” you have a fragile organization - and the fragility compounds over time if you’re not actively moving knowledge around.

And if you’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 not the ones who ship the most features today. They’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.

Seek 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’s right - or whether it’s right at all. The discomfort of not immediately knowing is exactly where the growth happens. Don’t outsource it.

The choice that’s already being made

Here’s what I keep coming back to.

The 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.

Every 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’t fully feel for years.

I 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.

The irony is that the companies best positioned for 2035 won’t look obviously superior in 2026. They’ll look slightly less efficient. They’ll be carrying some overhead in the form of junior engineers who aren’t yet fully productive. Their senior engineers will spend some time on mentorship that doesn’t show up in sprint velocity.

And then 2029 arrives, and the talent war starts, and those are the teams that already have the people they need.

Then she told me she was leaving.

When I asked why, she said something I haven’t forgotten: “I feel like I’m still waiting to do real work.”

She wasn’t being ungrateful. She wasn’t wrong. I had run a textbook onboarding: graduated her through a learning path, assigned well-scoped tickets, shielded her from ambiguity while she “found her footing.” I had read the right blog posts, used the right frameworks, done everything a thoughtful engineering manager is supposed to do.

I had also accidentally built a school. And she had spotted it.

The School We Built Without Noticing

Most engineering teams grow people with school logic.

New 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 “here’s the ten things you need to understand before we trust you with anything real.”

We do this for understandable reasons. We want to lower the odds of public failure, so we remove ambiguity and sequence the hard parts.

But the effect is the same as any classroom: we have placed the learning before the doing.

Simon Sarris made the point well in 2024 in School Is Not Enough. People learn through the work itself.

What the school model looks like in a codebase

On an engineering team, the school model shows up as pre-decomposed tickets.

A 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.

I’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.

That is staffing, not growth.

Senior 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.

Bradford Cross makes a similar point about the damage of “just take the next ticket.” 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.

I’ve hired technically strong engineers from competent teams who froze the first time a problem arrived without predefined edges.

The Fake Work Problem

People can tell when the work is fake.

Starter 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.

I 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.

Three 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.

Real work created care; the learning path created compliance.

“Safe” Is the Most Expensive Word in Your Vocabulary

Managers often say, “They’re not ready for that yet. Let them build confidence first.”

I think that gets the sequence wrong.

Confidence 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’s research on expert performance points the same way. Expertise grows at the edge of current ability, with feedback from real outcomes. Safe tasks do not produce that.

Sarris puts it plainly. “It is building skill itself that builds self-possession.”

In 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.

Those 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.

When 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.

The Apprentice Model

The alternative I’m reaching for isn’t “throw juniors in the deep end and see who swims.” That’s not how apprenticeships historically worked, and it’s not what I’m advocating.

The apprentice model is different. In Verrocchio’s studio, da Vinci didn’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 real: 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.

The studio metaphor is more useful than the school metaphor for engineering teams, and I’d encourage you to spend some time with it. It also has a serious theoretical grounding: Lave and Wenger’s situated learning research found that newcomers in craft communities didn’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.

In a school, the point is the curriculum. The work exists to teach.

In a studio, the point is the work. Learning is what happens when you do real work seriously.

Your 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’t map well to an environment where any engineer can learn almost anything on demand.

Your 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.

Will Larson writes about the art of finding “safe learning projects that also provide real value to the business.” I’ve long admired how precisely Will thinks about organizational problems, and he’s right that this is an art. But I’d push back on the framing. The goal isn’t to make the project safe. The goal is to make the environment 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’s a safe learning environment. A project with artificially reduced complexity is just school with a paycheck.

The Permissionless Principle

There’s a specific point Sarris makes about software that I keep returning to when I think about engineering culture.

He argues that programming thrives because of its “permissionless culture.” You don’t need a building permit. You don’t need an audience or a patron. You don’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’t make them wait.

He’s right. And most engineering managers are quietly dismantling this.

The 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’ve built a bureaucracy that requires explicit permission at every step, and you’ve sucked the agency out of what should be the most agentive environment in any company.

The engineers who grow fastest are almost always the ones who don’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’t in the sprint and show you the metrics afterward. They move ahead and course-correct when needed.

Your 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.

(I’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.)

The 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’re being lazy - and this is important, because there’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’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.

What Real Stakes Actually Feel Like

Real stakes don’t require catastrophic risk. I’m not suggesting you put a junior engineer on-call for a P0 service in their first month.

Real 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.

In practice, I’ve found this shows up in a few specific forms.

One 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.

Another is writing the post-mortem after something they own breaks in production. This one is uncomfortable and I’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’re going to do about it. It develops a kind of seriousness about reliability that no training module comes close to.

A 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.

That shift - from executing to owning - is the thing you’re trying to produce. And it only happens when someone else depends on you for real.

The Senior Engineer’s Role in All This

Senior engineers often get the wrong instruction.

We tell them to mentor juniors, review code, and stay available. That pushes them toward the role of teacher.

The more useful framing: the senior engineer’s job is to be the studio, not the classroom. They model the work, not the curriculum.

Bring 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.

Review PRs like conversations between peers. Code review should feel like joint problem-solving, not grading.

Sometimes 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.

An Honest Note on AI

I can’t write this post in 2026 without acknowledging the AI acceleration context, because I think it changes the argument slightly.

If 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’d be at least partly right.

But if your theory is that the real value of a senior engineer is judgment - 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 more important, not less. The work that remains most distinctively human is exactly the work you can only learn by doing it under real conditions.

Training an engineer to complete pre-defined tasks is now, more than it has ever been, a mistake. The tasks are the part that will be automated. The judgment is the part that won’t be. And judgment only grows through experience with real stakes.

What to Actually Change

Stop pre-decomposing everything. When you’re tempted to break a project into tasks before handing it to a junior, ask yourself: what’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?

Give ownership of outcomes, not activities. “You own the reliability of this service” is different from “you own the on-call rotation for this service.” 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.

Make the stakes visible. Engineers often don’t know that what they’re working on matters to real people. They don’t know the customer has been complaining about this bug for six months. They don’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’t are telling you something useful early. Of course, do this in a safe environment, acknowledging what’s actually feasible.

Explicitly carve out permissionless space. 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 “things you can do without asking” and “things that need coordination,” and make the first category as large as possible.

Bring people into the room when decisions get made. When you’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’t clean. You will teach them more in that hour than in a month of tickets.

Make the onboarding project real. This one is uncomfortable. It’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’s invisible until it fails.

There’s a question underneath all of this that’s worth sitting with honestly: what are you actually trying to produce?

If the answer is “engineers who can reliably complete the tasks on their backlog,” the school model is fine. It’s efficient. It produces people who are skilled at defined tasks and comfortable in defined environments.

If the answer is “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’t encountered yet” - then you need something different.

Sarris writes that “the purpose of education is to develop agency within a child. Purposeful work and achieving mastery are tools to getting there. They aren’t the results of learning and imagination, it’s the other way around.” Swap “child” for “engineer” and you’ve described what most of us should be doing differently.

Agency 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.

That’s the only kind of growth that actually transfers.

I 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 “Development - 2015.”

I changed nothing. My manager never followed up. The folder still exists somewhere in a Google Drive I no longer have access to.

I share this not because I’m uniquely bad at follow-through - though I’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.

There’s a better way. But I want to challenge something first.

The Dirty Secret Nobody Talks About

Most 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.

But there’s a second problem nobody addresses, and it’s the one that kills most genuine improvement efforts.

You can actually change, and nobody notices.

Here’s what happens. Let’s say your 360 surfaces that you’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.

Three months later, your directs still think of you as dismissive.

Not because they’re cruel or unobservant. Because the human brain doesn’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 “dismissive leader,” their brain will continue to notice evidence that confirms that label and unconsciously minimize evidence that doesn’t. They’ll remember the one time you cut someone off and forget the six times you didn’t.

The spotlight effect makes it worse. You think people are paying close attention to your behavior. They’re not. They’re busy. They’re focused on themselves. They’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.

This is why behavior change is actually two jobs. There’s the change itself - the specific, disciplined work of doing things differently. And then there’s the social work of making sure the people who formed their opinion of you actually get a chance to update it.

Most people only do the first job. This is why most 360 improvement efforts quietly die.

Choose Who Gets to Watch You Change

The 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’s fine advice if your goal is collecting valid data.

But if your goal is actually changing your reputation - which is what you’re trying to do, whether you admit it or not - the selection criteria are different.

I now think about rater selection in terms of two questions.

• First: who gave me this feedback? If your directs told you they don’t feel heard, those directs need to be in the group. If your peers said you’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.
• Second: who do I actually want to influence? This is the question most people don’t ask out loud, but it’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’s just honest about what’s actually at stake.

The 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.

Not All Feedback Deserves Your Commitment

When the feedback comes back, the instinct is to treat it like a verdict. Nobody told me what I’m about to tell you, and I wish someone had. Someone said you’re impatient, so now you’re working on patience. Someone said you don’t delegate enough, so delegation goes on the list. Someone said you need to be more strategic, so you add “be more strategic” to your development plan and promptly have no idea what to do with it.

I’ve sat in enough conversations with people reading their 360 reports to know what this looks like in practice. It’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.

That’s not development. That’s self-erasure.

The more useful move is to go line by line and consciously sort each piece of feedback into one of three buckets.

Sign it. This is real. You recognize it. You want to change it. When you sit with it honestly, it describes something you’ve half-known about yourself for years. Commit fully. These are your actual development targets.

Realign it. The underlying point is valid, but the framing doesn’t fit who you are or how you work. “Be less blunt” might become “choose the right moments for directness.” Same direction, different execution. You’re not declining the feedback - you’re translating it into something authentic enough that you’ll actually do it.

Decline it. This exists. Some feedback conflicts with your values. Some of it reflects someone else’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’ll actually do.

This is harder than it sounds, because “decline” can easily become “I’m too proud to hear difficult feedback.” The way I try to tell the difference: am I declining because this doesn’t fit how I work, or am I declining because it’s uncomfortable? The first is legitimate. The second is ego.

When you’ve sorted honestly, you probably have two or three real commitments. Maybe four. That’s the right number. Enough to work on meaningfully, few enough to actually track.

“Be More Strategic” Is Not a Behavior

We cannot change concepts. We can only change specific, observable actions.

“Be more strategic” is a concept. “Send a written summary after every major decision that includes the business rationale and trade-offs” is an action. “Be less emotional” is a concept. “Wait twenty-four hours before responding to any message that triggers a strong reaction” is an action. “Be a better communicator” is a concept. “Open every one-on-one by naming one specific thing the person did well since we last spoke” is an action.

The action version has three properties that matter. You can do it - it’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’t.

I’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.

The failure mode is making this step too conceptual. A development plan that says “I will work on strategic communication in my leadership interactions” is not a plan. It’s an intention dressed up as a plan. The question to keep asking until you can’t subdivide anymore: what will I actually do, when, and how will I know if I did it?

You might be interested in my earlier post about goal setting.

The Step That Changes Everything

This is the part most people skip. It’s also the single most important thing you can do.

Go back to your feedback givers individually. Before you’ve done all the work. Before you’ve accumulated a track record of change. Early, when you’re still in the uncomfortable place of having heard the feedback and not yet having responded to it.

Tell them what you heard. Tell them what you’re committing to change. Tell them where you’d like their help.

That last part matters. Help is not the same as accountability. “Hold me accountable” sounds serious, but it puts the relationship into an evaluative frame. “I’d like your help” is vulnerable. It acknowledges that you can’t do this alone. Almost no one will refuse a genuine ask for help.

What you’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.

This does two things, and the less obvious one matters more.

Obviously, it creates a feedback loop that most change efforts don’t have. You’re no longer trying to self-assess whether you’re improving while simultaneously doing the thing you’re trying to improve. You have real-time input from people who were close enough to the original problem to notice the change.

Less obviously, you’re nudging the other person to pay attention. Not manipulating them - just acknowledging that they’re busy and their brain isn’t running continuous reassessments of your leadership on its own. When someone knows you’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.

This is the mechanism by which genuine change actually becomes visible. It doesn’t happen automatically. It happens because you made it possible for the update to occur.

(I realize this sounds almost embarrassingly obvious when described this way. But I’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.)

The Problem With Motivation

The period immediately after receiving feedback is the worst time to judge your own commitment. I’ve learned this the hard way.

In 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’ve had the uncomfortable conversation. You’ve made a plan. You’re going to do this.

Six 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.

This is not a character flaw. It’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.

Which is why the behavior change work needs a system that functions independently of how motivated you happen to feel on any given week.

There are a few approaches that actually work here. The simplest is self-scoring: at the end of every week, for each commitment you’ve made, just answer yes or no. Did you do what you said you’d do? Not a narrative. Not a reflection. Just a score. The score creates a feedback loop that’s honest in a way that intentions rarely are.

If 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’s cheap. It’s consistent. It has no personal history with you and no interest in protecting your feelings. I’ve used this myself and it surfaces things that I was convinced I had addressed and hadn’t.

The 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’s it. Ten minutes to maintain the loop. Most people won’t even do that.

Oh, by the way, I’ve written about motivation in the past.

What You’re Actually Trying to Do

I want to be direct about the goal here, because I think it often gets obscured by the development language that surrounds 360 feedback.

You are not trying to optimize your survey scores in the next cycle. You are not trying to satisfy HR’s annual process. You are not even, primarily, trying to become a better leader in the abstract.

You are trying to build a better reputation, earned through genuine change, with the specific people who matter to your work.

That sounds mercenary if you say it out loud, so people usually don’t. But it’s the honest description of what’s at stake.

To be clear: I’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’t care why you made it. Your directs don’t need to know you were motivated by a 360 report. The improvement in how you lead them is real regardless.

But caring about reputation isn’t vanity. It’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 2011 HBR piece on 360 surveys - when someone rates your behavior, what they’re actually measuring is their own experience of you relative to themselves, not some objective truth. Your peer who said you’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’s it. Three interactions, out of hundreds, now generalized into a label that will follow you through every future interaction with that person.

This is not a flaw in 360 feedback. It’s how human beings form impressions - quickly, from thin evidence, and then self-confirmingly. Buckingham and Goodall’s Feedback Fallacy piece in HBR 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’t reputation management in the PR sense. It’s asking for a fair assessment based on a fuller data set.

But I’ve watched too many people do real, honest personal development work and then wonder why nothing seems to have shifted in how they’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’t automatically produce the other. Your reputation is not your personality or your intentions - it’s the story other people tell about you when you’re not in the room. 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.

360 feedback, at its best, gives you a rare honest look at what that story currently sounds like. It’s a gift, even when it doesn’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’s where the actual work is.

Most organizations treat the feedback collection as the thing. The collection is nothing. It’s expensive data you paid for and then filed.

The 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.

Everything else is just expensive data you collected.

And those conversations you hoped you’d never have to have again? They don’t go away because you survived one review cycle. They come back, slightly reworded, with the same underlying truth about how you’re showing up.

Until you actually do the second job.

If this resonated, I write about engineering leadership, feedback systems, and the parts of management nobody puts in the job description. New post every week.

Because AI doesn’t have opinions about quality. It doesn’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.

AI is an amplifier. And most engineering leaders haven’t stopped to ask what exactly they’re amplifying.

The Amdahl’s Law Problem

Amdahl’s Law 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’t. It applies just as cleanly here, and I haven’t seen enough people make this argument explicitly.

Good 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’t require deep validation, you give a proportionally bigger speedup to the engineers who weren’t validating anyway.

The gap between good and bad engineering just got wider.

This reframes the whole conversation. The question isn’t whether AI produces good or bad code. It’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’t something AI speeds up at all. It requires the same concentration it always did. Probably more, because there’s simply more code to read.

The bottleneck moved. Most teams haven’t noticed yet.

The Incentive Problem Is Worse Than the Tool Problem

I’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.

I don’t blame them. That’s a rational response to incentives.

If 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’re delivering throughput. The tool is just making the mismatch more visible.

I’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’ve shifted the cognitive load downstream without changing downstream capacity.

That is a leadership problem. Not an AI problem.

Spec Drift

There’s a phenomenon I’ve started calling verification debt, 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’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.

The 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.

AI 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’t.

The DORA research 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’t change what happens when that code is misaligned.

The solution isn’t to use AI less. It’s to treat specification and alignment as first-class engineering work, which most teams still don’t.

The Four Questions You Should Be Asking Your Teams

I want to be concrete, because “strengthen your engineering process” is the kind of advice that sounds good and changes nothing.

When I look at how AI is actually changing the work, four questions separate teams that are getting stronger from those quietly accumulating debt:

1. Who owns the specification? 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’t exist, or nobody reads it, or it hasn’t been touched in months, you are flying blind. AI makes that worse by an order of magnitude.
2. What does your code review actually verify? If the answer is “roughly whether it does what the PR description says,” that’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? Good code review has always required this. AI makes skipping it far more costly.
3. Is validation a gate or a formality? 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’s evidence of a test suite that passes. Those are different things. Charity Majors has written about this more sharply than I can: testing strategy has to be intentional or it’s just confidence theater.
4. Are your engineers slowing down anywhere? 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’re shipping. The engineers who aren’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’re looking.

The Leader’s Job Didn’t Get Simpler

There’s a fantasy version of AI in software engineering where the machines write the code and humans do the “interesting parts.” I find this fantasy genuinely appealing. I also think it fundamentally misunderstands what the interesting parts are.

The interesting parts of software engineering aren’t “above” the code. They’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’t build that model. It generates statistically plausible code based on what similar systems have looked like before.

Your engineers are still the ones who have to build that model. Your job is to create the conditions in which they actually do.

That means resisting the pressure to measure productivity by output volume alone. (I know that’s hard when your own leadership is looking at deployment frequency and feature counts. I’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’re shipping, or whether they’re shepherding code they couldn’t fully explain under pressure.

Will Larson’s framing on sustainable pace 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.

I don’t think those leadership responsibilities changed because of AI. I think AI made the consequences of ignoring them arrive faster.

A Note on the Historical Cycle Argument

The “we’ve seen this before” argument is popular right now, and it’s not wrong. Every decade has had its version of “expertise is no longer necessary”: 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.

That pattern will hold this time too. The interesting question isn’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’re now facing a hairball that nobody really understands?

That’s not a question for your engineers. That’s a question for you.

What I’d Actually Change

If I were designing this from scratch today, three things would be non-negotiable.

1. First: 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’s the forcing function that makes verification possible.
2. Second: code review checklists get updated to explicitly ask about behavioral alignment. Not just “does this work” but “does this still match what we said it should do.” 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.
3. Third: I’d track verification debt the same way I’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’m idealistic about backlogs, but because naming something changes how seriously a team takes it. Invisible debt grows. Named debt gets paid down.

None of this is complicated. None of it is new. It’s the work good engineering has always required. The difference is that without it, AI will surface the gap much, much faster.

Amplifiers are neutral. What you point them at is not.

I 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.

Now I sit in planning sessions where we talk about how many agents we’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.

It’s not that the code is bad, exactly. It’s that I’m not sure anymore.

The Trap Inside the Green Build

There’s a term for what’s accumulating: verification debt. Lars Janssen put it well in a recent post: it’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’t fully understood, they’re borrowing against the future.

What makes this sneaky is that it doesn’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.

And six months later you discover you built exactly what the spec said, and nothing the user actually needed.

I’ve been there without AI. We’ve all shipped something “correct” that was wrong. AI just made it faster and easier to get there at scale.

Everyone’s 50% More Productive, And That’s The Problem

Here’s the math nobody wants to talk about. If AI makes every engineer 50% more productive, you don’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.

When 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’t vanish. It moves upstream, to the parts of the job that are irreducibly human: deciding what to build, defining “done,” understanding the domain, making judgment calls about risk.

I’ve written about this pattern before: the work didn’t disappear, it moved. What’s new here is that it moved specifically into verification - and most teams haven’t consciously staffed or structured for that yet.

As an engineering leader, this is the thing I keep turning over. I’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’re not good proxies for a world where building is cheap.

The question isn’t “how do we produce more code?” anymore. The question is “how do we verify more code?” And I don’t think most teams have a real answer to that yet.

What I’m Actually Watching For

I’ve started framing verification as a first-class engineering skill, not a phase in the process.

The 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?

That last question is the one. “Probably” is not good enough.

(I’ve started asking this in code review discussions and the silence is instructive. Nobody wants to be the one to say “I pressed approve and moved on.”)

The agents won’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.

The Skill Hasn’t Shrunk, It’s Shifted

People keep saying AI is making engineers dumber. I don’t think that’s the right frame.

We stopped memorizing API signatures when search engines appeared. The cognitive load didn’t disappear. It shifted toward synthesis, architecture, judgment. The skill changed, but it didn’t shrink.

What I see with AI is the same pattern, one level up. The skill isn’t “write code.” It’s “understand what the code should do and verify that it does it.” That requires knowing the domain. Reading the diff and actually following the logic. Catching the places where the agent made a confident wrong assumption.

That’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.

Most of my day is asking agents questions and then validating their answers. It sounds efficient. In practice it’s a different kind of exhausting.

What This Means for How You Run Your Team

If you’re managing engineers right now, I’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’re not the thing to watch.

Watch the things that tell you whether the output is right. Review latency. Defect escape rate. Incidents that trace back to “we shipped something that looked fine.” Those will tell you whether your team is accumulating verification debt or actually managing it.

Build review capacity explicitly. Don’t assume it scales with generation capacity. It doesn’t.

And create space for engineers to say “I don’t fully understand what this does.” That admission is worth a lot more than a fast approval.

The agents make output cheap. They don’t make responsibility cheap.

That’s the job now: keeping those two things from drifting too far apart. I have since written about the practical side of this, the schemas, interfaces, and tests you have to hand-roll to recreate the QA that used to come along with typing.

It’s fiction.

I’ve been an Engineering Manager at multiple companies. The role has never been the same twice - not even close. And I’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.

The standard definition is a myth we keep telling ourselves because it makes hiring easier. The reality is messier and more interesting.

The Four Pillars Nobody Told You About

In every context I’ve worked in, the EM role pulls across four areas: Product, Process, People, and Programming. The mistake is assuming they’re balanced equally. They never are.

What changes - radically - is which pillar consumes your week.

Large team? Programming disappears. You’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’s not a failure of time management. That’s the job.

Small team? Suddenly you’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.

No product manager? You’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’ve seen teams work beautifully on the inside while slowly dying on the outside because nobody was checking whether the work mattered.

Reporting directly to the CEO? You’re suddenly the interface to sales, operations, and clients. You’ll spend more time explaining engineering tradeoffs to non-engineers than you ever expected. Your ability to translate is the job.

None of this is surprising in isolation. But somehow we still treat the EM role as if there’s a canonical version of it.

The Real Job Is Bottleneck Detection

Here’s what I’ve come to believe after years of doing this: the Engineering Manager’s primary job is to identify where the team’s bottleneck sits in the software development lifecycle, and fill it.

Not permanently. Not because you’re the most qualified person for it. But because the team’s ability to move forward depends on someone owning that constraint right now.

Sometimes that bottleneck is technical leadership. Sometimes it’s product clarity. Sometimes it’s someone willing to have hard conversations with stakeholders. Sometimes - honestly - it’s someone sitting down and writing the spec nobody else will write.

The pillar you focus on shifts as circumstances change. That’s not role ambiguity. That’s the design.

Will Larson has written about how “good engineering management” 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’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.

What doesn’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.

The Interview Trap

Here’s a mistake I see managers make, especially early in their careers: asking the interviewer “what do you expect from an Engineering Manager here?”

It sounds like a thoughtful question. It isn’t.

Most managers believe their own experience is the industry standard. They’ve been doing the job a certain way for years. If you ask what they expect, you’ll get a description of what they’ve seen - not what the role actually requires in that specific context. The answer will be confident and incomplete.

Ask instead about their daily life. What’s taking up most of their time right now? What problems keep coming back? Where does the team get stuck?

That conversation will tell you more about what the role actually is than any job description or generic answer about “ownership” and “technical leadership.”

You’re not just evaluating fit. You’re doing early bottleneck detection.

The Uncomfortable Part

Accepting that the role is context-defined rather than fixed puts the burden on you.

You can’t just get good at “being an EM” 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’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.

The 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’ve done it. It doesn’t end well.

The role requires flexibility not as a soft skill, but as a core operating principle.

That’s not what the job descriptions say. But it’s what the job is.

The teaching isn’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, as Alan Watts put it, for comfort - instead of looking at where it points.

I keep thinking about this because I keep watching it happen. Not in meditation halls. In engineering organizations.

We Are Very Good at Optimizing the Wrong Thing

Engineers 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.

The 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.

But 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’t be automated.

So we optimize the finger. And after long enough, the finger becomes the point.

I’ve done this. More than once.

The Agile Ceremony That Eats Your Team

I 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’s Jira hygiene was impeccable.

The team was miserable and shipping slowly.

When 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’s sense of purpose was not.

The 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.

This is the most common form of finger-worship I see. It’s particularly hard to spot because the ceremonies look like discipline. From the outside, from a director’s report, from a maturity assessment - everything checks out. The process is healthy. The patient is dying. There’s even a name for it: Agile theater - when teams adopt all the motions of agility while optimizing for ceremonies instead of outcomes.

Ask 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’t remember, you’re probably managing the finger.

OKR Season as Performance Art

I have a complicated relationship with OKRs…

The 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’s pitch is compelling, and I’ve seen OKRs work. Will Larson’s take on goals and baselines captures the real intent well: goals should decouple the “what” from the “how,” not become a bureaucratic layer on top of them.

But inside most engineering organizations, OKR season has become something else. It’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 “super important” project that a senior stakeholder pushes in from the side).

The key results - the finger - consume enormous organizational energy. The actual performance shift that OKRs were supposed to unlock rarely materializes.

I’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.

There’s a version of this that’s even more insidious: teams learn to set key results they know they can hit. 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.

If 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’t actually fix.

The 1:1 That Doesn’t Do Anything

I believe in 1:1s. I run them regularly, I prepare for them, and I think managers who skip them are making a mistake.

That said, I’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.

The 1:1 is a finger pointing at something specific: the growth, wellbeing, and effectiveness of a person on your team. When it’s working, the person leaves the room slightly clearer, slightly more capable, slightly more connected to what matters. When it’s not working, it’s just a recurring calendar event.

The failure mode I’ve noticed most is confusing the conversation with the outcome. 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.

Listening is the finger. The moon is the person actually growing and solving the problem. (And yes, I’ve done this too. The listening feels like the act because listening is where the effort is visible.)

The other version: 1:1s that are entirely about the manager’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.

After your 1:1s, are the people you manage measurably more capable over time? Are they solving problems they couldn’t solve before? Are they more confident in their judgment? If not, the recurring invite is just a recurring invite.

Career Ladders and the Level Theater

Career frameworks are useful. I’ve helped build a few. Done right, they create shared language, reduce subjectivity, and give engineers a map for their own development.

Done wrong, they create a new game to play.

You’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 “cross-team impact” 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 “staff-level initiative” in the framework, regardless of whether that project is the highest-leverage thing they could be doing.

The 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 Goodhart’s Law does the rest: when a measure becomes a target, it ceases to be a good measure.

I’ve managed engineers who were technically underpromoted by their rubric score and doing extraordinary work. I’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 promotion pathologies - the recurring ways that level systems develop a life of their own, disconnected from the actual performance they were meant to reflect.

The fix is not to abandon career frameworks. They’re necessary at scale. The fix is to hold them lightly - to remember that when the level rubric says “leads projects with ambiguity,” the moon is actually “comfortable and effective in ambiguous situations”. Not someone who has learned to narrate ambiguity well in a promo doc.

The Post-Mortem That Closes Itself

Post-mortems might be the clearest example of finger-worship in engineering culture.

The original moon: learn from failures, prevent recurrence, and build psychological safety so people share what went wrong. Google’s SRE book 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.

The finger: a document. A structured template. A meeting with a facilitator. A list of action items assigned with due dates.

The moon disappears very quickly. The finger is what we have meetings about.

I 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.

We are very good at running the process. The process is not working.

Post-mortem culture that actually learns requires something that can’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’t do that. The document is just the finger.

What Mentoring Gets Wrong

This one is personal.

I’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’s actual development.

Good advice is a finger. It points at a capability, a mindset, a way of seeing problems that the mentee doesn’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.

But 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.

The 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.

Real mentoring is less comfortable. It involves sitting with the mentee’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.

I 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.

The Diagnostic

Here is the question I now ask myself when I’m running a process, a ceremony, a framework, or a practice that I believe in:

If this process disappeared tomorrow, what would get worse?

If the answer is “the process would disappear,” you’re worshipping the finger. The finger is its own justification.

If the answer is “the team would lose clarity, rhythm, or growth opportunity,” you’re probably still connected to the moon. The process is doing what it’s supposed to do.

The second question: When did this practice last change something? Not produced something. Changed something. Altered behavior, direction, understanding, or outcomes in a way that mattered to someone outside the room.

If you can’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.

The Harder Problem

Here’s what makes this genuinely difficult: you cannot see the moon without the finger.

The 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.

The finger is how you find the moon in the first place. That’s the whole point of the Buddhist image. Without the pointing, you wouldn’t know where to look.

The 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’t working feels like attacking culture.

But the question isn’t whether the finger is legitimate. The question is whether it’s still pointing at anything.

Ryokan, the Zen poet, wrote something that has stayed with me:

Relying upon a finger, we see the moon. Relying upon the moon, we understand the finger.

(The full poem and context 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.

Most 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’t measure it. Even when the dashboard shows green. Even when the quarterly report looks fine.

Look up from the finger. See where it’s pointing. Go there.

The thing that actually breaks first is you.

The invisible routing layer

At 10 people, a good engineering leader is the connective tissue of the entire org. Not because they’re a control freak (well, some are), but because it’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’t know who owns the auth service: they ask you, and you tell them in thirty seconds.

You are the context routing layer. 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’s fast, and it produces consistent decisions because one brain is making most of them.

The problem is that the team has no idea this is happening. To them, things just… work. Decisions get made. Context flows. Problems resolve.

They think the org is functional. It’s not. It’s you.

When the routing layer saturates

I 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.

What I hadn’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’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.

The org felt slow. Decisions felt inconsistent. I kept getting pulled into things I thought I’d delegated. I blamed the leads at first. (I was wrong. And yes, I’ve done that too.)

What 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.

What you were doing unconsciously

It’s worth being specific, because the fix depends on naming it accurately.

Tanya Reilly’s “Being Glue” 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’s high-impact. And it’s almost entirely invisible on a good day.

When you were the routing layer, you were doing at least four things that now need explicit structure:

Decision logging. 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.

Synchronizing assumptions. 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.

Absorbing ambiguity. 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.

Social cohesion. You knew everyone. You knew who was frustrated, who was thriving, who needed more challenge. You maintained the team’s social fabric without anyone calling it that. (This one is the last to break, and the hardest to rebuild once it does.)

The wrong fix and the right one

The standard advice at this point is: document everything. Write it down. Build a Notion wiki. That advice isn’t wrong, but it’s treating a symptom while the disease progresses.

Documentation without ownership decays into archaeology within months. I’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’s head. You haven’t solved the routing problem - you’ve just created a fake routing system that gives everyone false confidence.

The real fix is to externalize the four functions above into lightweight, maintained systems - and then get out of the way enough that those systems actually get used.

Will Larson has a useful frame for this he calls “Model, Document and Share”: 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’s head and make it reproducible.

Some of what that looks like in practice:

• Decision logs 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.
• Team leads who are explicitly responsible for assumption synchronization between their team and adjacent teams - not because it’s on a job description, but because you’ve talked about why it matters and they’ve internalized it.
• A lightweight escalation habit: when something is ambiguous, the right move is to write down the ambiguity and make it visible, not resolve it silently and move on.

None of this is novel. What’s novel is understanding why you’re doing it: not because scale requires process, but because you were doing all of this yourself and it needs a new home.

The thing worth naming to your team

Here’s what I’ve started doing that I wish I’d done earlier: telling teams explicitly what used to happen and what needs to happen now.

Not as a lecture, just as a fact. Something like: “When we were smaller, I held a lot of context that let us move fast without much coordination overhead. We’re past the point where that scales. Here’s what I need from each of you to replace it.”

Most engineers find this clarifying rather than alarming. They suspected something was off. They just didn’t have the frame.

What they didn’t know - and what most managers never say out loud - is that the org’s apparent smoothness was load-bearing on one person. Once you name it, you can share the weight.

The HN thread will keep producing answers about documentation and communication bandwidth and Dunbar’s number. Those aren’t wrong.

But if you’re an EM watching things crack as your team grows, start by asking a harder question: what was I doing that nobody else knew I was doing?

The answer is usually longer than you expect.

The Cone of Uncertainty, Fibonacci scale, and Cynefin walk into a sprint planning session…

A product manager walked into a refinement session a few years back, dropped a one-pager on the table, and said: “How long will this take?” 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.

I stopped the session. I told her we couldn’t answer that question yet - not because we were hiding something, but because the honest answer was “somewhere between three weeks and five months, and I’m not joking.” 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.

That’s the conversation most engineering teams never have. And it’s the conversation the #NoEstimates movement, for all its righteous frustration, accidentally makes harder to have.

The Problem #NoEstimates Actually Solved

I want to be fair here. The people who built the #NoEstimates movement weren’t being irresponsible. They were reacting to something real and genuinely damaging: the industrial-scale misuse of estimates as performance targets.

The 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’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 “missing” 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’t know it yet.

That pathology is real. I’ve lived it. The frustration is valid.

But the solution - don’t estimate - is like responding to a broken thermometer by deciding temperature doesn’t exist. The thermometer was the problem. Not the concept of heat.

What often gets lost in that frustration: your estimate doesn’t change the actual work. Maarten Dalmijn puts it well in his writing 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. Delivering a feature takes as long as it takes. What the estimate influences is not the work itself but the expectations around it - and managing those expectations, honestly and clearly, is very much worth doing (and it’s part of the job).

Why Organizations Actually Need Estimates

Here is the thing that the #NoEstimates literature almost always sidesteps: estimates are not primarily for the team doing the work. They are for the organization around the team.

Three specific situations make estimation non-negotiable for anyone operating inside a larger organization.

External commitments. 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’s feasible. That call requires some model of how long things take. “We don’t estimate” is not an answer a business can give a customer. It’s a sentence that ends contracts.

Inter-team dependencies. 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’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 (“probably six weeks, could be eight”) is infinitely more useful than silence. This is not about control. It’s about respect for the humans downstream of you.

ROI calculations. 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’re just guessing. And if you’re going to guess anyway, you might as well make it a structured guess with explicit assumptions attached.

None of these needs require precise estimates. They require useful ones. That distinction is everything.

What Joseph Pelrine Showed Us About Why This Is Hard

Joseph Pelrine is Europe’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 this talk, he describes a fascinating exercise he ran with over 300 people working in Agile software development. Using the Cynefin framework - Dave Snowden’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.

The Cynefin framework

Task estimation, consistently and repeatedly, landed in the Complex domain.

Not Complicated. Complex.

This distinction matters enormously. In the Complicated domain, cause and effect are knowable - you might need an expert to trace the relationship, but it’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.

In the Complex domain, cause and effect are only knowable in retrospect. The system is too entangled, too context-dependent, too sensitive to small changes. You don’t analyze and then act. You probe, observe what happens, and respond. Your knowledge is inherently local and temporary.

Task 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’t work: cabinets are roughly like other cabinets. Features are not roughly like other features.

What Pelrine’s work tells us is not “don’t estimate.” It tells us: you are applying an ordered-domain tool to an unordered-domain problem. The answer is not to throw away the tool. It’s to use it with the appropriate epistemic humility - and to stop pretending the output is a commitment.

This also reframes an honest truth that most estimation advice dances around. Even great teams only produce mediocre estimates. Not because they’re not skilled, but because there’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.

The Cone Doesn’t Lie, But You’re Ignoring What It’s Saying

Steve McConnell’s Cone of Uncertainty is one of those concepts that everyone nods at and almost no one actually applies.

The 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’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’re close to done, your estimates are nearly exact. (You also, at that point, no longer need them.)

That last part is the irony: estimates become more reliable closer to completion, which is also when they’re least useful. Early on, when you’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.

Two more things are worth sitting with.

• First: the cone represents the best case for skilled estimators. It is not describing average teams with average practices. It’s describing what’s possible when you’re actually good at this. Most teams do worse. If your team commits to a date at the initial concept stage, you are not making a plan. You are making a wish - and then arranging your calendar around it.
• Second: the cone narrows only when you make decisions that eliminate variability. Time alone does not narrow it. Defining scope narrows it. Resolving architectural unknowns narrows it. Actually writing code and discovering what’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.

The practical consequence is something I’ve started saying long ago explicitly to stakeholders: the quality of our estimate depends on how far we are in the cone. I won’t give you a two-week number in week one. I will give you a range, and I’ll tell you what has to be true for us to narrow it.

Most stakeholders, when you explain the cone to them, accept this. They’re not asking for false precision because they enjoy it. They’re asking because nobody ever told them they were allowed to ask for a range.

Why Fibonacci and Not Hours

When 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.

The non-linearity is doing epistemic work.

When you estimate something as a 2 versus a 3, you’re saying: “I have a rough sense of the difference, but it’s marginal.” When you jump from 8 to 13, you’re encoding something much more important: the uncertainty band around this estimate is wider than the estimate itself. A 13-point story doesn’t mean “I know exactly how big this is, and it’s 13.” It means “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’t ask me to be more precise than that.”

The 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: “This story should probably be split, because an estimate of 21 is essentially us saying we don’t understand the work yet.”

The other underappreciated function of Fibonacci estimation is what happens during 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’t in the ticket.

That conversation - the one forced by disagreement - is often where the real work of refinement happens.

The biggest value in estimating isn’t the estimate. It’s checking whether there is a common understanding. The number is almost a side effect. Remove the forcing function, and that shared understanding often doesn’t form until someone is three days into a task and hits the hidden complexity.

This is why I find the #NoEstimates argument that “estimation meetings are waste” 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.

The Commitment Trap (And How to Avoid It)

The deepest dysfunction the #NoEstimates movement was responding to is this: estimates become commitments through social pressure, not logic. 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.

There’s a related failure mode that’s just as damaging, and it’s about who creates the estimate. When people who aren’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 and 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’s a blame-game waiting to happen.

When 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 “how do we hit the deadline?” The question of whether you’re building the right thing - whether the work is actually good - slides quietly out of view. The deadline wasn’t wrong because the estimate was imprecise. It was wrong because the estimate became the mission.

The way I’ve navigated this is by separating three things (and working with my stakeholders to have agreement on this) that most organizations conflate:

1. An estimate 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. “We think this is 4-6 weeks, assuming requirements don’t change and we get answers on the API question by next Friday.”
2. A plan is a commitment to a process, not an outcome. “We will work for two weeks, review progress, and give you an updated forecast.” Plans are things you can keep. Estimates are things you can only be more or less accurate about.
3. A commitment 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’s reckless. When somebody forces you to commit to something, try only committing to priorities, not timelines. If that doesn’t work, make the level of confidence part of the commitment.

The dysfunction happens when organizations treat estimates as commitments from the moment they’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.

The 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’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.

What Good Estimation Practice Actually Looks Like

I won’t pretend I have a perfect system. I don’t. But across the teams I’ve managed, a few patterns have consistently made estimation more honest and more useful.

Estimate late, not early. The cone narrows only through learning. Do spikes. Write some exploratory code. Talk to the teams whose systems you’ll integrate with. Work with what you do know to discover what you don’t know. Resist the pressure to give numbers before you’ve done the learning that would make them meaningful.

Don’t over-decompose before starting. This one is counterintuitive, and I’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’t - and the time spent in those sessions is time you’re not spending learning from actual work. There’s a real cost here that’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.

Give ranges, not points. “Three to five weeks” is more honest than “four weeks” 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’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’re communicating estimates.

Make your assumptions visible. 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’s team delivers something by a certain date, say so. Assumptions that live in your head become misunderstandings that surface at the worst moment.

Track accuracy over time - without punishment. 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’re a property of the domain.

Split anything over 8. A story that’s a 13 or a 21 on the Fibonacci scale is almost always a story that contains hidden complexity you haven’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.

The Uncomfortable Truth for Both Camps

Here’s what I think is actually true, and I’ve found it unpopular in equal measure with both estimation enthusiasts and #NoEstimates advocates.

Estimates 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.

There’s a trap worth naming here - what Dalmijn calls the Complex Work Estimation Fallacy: the belief that by estimating more often, refining the process, and working together longer, a team will eventually produce accurate estimates. It won’t. The ceiling on estimation accuracy in a Complex domain is not a function of team maturity. It’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.

Refusing to estimate doesn’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’ve been on one. It was a specific organizational context that most of us will not be in for most of our careers.

For everyone else, the choice is not between “bad estimates” and “no estimates.” The choice is between unconscious, low-quality estimates (which your organization will make anyway, with or without you) and explicit, humble, range-based, assumption-visible estimates that give the people around you something real to work with.

Joseph Pelrine was right that task estimation lives in the Complex domain. That’s exactly why we need to approach it with a complexity mindset: probe, observe, respond. Estimate, track, calibrate. Do it again. The cone doesn’t narrow by waiting. It narrows by learning.

Stop trying to get out of estimating. Start getting better at it - and clear-eyed about how good “better” can actually get.

Then the same symptoms came back. Just upstream now.

It took me longer than I’d like to admit to realize I was solving the wrong problem. The real constraint wasn’t on anyone’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.

I was the constraint. And I was the last person to see it.

This post is about the Theory of Constraints and why most engineering teams apply it too shallowly. If you manage a team or run an engineering organization, you’ve almost certainly read about TOC at the five-steps level. You’ve heard about identifying your bottleneck, exploiting it, and subordinating everything else.

What 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: policy constraints and the leadership behaviors that produce them.

What TOC actually says, briefly

Eliyahu Goldratt introduced the Theory of Constraints in 1984 through a novel called The Goal. 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’t that constraint produces no real improvement in overall output.

The five focusing steps 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.

I’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 types of constraints, because this is where most engineering teams stop reading too early.

Goldratt distinguished between physical constraints, resource constraints, and policy constraints. 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’re written or unwritten rules, explicit or implicit, that prevent the system from achieving higher performance. They don’t show up as a queue building somewhere. They show up as decisions that can’t get made, work that can’t start, and autonomy that never quite materializes.

Policy constraints are almost always the hardest to identify and the most common in mature engineering organizations. They’re also almost always created, sustained, and invisible to leadership.

The visible bottleneck is not the real problem

Here’s a pattern I’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.

They 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.

The 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’t available on the team’s timescale. Fixing code review speeds up work flowing into the constraint. It does nothing to the constraint itself.

Goldratt’s point was precise: any improvement made anywhere besides the constraint is an illusion. Not a small win, not progress with caveats. An illusion. That’s a strong claim and it’s worth sitting with.

I’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’s causing the queue? Sometimes it’s QA capacity. Often it’s that tickets arrive without adequate acceptance criteria because the product process is broken. Sometimes it’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.

These causes don’t appear on your Jira board. They require a different kind of investigation.

How to actually find policy constraints

The technique I find most useful is what I think of as the “why can’t we just” test. Walk through your delivery process and ask that question at every point of friction.

Why can’t we just deploy when the feature is ready? “We need a release window sign-off.” Why does that sign-off exist? “Because a VP wants visibility before anything goes to production.” Why does that VP want visibility at that point rather than earlier? “Because there was an incident three years ago and they added the step.”

That’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.

The questions to ask systematically:

• Where do teams wait for a decision from someone not on the team?
• Where does work require approval from someone unavailable during normal working hours?
• What cannot happen without a specific person’s involvement, not because of expertise, but because of authority?
• What process exists because of a past incident, and has anyone evaluated whether it still makes sense?
• What would the team do differently if the leader weren’t watching?

That 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’t trust them. The workarounds are the signal.

The leader as constraint

I want to be direct here, because most writing on this topic stays diplomatic.

Senior engineering leaders are among the most common constraints in their own organizations. Not because they’re bad leaders. Not because they don’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.

The 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 “quick sync before we finalize this” that saved a project once is now a recurring tax on every decision.

(I’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.)

The 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.

The test is simple: if you were unavailable for two weeks, what would stop?

Not 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’d like but continue, is subordination you’ve imposed on the system unnecessarily.

Why subordination is politically hard

Goldratt’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’s maximum throughput, even if that means deliberately operating some resources below full capacity.

In practice, this is deeply uncomfortable.

It means telling a high-performing team to slow their output because feeding work faster into the constraint doesn’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.

Most 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.

I’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 “only” 60% utilized but consistently unblocking the constraint is contributing more than a team running at 100% on work that queues behind a bottleneck they’re not helping to fix.

That’s a hard sell. It requires trust. It requires people to believe you’re measuring what matters rather than what’s easy. And it requires that the constraint actually gets fixed, not just identified and left.

Identifying your real constraint: a practical approach

I want to give you something concrete you can do after reading this.

Map your value stream. 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.

Then 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.

Then run the “why can’t we just” 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’ll find that the policy constraints cluster around the middle of the process, around the points where decisions cross team or organizational boundaries.

Finally, and this is the uncomfortable part: ask someone junior to do this analysis for you. Engineers two or three levels below you see the constraint with perfect clarity. They’ve been adapting to it for months. They’ve built workarounds. They have opinions about exactly what would change if leadership removed itself from the critical path. They often won’t volunteer this information unprompted because doing so feels presumptuous or unsafe.

Ask directly. Create conditions where the honest answer is welcome. The information is already in your organization. It’s just waiting for permission to surface.

What actually changes when you fix a policy constraint

When 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.

The 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’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.

The second-order effect was the one I hadn’t anticipated: teams started surfacing problems earlier. When the path from “I see an issue” to “we can address it” is short and doesn’t require escalation, people bring things up when they’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’re more expensive to fix.

Goldratt described this dynamic as the constraint suppressing information about the system’s actual state. When you remove a policy constraint, you don’t just increase throughput. You improve the quality of your organizational signal. You find out earlier what’s actually happening.

The constraint will move. Be ready.

One 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.

When 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’s architectural decision quality drops because they’ve been operating inside tight guardrails for so long that the muscle for independent judgment hasn’t developed. These are real and solvable problems, and they’re much better problems to have than a permanent constraint baked into leadership behavior.

The 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.

I 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?

This is the practice that makes TOC useful rather than just interesting as a framework.

On not confusing busyness with throughput

There’s a deeper idea underneath all of this that I want to name explicitly, because it affects how engineering leaders think about their job.

Most 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 enabling rather than doing, but it doesn’t always give us a clear signal for when we’re succeeding.

TOC 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’s stagnant despite local improvements, you have a constraint you haven’t found yet.

The most important question an engineering leader can ask isn’t “Is the team busy?” It’s “Is value flowing?”

TOC even offers a concrete accounting lens for this: throughput accounting, which shifts focus from cost-cutting to measuring how fast value moves through the whole system. It’s a different way of evaluating decisions, and it reframes what “good” looks like for a leader.

Those 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’s an exhausting and demoralizing place to work, even if the sprint burndown looks healthy.

When I’ve been most effective as a leader, it wasn’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.

Start here

If you want to apply this, start with one question this week.

Pick 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.

If it reaches a person: is that a capacity problem, or is that person a decision chokepoint? If the latter, that’s a policy constraint.

If it reaches a process: who created the process, and does it still solve the problem it was created to solve?

If it reaches a rule: where is the rule written down, and when was it last revisited?

The answer is already in your organization. You don’t need a consultant, a new tool, or a workshop. You need to ask honestly and then be willing to hear what comes back.

The constraint you’re looking for probably isn’t on any board. But the people on your team know exactly where it is. They’ve been working around it for months.

Go ask them.

They think they need to coach more. They’ve read the books, attended the workshops, internalized the message that great managers ask questions instead of giving answers. They’ve been told, repeatedly, by people they respect, that their job is to “unlock potential” and “empower their teams.” If someone on their team is struggling, the prescription is always the same: ask better questions. Be curious. Hold space. Coach.

I 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.

This is a post for engineering managers, new and experienced, who have a nagging feeling that something about the coaching-first orthodoxy doesn’t quite fit. Who have sat in a 1:1, asked a string of open-ended questions, and watched their report’s face go from hopeful to frustrated. Who suspect that sometimes, the most helpful thing they could do is just say the thing.

How we got here

The coaching-first movement in management isn’t wrong. It emerged from a real problem.

For 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 “do it this way” without understanding the constraints. Or worse, the manager had been promoted out of their technical depth and was directing work they couldn’t actually evaluate.

The coaching model was a corrective to this. And it’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’t have learned if you’d just started talking.

I 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 “what have you tried?” 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.

But here’s what I’ve also learned: the coaching model has become so dominant that questioning it feels almost heretical. It’s the water we swim in. Every management book, every leadership course, every conference talk reinforces the same message. Coach, don’t tell. Ask, don’t direct. Empower, don’t decide.

And when something becomes orthodoxy, people stop thinking about when it doesn’t apply.

The three failure modes

I’ve seen coaching go wrong in three distinct ways. Each one is common enough that I’d bet most engineering managers reading this have done at least one of them in the past month.

Failure mode 1: Coaching when someone needs an answer.

An engineer comes to you and asks: “Should I use approach A or approach B for this migration?” They’ve thought about it. They have context. They’re not stuck because they lack critical thinking skills. They’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.

And instead of answering, you say: “Well, what do you think? What are the tradeoffs of each approach?”

I’ve done this. It feels like good management. It feels like you’re developing their decision-making skills. But from the other side of the table, it often feels like something else entirely: Why won’t my manager just tell me what they think?

There’s a particular look people get when they’re being coached and they didn’t want to be coached. It’s subtle. A slight deflation, a beat of silence before they gamely try to answer your question. I’ve learned to watch for it. It means I’ve misread the situation.

Sometimes 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’t coaching. It’s withholding.

Failure mode 2: Coaching as avoidance.

This one is harder to see in yourself, because it feels so much like doing the right thing.

An engineer on your team is underperforming. Their code quality has dropped. They’re missing commitments. Other team members are starting to notice and compensate. You know you need to address it.

So you set up a 1:1. And you open with: “How do you feel things are going?” You ask about their goals. You ask what obstacles they’re facing. You ask what support they need from you. You’re coaching.

Except what you’re actually doing is hoping they’ll say the hard thing so you don’t have to.

I’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’t meeting the bar.

The engineer in that conversation often knows something is wrong, but they don’t know how wrong, because you haven’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.

Which one is actually more respectful?

Failure mode 3: Coaching as status performance.

This is the subtlest one. It’s when managers adopt coaching behaviors because it signals a particular kind of leadership identity (thoughtful, empowering, modern) rather than because it’s what the situation calls for.

I’ve sat in skip-levels where an engineering manager spent 45 minutes asking me Socratic questions about a problem I’d already solved. They weren’t trying to help me think. They were performing the role of “leader who coaches.” The questions weren’t curious. They were procedural. They were going through the motions of a coaching framework they’d learned somewhere.

The tell is this: if your questions have predetermined right answers, you’re not coaching. You’re giving a quiz.

Your manager is not your coach

Here’s the thing nobody in the coaching literature wants to talk about: the relationship between a manager and their report is not a coaching relationship. It has a fundamental asymmetry that no amount of psychological safety can erase.

Your 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’s what makes coaching work. You can be fully honest with a coach because there are no consequences to vulnerability. You can say “I have no idea what I’m doing” to a coach. Saying that to your manager carries risk, no matter how good your manager is.

I’m not saying managers shouldn’t use coaching techniques. They absolutely should. The question-asking, the active listening, the “keep the thought bubble over their head” approach: these are valuable skills. But we should be honest about what we’re doing. When a manager coaches a report, it’s management that borrows from coaching. It’s not coaching.

The distinction matters because when managers fully inhabit the “coach” identity, they sometimes abdicate the parts of management that coaching doesn’t cover. A coach doesn’t need to give you a performance rating. A coach doesn’t need to make a decision about headcount. A coach doesn’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.

Some of the worst managers I’ve worked with were the most “coach-like.” 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.

When managing is the generous act

There’s a framing I keep coming back to: sometimes the most generous thing you can do is be direct.

I had a report once, a senior engineer, smart, capable, who was agonizing over whether to accept a tech lead role. They’d been going back and forth for weeks. In our 1:1s, I’d been coaching: asking about their fears, exploring what they wanted from their career, helping them think through the tradeoffs.

After the third conversation that covered the same ground, I stopped and said: “I think you should take it. You’re ready. The reason you’re hesitating isn’t that you don’t know the answer. It’s that the answer is scary. But you’re going to be good at this.”

They took the role. Months later, they told me that conversation was the most helpful one we’d ever had. Not the coaching. The moment I dropped the questions and just told them what I saw.

I think about this a lot. Coaching assumes that the person has the answer inside them and just needs help finding it. That’s often true. But sometimes people don’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 “yes, this is the right call.”

Coaching helps people find their own path. Managing sometimes means pointing at the path and saying “that one, go.”

Neither is inherently better. The skill is reading which one the moment requires.

Engineers are not generic employees

Most 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’t account for the specific culture and communication norms of engineering teams.

In my experience, engineers tend to value a few things that the coaching orthodoxy sometimes conflicts with:

Directness. Most engineers I’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 “what do you think?” an engineer will often answer, then immediately follow up with “but what do you think?” They want the exchange, not the facilitation.

Speed. Engineering work often has genuine time pressure. When there’s an incident, when a deadline is real, when a decision is blocking three other teams: that’s not the moment for coaching. That’s the moment for clarity. “Here’s what we’re doing. Here’s why. Let’s go.” You can debrief and coach after.

Technical respect. Engineers notice when you ask questions you could answer yourself. If you know the answer to a technical question and you withhold it to “let them discover it,” many engineers will read that as condescension, not empowerment. They’d rather you share what you know and have a real discussion about the tradeoffs.

Honesty about uncertainty. I’ve found that engineers respond well to “I don’t know, let’s figure it out together,” which is neither coaching nor directing, but collaborating. The coaching model doesn’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.

None of this means coaching doesn’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.

A framework for reading the room

So how do you know when to coach and when to manage? I don’t have a perfect model, but I’ve developed some heuristics over the years.

Coach when:

• The person has the skills and context to solve the problem, but hasn’t connected the dots yet
• The goal is long-term development, not immediate output
• There’s genuine room for multiple good answers, and you want them to develop judgment
• The person is explicitly asking for help thinking through something (not asking for an answer)
• You honestly don’t know the best answer and believe they’re closer to it than you are

Direct when:

• The person is missing context or information that you have
• There’s time pressure and a decision needs to happen now
• The person has been going in circles and needs someone to break the loop
• You’re addressing a performance issue. Be clear, be specific, be kind, but be direct
• The person is new and needs orientation, not exploration
• There is a genuinely right answer and you know what it is

Collaborate when:

• Neither of you has the full picture
• The problem is genuinely novel and requires real-time thinking together
• You want to model how you reason through hard problems
• The person is senior enough that the manager-report dynamic matters less than the “two smart people working on a hard problem” dynamic

The mistake most managers make isn’t being in the wrong mode. It’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.

The coaching question you should ask yourself

If I had to distill this into one piece of advice, it would be this: before you coach, ask yourself why you’re coaching.

Is 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?

If it’s the former, great. Coach away.

If it’s the latter, if you’re reaching for questions because making a statement feels risky, because you’re not sure of your own opinion and coaching lets you hide that, because directing feels “old school” and you’d rather be the cool, empowering manager: then you owe your report more than that.

I’ve been that manager. I’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’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.

The best managers I’ve worked for, the ones I learned the most from, weren’t the ones who coached me. They were the ones who saw me clearly and responded to what I actually needed. Sometimes that was a question. Sometimes it was an answer. Sometimes it was “I disagree, and here’s why.” Sometimes it was “I trust you, go do it.”

They weren’t performing a management style. They were paying attention.

Managing is not a dirty word

I think we’ve accidentally created a culture, especially in tech, where “managing” has become a slightly pejorative term. It implies control, bureaucracy, micromanagement. “Coaching” and “leading” are the aspirational words. Nobody puts “I’m a great manager” on their LinkedIn bio. They say “servant leader” or “people-first leader” or “I grow teams.”

But 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.

The best engineering managers I’ve known weren’t the best coaches or the best directors. They were the most situationally aware. 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.

If you take one thing from this post, let it be this: your job isn’t to coach. Your job isn’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.

Pay attention to the person in front of you. Respond to what they need, not to what your management philosophy prescribes. That’s the whole thing.

Who this is for: Engineering managers, team leads, and founders who feel their team is either drowning in firefights or suffocating under process. What you’ll get: A framework for diagnosing which failure mode you’re in, and the smallest possible interventions to fix it.

Imagine two teams. The first: six brilliant engineers, who shipped almost nothing for an entire semester.

They weren’t lazy. They weren’t distracted. They had a roadmap, a project tracker, a weekly planning ceremony, a biweekly retrospective, a definition of done, a review checklist, and a sign-off chain that required three approvals before anything touched production.

They had so much process that the process itself had become the work.

Now, imagine another team. Roughly the same size, roughly the same caliber; was shipping constantly but breaking things just as fast. No documentation. No onboarding guide. The senior engineer who’d built the core system held everything in his head, and when he went on paternity leave, two junior devs stared at his code like archaeologists trying to decipher a dead language.

Two teams. Two opposite problems. And both would tell you, with total sincerity, that they needed “better process.”

They are both right. They are both wrong.

Here’s the thing I’ve come to believe after fifteen years of building and leading engineering teams: the problem is almost never “too much process” or “too little process.”

The problem is that most teams have no idea where they actually sit on the spectrum, with no vocabulary for talking about it.

So let me give you one.

The Question Underneath the Question

When someone says “we need better process,” what are they actually saying?

Sometimes they mean: I’m exhausted from putting out fires, and I want things to be more predictable.

Sometimes they mean: I’m frustrated that I can’t get anything done because there are too many gates between me and shipping.

And sometimes (more often than you’d think) they mean: I don’t trust the people around me to make good decisions, so I want rules that constrain them.

That last one is worth sitting with for a second.

A lot of process gets created not because it solves a real problem, but because someone experienced a bad outcome once and decided the way to prevent it from happening again was to add a checkpoint. A review. An approval. A meeting. A form.

And each individual checkpoint feels reasonable. Each one, on its own, is defensible. But they accumulate. They compound. And eventually you wake up one morning and your team is spending more time talking about work than doing work, and nobody can point to the moment it went wrong because it happened one sensible-sounding decision at a time.

Two Axes, Four Worlds

Picture a two-by-two grid. (I know, I know. Stay with me.)

The horizontal axis is Standardization. This is the degree to which your team has documented, repeatable, automated ways of doing things. Templates, runbooks, CI/CD pipelines, decision criteria, onboarding checklists. The plumbing that lets knowledge compound instead of evaporate.

The vertical axis is Judgment. This is the degree to which people on your team can think critically, adapt to novel situations, make good calls under uncertainty, and exercise real ownership over outcomes. It’s the human layer, the part that no process can replace.

Now look at the four quadrants these axes create:

Top right: Optimal Scaling. High judgment and just enough standardization. People think for themselves but don’t reinvent wheels. Processes exist to capture and share learning, not to control behavior. This is where you want to live. Scaling (growing) is encoded into the mindset and the culture.

Top left: Chaos. High judgment but almost no coordination. Everyone’s smart, and everyone’s going in a different direction. Knowledge is tribal. Success depends on heroes showing up. Nothing compounds. Your team might be individually excellent, but collectively mediocre at best.

Bottom right: Bureaucracy. Lots of standardization, but people have stopped thinking. “That’s not how we do it here” is the most common sentence you hear. Innovation dies not from rejection, but from delay and from a thousand cuts of processes/gates. Your best people are either frustrated or already interviewing somewhere else.

Bottom left: Dysfunction. No process and no judgment. I won’t spend much time here because no team survives in this quadrant for long. If you’re here, you have bigger problems than this post can solve.

The insight that took me years to realize is this: most teams (and organizations!) oscillate between Chaos and Bureaucracy. They swing back and forth like a pendulum, overcorrecting each time.

They start in Chaos: scrappy, fast, unstructured. Something breaks badly. So they add process. A lot of process. They swing into Bureaucracy. Things slow to a crawl. Someone (usually a new leader) comes in and “cuts the red tape.” They swing back to Chaos.

And so on. Forever. Unless you learn to find the edge.

How to Know You’re in Chaos

Here’s the thing about Chaos: it feels exciting. For a while. It feels like velocity. People are moving fast, making decisions, shipping things. There’s an energy to it that’s genuinely intoxicating, especially if you came from a bureaucratic environment.

But there are tells. And if you’re honest with yourself, you already recognize them:

• Fire drills are your operating rhythm, not an exception. You’re constantly reacting. Every week has at least one “drop everything” moment that wasn’t on anyone’s calendar.
• New hires take forever to become productive. Not because they’re slow, but because there’s nothing written down. They learn by osmosis, by watching, by asking the right person the right question at the right time. Which means they’re learning randomly, not systematically.
• You’re solving the same problems on repeat. Someone figured out the best way to handle X six months ago. But they didn’t document it, or the document lives in a Notion page nobody knows about, so someone else is figuring it out from scratch right now.
• The team has heroes, and the heroes are exhausted. There are two or three people who hold everything together. If any of them get sick, go on vacation, or (heaven forbid) quit, whole systems of knowledge walk out the door with them.
• Quality is wildly inconsistent. Some things are beautiful. Some things are held together with duct tape and good intentions. There’s no baseline, just individual standards.
• You can’t take a week off without everything catching fire. This is the acid test. If your absence causes visible disruption, your team is running on you, not on systems. That’s not leadership. That’s a single point of failure.

What’s actually happening underneath all of this is deceptively simple: individual excellence isn’t translating into team performance. You have talented people burning energy on delivery that should be going toward building systems. They’re doing the work and reinventing the infrastructure to do the work, every single time.

I ran a team like this for almost two years early in my career. I was proud of how fast we moved. I bragged about our lack of process. “We’re not bureaucrats,” I’d say. “We just ship.”

What I didn’t see (what I couldn’t see, because I was one of the heroes keeping the whole thing afloat) was how fragile it all was. The moment I got pulled onto a different project for three weeks, two major things broke that never should have broken, because the only reason they hadn’t broken before was that I was personally checking them every day.

That’s when I started to understand: speed without systems isn’t velocity. It’s just motion. It barely works, and definitely won’t scale.

How to Know You’re in Bureaucracy

Bureaucracy is sneakier than Chaos. Chaos announces itself with alarms and fire drills. Bureaucracy creeps in quietly, one reasonable-sounding rule at a time, until one day you realize your team is moving at half speed and nobody can explain exactly why.

The indicators:

• Decisions that should take hours take weeks. Not because the decisions are complex, but because they need to pass through three layers of review and two approval chains. The actual decision-maker has been abstracted away behind a process.
• People ask permission for things they clearly own. An engineer wants to refactor a module they built and maintain. They open a ticket, request a review, wait for approval. Why? Because “that’s the process.” The process has become a proxy for trust — and the implicit message is: we don’t trust you.
• “We’ve always done it this way” is a conversation ender. It shouldn’t be. It should be a conversation starter. If the best justification for a process is its own existence, that’s not a reason. It’s inertia.
• New ideas die from delay, not from deliberate rejection. Nobody says “no.” They say “let’s put it through the review cycle.” And then the review cycle takes eight weeks, and by the time it comes out the other end, the moment has passed, the energy is gone, and the person who proposed it has learned that proposing things isn’t worth the effort.
• Your best performers are visibly frustrated or already gone. High-judgment people have options. When they feel micromanaged or constrained by processes that don’t serve them, they leave. And what you’re left with is a team of people who are comfortable being told what to do. Which means you need even more process to compensate for the judgment you’ve lost. It’s a vicious cycle.
• More time goes to reviews and checks than to actual work. If your team spends more hours per week in approval meetings, code review queues, and documentation reviews than in building, designing, or solving problems, you’ve optimized for control, not for outcomes.

I have a friend who works at a company where deploying a single configuration change required approval from three people across different teams. The change itself took four minutes. The approval process took eleven days. When she asked why, the answer was, “Two years ago, a bad config change caused an outage.” So they built a process to prevent that specific failure from ever happening again. And it worked: that specific failure never recurred. But the cost of preventing it was that every config change, no matter how trivial, now took eleven days. The cure was worse than the disease, but nobody had ever done the math.

Here’s the uncomfortable truth about bureaucracy: it’s often created by well-intentioned people who are trying to prevent real problems. That’s what makes it so challenging to fight. Every rule has a story. Every approval chain has an origin. And telling someone “this process is slowing us down” feels like telling them “that thing you’re worried about doesn’t matter.”

But that’s not what you’re saying. What you’re saying is: “The cost of this prevention has exceeded the cost of the original risk, and we need to recalibrate.”

The Edge: Where Scaling Actually Happens

The edge between Chaos and Bureaucracy is narrow, and it’s not a place you arrive at and stay forever. It’s more like balancing on a surfboard: you’re constantly making small adjustments, leaning one way and then the other, reading the wave.

What does it look like when a team is on the edge?

Clear outcomes, flexible methods. People know what they’re trying to achieve and why, but they have real latitude in how they get there. The goal is specified. The path is not.

Processes that make good decisions easier. A decision framework isn’t an approval gate. It’s a tool. It says: “Here are the criteria that tend to lead to good outcomes in this kind of situation. Use them if they help. Discard them if they don’t.” The difference between a guardrail and a cage is that a guardrail still lets you steer.

People are empowered to edit and delete, not just add. This is one of the most underappreciated indicators of a healthy team. Anyone can create a process. The question is: can anyone remove one? If adding a rule requires a Slack message but removing one requires a committee review, your process is going to grow like weed.

Principles instead of policies. “We deploy with confidence” is a principle. “All deployments require sign-off from a senior engineer, a QA lead, and the team manager” is a policy. Principles scale. Policies calcify. Principles require judgment. Policies replace it.

Automation that frees people to think, not automation that replaces thinking. The best automation handles the mechanical parts: running tests, checking formatting, deploying to staging, and sending notifications. It doesn’t make decisions. It clears the runway so humans can focus on the decisions that actually need a brain.

The underlying idea is Minimum Viable Process. Just enough structure to trigger compounding. Just enough coordination to prevent repeated failures. Nothing more.

It sounds too simple to work. And in a way, that’s the point. The instinct when something goes wrong is always to add. Add a review. Add a check. Add a step. The discipline of Minimum Viable Process is in asking: “What is the least we can add that solves this problem?” And then actually stopping there.

Getting Out of Chaos

If you’ve read the indicators above and recognized your team in the Chaos column, here’s where to start. And I want to emphasize start, because the biggest mistake I see managers make is trying to fix everything at once, which ironically just creates a different kind of chaos.

1. Document the decisions you make most often.

Pick the three to five decisions your team makes repeatedly — the ones that come up every week or every sprint. Deployment criteria. Incident response priorities. Feature scoping trade-offs. Whatever your recurring decisions are.

Now write down the criteria you actually use when making those decisions. Not the criteria you think you should use. The real ones. The messy, intuitive heuristics that live in your head.

This alone is transformative. Not because the document is magic, but because it makes implicit knowledge explicit. It means the next time someone faces that decision and you’re not in the room, they have something to work with.

2. Create templates for recurring work, but treat them as starting points, not mandates.

A template that says “here’s a good structure for a design doc” is a gift. A template that says “every design doc must follow this exact structure or it won’t be reviewed” is a cage. The difference is in how you frame it and enforce it. Frame it as: “This is what we’ve found works. Start here. Adapt as needed.”

3. Establish one single source of truth for key information.

Doesn’t matter if it’s Notion, Confluence, a Google Doc, or a text file in your repo. Pick one place where the important stuff lives. Architecture decisions. Team norms. Onboarding steps. Who owns what.

The format doesn’t matter. The singularity matters. One place. Not five. Not “check Slack and also the wiki and also that doc Sarah wrote last quarter.”

4. Run a short weekly sync to align on priorities, and actually use it.

Fifteen minutes. What are the top three things this week? What’s blocked? What changed since last week? That’s it. Not a status report. Not a performance review. Just alignment.

The key to all of this: add the minimum structure that prevents your most repeated problems. Then stop. Resist the urge to systematize everything. You’re not building a machine. You’re building a team that has just enough shared infrastructure to work together effectively.

Shifting Out of Bureaucracy

If your team is in the Bureaucracy quadrant, the prescription is the opposite. And it’s scarier. Adding process feels safe. Removing it feels dangerous. What if we take away the guardrail and someone drives off a cliff?

Here’s what I’ve learned: they almost never do.

1. Audit every process that exists “because we’ve always done it.”

Set aside a day (I’m serious, block an actual day!) and walk through your team’s processes with one question: “If we removed this tomorrow, what specifically would break?” Not “what could break” in some hypothetical worst case. What would break, based on what we know about how the team actually works TODAY.

You’ll find that a surprising number of processes exist to prevent problems that haven’t occurred in years, or that were caused by people who no longer work there, or that are already prevented by something else you built later.

2. Replace approval chains with clear decision rights.

Instead of “this needs to be approved by three people,” try “this decision belongs to [specific person or role]. They inform these other people when it’s made.”

The shift from “approve” to “inform and proceed” is massive. It says: we trust you to make this call. We want to know about it, but we’re not going to gate it. This single change, in my experience, has a bigger impact on team speed than almost any other intervention.

(For a more full-fledged solution, create a Responsibility assignment matrix)

3. Turn reviews into feedback loops, not gates.

Code review should make code better. Design review should make designs better. If a review process doesn’t materially alter the outcome at least 30% of the time, it’s probably not earning its keep. It’s a ritual, not a tool.

Ask yourself: what percentage of reviews actually change the work? If the answer is low, you might be running reviews for compliance, not for quality.

4. Make a recurring appointment to prune.

This is the one that makes the biggest long-term difference. Every six to eight weeks, block a half-day for the team to ask: “What process is no longer serving us?” Make it safe to challenge existing systems. Celebrate deletion as much as creation.

The mantra: Remove steps until something breaks. Then take one step back. Not two. Not five. One.

Why This Is Harder Than It Sounds

I’ve presented this as a fairly clean framework: diagnose your quadrant, apply the corresponding interventions, adjust as needed. And at the conceptual level, it is that simple.

But in practice, it’s hard. And I want to be honest about why.

People have emotional attachments to process. If someone designed the current review workflow, telling them it’s unnecessary feels personal. If a team survived a brutal outage and built an extensive post-incident process in response, suggesting that process is now overkill feels like dismissing the trauma of the outage. You’re not just editing a Confluence page. You’re navigating people’s identities and fears.

Different parts of your team may be in different quadrants. Your infrastructure team might be in Bureaucracy while your product team is in Chaos. Applying the same intervention everywhere will overcorrect one while undercorrecting the other. You need to diagnose at the team level, sometimes even at the sub-team level.

The optimal point shifts over time. As your team grows or your business changes, the right amount of process changes. What worked for eight people won’t work for thirty. What worked when everyone was in the same room won’t work when you’re distributed across three time zones. If you enter a highly regulated market, you will need more compliance. The edge is a moving target, and the only way to stay on it is to keep checking.

Leaders often are the process problem. This was the hardest lesson for me. I realized, embarrassingly late, that I was personally the bottleneck in several decision chains. Not because the process required it, but because I hadn’t let go. I said I wanted the team to be autonomous. But I also wanted to be consulted on everything. Those two desires are incompatible, and the team was paying the tax for my inability to reconcile them.

If you’re a leader reading this, the most productive thing you might do today is ask your team: “What decisions are you waiting on me for that you shouldn’t have to?” And then actually listen to the answer.

The Smallest Possible Step

I’ve given you a lot to think about. So let me end with something small and concrete.

This week, do one thing:

If you see chaos indicators on your team: pick the one problem that keeps recurring and create the minimum process to prevent it. A short checklist. A documented decision criterion. A template. Something lightweight that takes less than an hour to create and saves more than an hour next time the problem comes up.

If you see bureaucracy indicators: pick one approval, one review, or one gate and remove it. Just delete it. See what happens over the next two weeks. (Prediction: nothing bad will happen. And something good might.)

The goal isn’t perfect process. Perfect process is a myth - a destination that keeps receding as you approach it.

The goal is optimal process. Just enough to coordinate. Just enough to compound. Not enough to control.

That narrow edge, that uncomfortable, exhilarating, constantly shifting balance between too little and too much — is where high-performing teams actually live.

It’s not a place you get to. It’s a practice.

And the practice starts with seeing clearly where you are right now.

If you found this useful, I’d appreciate you sharing it with another leader who’s wrestling with the same tension. The best process insights I’ve ever gotten came from someone who was one step ahead of me in solving the same problem.

So far, I’ve been awfully quiet about AI, specifically agentic coding. I’ve been watching, experimenting, and learning.

Over the past few weeks, I’ve read a cluster of articles about AI coding that span the full spectrum from deeply skeptical to fully committed. Cory Doctorow warns about an AI bubble and the rise of “reverse centaurs”: humans reduced to squishy appendages for machines. Armin Ronacher diagnoses an “agent psychosis” sweeping the developer community. Addy Osmani documents what he calls the 80% problem and comprehension debt. Bicameral AI argues that coding assistants are solving the wrong problem entirely. Meanwhile, Dmytro Gaivoronsky reports from inside Steve Yegge’s Gas Town, running 20-30 agents simultaneously, and Jake Quist offers a clean conceptual frame that tries to explain why AI nails a RingBuffer implementation but falls apart on a simple CRM.

What struck me isn’t where they disagree. It’s how much they agree on the facts AND how differently they interpret them.

The productivity paradox nobody can escape

Let’s start with the numbers, because nearly every author reaches for the same datasets.

Faros AI and Google’s DORA report found that teams with high AI adoption merged 98% more PRs, but review times ballooned 91%, and PR size increased 154% on average. The bottleneck just moved from generation to review.

Atlassian’s 2025 survey, cited by both Osmani and Bicameral, found the paradox in stark terms: 99% of AI-using developers reported saving 10+ hours per week, yet most reported no decrease in overall workload. The time saved writing code was consumed by coordination overhead and context switching.

Index.dev reported that teams using AI completed 21% more tasks, yet company-wide delivery metrics showed no improvement. And METR, in a controlled study, found that experienced developers were 19% slower when using AI coding assistants - yet believed they were faster.

Stack Overflow’s 2025 survey showed only 16% of developers reported “great” productivity improvements from AI. The top frustrations: AI solutions that are almost right but not quite (66%) and debugging AI code taking longer than writing it yourself (45%). SonarSource found that only 48% of developers consistently check AI-assisted code before committing it, while 38% said reviewing AI-generated logic requires more effort than reviewing human-written code. And Apiiro reported that 48% of AI-generated code contains security vulnerabilities.

These numbers aren’t contested. Bulls and bears cite the same data. The disagreement is about what to do with it.

Where the work went

Here’s where the interpretations diverge, and where I think reading these pieces together is more illuminating than reading any of them alone.

Gaivoronsky, writing from inside Gas Town, puts it most directly:

“AI-assisted coding has increased my productivity and the distance between me and the code. These aren’t separate effects. The productivity gain is the distance.”

For him, the work moved upstream: into design, guardrails, and feedback loops. He splits his attention into two modes: autopilot (70% of tasks, where CI and linting provide the quality gate) and deliberate (30%, where he brainstorms with AI before writing anything, sketches designs, and reviews code carefully). He’s not worried about the distance because he’s invested heavily in the infrastructure that catches falls.

Osmani sees the same shift but focuses on its cost. He coined (via Jeremy Twei) what I think is the most useful concept in this whole debate: comprehension debt. Generation and comprehension are different cognitive capabilities. You can review code competently long after your ability to write it from scratch has atrophied. But there’s a threshold where “review” becomes rubber stamping. Osmani confesses to crossing it himself: “Claude implemented a feature I’d been putting off for days. The tests passed. I skimmed it, nodded, merged. Three days later I couldn’t explain how it worked.”

Bicameral pushes back on the entire frame. Their argument, backed by IDC’s 2024 data showing developers spend only 16% of their time writing code, is that the bottleneck was never code generation. It was always an ambiguity: the gap between business intent and technical implementation. As they quote from r/ExperiencedDevs:

“A developer’s job is to reduce ambiguity. We take the business need and outline its logic precisely so a machine can execute. The act of writing the code is the easy part.”

Their concern is that AI agents bury requirement gaps within hundreds of lines of code rather than surfacing them the way a human developer would escalate to product.

Quist offers what I think is the cleanest conceptual frame. He asked an LLM to write a RingBuffer - a self-contained data structure with clear boundaries - and it did it flawlessly, better than he could have. Then he asked it to build a personal CRM, and it fell apart. His hypothesis: the dividing line isn’t frontend versus backend or simple versus hard. It’s complexity: meaning interconnected concerns that require holding multiple contexts simultaneously. Humans are remarkably good at context-switching across these concerns. Current AI architectures aren’t. “Humans will own whatever is complex; LLMs will handle whatever isn’t.”

These aren’t contradictory views. They’re describing the same elephant from different vantage points. The work moved. Whether that’s liberating or terrifying depends on where you’re standing and what infrastructure you have in place.

The spectrum of coping strategies

What’s more useful than picking a side is recognizing that practitioners are developing a spectrum of strategies, and your position on it depends on your risk tolerance, your guardrails, and the maturity of your codebase.

On one end, Osmani lays out a comprehensive spec-driven development workflow. Start in read-only plan mode. Draft specifications before touching code. Structure them like professional PRDs with commands, testing expectations, project structure, code style, git workflow, and boundaries. Use GitHub’s Spec Kit four-phase gated workflow (specify, plan, tasks, implement). Break work into modular prompts. Build in self-checks, three-tier boundaries (always do, ask first, never do), and LLM-as-a-judge review patterns. GitHub’s analysis of over 2,500 agent configuration files confirmed that the most effective specs cover six areas: commands, testing, project structure, code style, git workflow, and boundaries.

Osmani cites Andrej Karpathy’s observation about the shift from imperative to declarative development: don’t tell the AI what to do - give it success criteria and let it iterate. Write tests first, let the agent loop until they pass. Define the API contract, let it implement to spec. The developers succeeding with this approach spend 70% of their time on problem definition and verification, 30% on execution. The ratios inverted from traditional development, but total time decreased.

On the other end, Gaivoronsky has embraced what he calls “autopilot mode” for the majority of his work, relying on deterministic feedback loops - unit tests, linters, formatters, type checking, CI gates, pre-commit hooks - as the quality net. He’s codified his patterns into Claude commands, skills, and custom prompts. When he spots something working reliably, he encodes it. The codified workflows compound. His numbers from January 2026: 1,130 sessions, 37,562 prompts, failure signals in about 16% of sessions, mostly CI-related. He’s not reviewing every line anymore, and he’s made peace with that: “Less intimate, more managerial. I know what’s there at an architectural level, but I don’t have line-by-line familiarity anymore.”

Between these two poles, there’s a pattern that both converge on: asking AI to verify its own work in a fresh context window. Have the model review its output with a clean slate and it catches its own mistakes. It sounds strange - the same model critiquing itself - but both Osmani and Gaivoronsky report that it works. The key is the fresh context: it breaks the coherence bias that made the model confident in the first place.

What goes wrong when you get it wrong

Ronacher’s piece is the necessary cold water. As a maintainer of popular open-source projects, he sees the downstream consequences when people skip the guardrails entirely and enter what he calls “slop loops.”

The asymmetry is brutal. It takes someone a minute of prompting and a few minutes of waiting for code to come out. Actually reviewing a pull request takes many times longer. The contributor felt good about it - their AI companion validated them. But the maintainer sees code that looks plausible on the surface and takes real effort to evaluate. Some projects now prefer receiving the prompts rather than the code, because prompts reveal intent more clearly than AI-generated implementations.

Ronacher describes a dynamic that resonates with something Doctorow named more precisely: the reverse centaur. In Doctorow’s formulation, a centaur is a person assisted by a machine - autocomplete, driving a car. A reverse centaur is a machine head on a human body: a person serving as a squishy appendage for an uncaring system. He points to Amazon delivery drivers surrounded by AI cameras, monitored and driven at superhuman speed. In what Dan Davies calls an “accountability sink,” the human’s job isn’t to oversee the machine’s work - it’s to take the blame for the machine’s mistakes.

You don’t have to buy Doctorow’s full macro thesis about the AI bubble to find this concept useful at the micro level. When a developer merges AI-generated code they don’t understand because the tests passed and they’re under pressure to ship, they’ve become a reverse centaur. They’re not overseeing the AI. They’re providing the accountability surface for its output. That’s a different relationship than the orchestrator-builder role that Osmani and Karpathy describe, and the line between them is thinner than anyone wants to admit.

Osmani cites Yoko Li capturing the addiction loop: “The agent implements an amazing feature and got maybe 10% of the thing wrong, and you’re like ‘hey I can fix this if I just prompt it for 5 more mins.’ And that was 5 hours ago.” You’re always almost there. The psychological hook is real.

Karpathy, via Osmani, catalogs the failure modes that persist despite system prompts, despite CLAUDE.md instructions, despite plan mode: assumption propagation (misunderstanding something early and building on faulty premises), abstraction bloat (1,000 lines where 100 would suffice), dead code accumulation, and sycophantic agreement - no pushback, just enthusiastic execution of incomplete or contradictory instructions. As Osmani puts it: “Agents optimize for coherent output, not for questioning your premises.”

What this means for your team (and for you)

I don’t have a tidy conclusion. Nobody does, and anyone claiming otherwise is selling something. But reading these pieces together surfaced a few things I keep returning to.

The split is real, and it’s not just about tools. Karpathy, via Osmani, predicts that AI coding “will split up engineers based on those who primarily liked coding and those who primarily liked building.” Armin Ronacher’s poll of 5,000 developers shows it’s already happening: 44% write less than 10% of their code manually, while 20% still write over 90% by hand. That’s a bimodal distribution, not a bell curve. As Osmani notes, there’s an uncomfortable truth here: orchestrating agents feels a lot like management. If you became an engineer because you didn’t want to be a project manager, this shift might feel like a betrayal.

Guardrails are the prerequisite, not the afterthought. Gaivoronsky is the most bullish practitioner in this group, and his entire argument rests on infrastructure: tests, linting, CI gates, pre-commit hooks, type checking. Without those, he says, “you cannot put anything on autopilot. You end up reviewing every line because that is your only quality gate.” This maps directly to the DORA 2025 finding that AI amplifies your existing practices - good processes get better, bad processes accumulate debt at unprecedented speed.

The bottleneck probably isn’t where you think. Bicameral’s argument haunts me, because it matches my experience from the past 25+ years: most tech debt isn’t created in the code. It’s created in product meetings. Deadlines, scope cuts, “ship now, optimize later.” AI agents that bury requirement gaps instead of surfacing them accelerate this. If your product-engineering handoff is already messy, AI coding tools will make it worse, not better. The IDC data showing developers spend only 16% of their time writing code should make everyone pause before celebrating 10x improvements in that 16%.

Comprehension debt compounds silently. Of everything I’ve read, this is what I worry about most for my teams. The risk isn’t that AI produces bad code. It’s that it produces confident code in the wrong direction, and that over time, the people responsible for the system understand less and less of it. As Osmani puts it:

“If your ability to ‘read’ doesn’t scale with the agent’s ability to ‘output,’ you aren’t engineering anymore. You’re hoping.”

As one commenter on Hacker News wrote: “It’s been like the boiling frog for me. Started by copy-pasting more into ChatGPT. Then more in-IDE prompting. Then agent tools. Suddenly I barely hand code anymore. The transition was so gradual I didn’t notice until I was already there.”

Complexity is the moat, for now. Quist’s frame is the one I find most durable. AI commoditizes the simple, self-contained parts of software. Humans retain ownership of the interconnected, context-heavy parts. This applies at every level: within a codebase, within a team, within an organization. The question for any engineering leader isn’t “should we use AI agents?” It’s “where in our system does the real complexity live, and how do we make sure humans still own that?”

The work moved. It didn’t disappear. Whether your organization thrives or drowns depends on whether you’ve moved with it upstream into design, specifications, guardrails, and the messy human work of reducing ambiguity, or whether you’re still standing where the code used to be, wondering why everything feels faster and worse at the same time.

We removed it. Support received exactly zero tickets. I bought the scotch.

This wasn’t a technical failure; it was a failure of imagination. I had projected my own workflow onto ten thousand strangers and assumed it was universal law.

If you lead a team, build a product, or write code, your intuition is likely lying to you about what is “normal.” This is a dissection of the False Consensus Effect, the psychological glitch that convinces us that our weird habits are the industry standard, and how it’s silently killing your product-market fit.

The Mirror House

The False Consensus Effect is the tendency to overestimate how much other people agree with our beliefs, behaviors, and preferences. We assume our internal narrative is the default setting for humanity.

It’s easy to spot in others. You see the junior dev who assumes everyone knows the obscure shortcuts in Vim. You see the CEO who thinks everyone is willing to work on Saturday because “we’re changing the world.”

It is terrifyingly hard to spot in yourself.

In 1977, Stanford psychologists asked students if they’d walk around campus wearing a sign that said “Eat at Joe’s.” The results were binary. Those who agreed to wear the sign estimated that 62% of their peers would also agree. Those who refused estimated that 67% of their peers would also refuse.

Both groups thought they were the majority. Both groups were statistically impossible to reconcile.

We anchor the world to our own position. If you think $100 is expensive for SaaS, you assume your customers do too. If you think privacy is dead, you assume your users don’t care about data tracking. You are looking in a mirror and calling it a window.

The Availability Trap

Why does a smart brain do this dumb thing? It comes down to the Availability Heuristic.

Your brain is a lazy pattern-matching machine. When asked to estimate what “most people” think, it doesn’t run a SQL query on the global population. It queries the cache.

And what’s in your cache?

1. Your own thoughts (highest availability).
2. Your friends and colleagues (high availability).
3. That one article you read yesterday (medium availability).

In tech, this is exacerbated by our tendency to cluster. We build monocultures. We hire for “culture fit.” We live in San Francisco or hang out in the same subreddits. When everyone you know hates Facebook, you assume “Facebook is dying.” meanwhile, they add another hundred million users in markets you’ve never visited.

This creates a feedback loop. You validate your opinions with people who share your opinions, which solidifies the belief that your opinions are facts.

The Ego Component

There is a darker, more fragile element here: Self-Esteem Maintenance.

Acknowledging that our worldview is niche makes us feel isolated. If I believe that clean code is more important than shipping speed, and the rest of the world disagrees, I have to confront the possibility that I might be wrong. Or, at the very least, that I am weird.

To protect our ego, we project our values onto the masses. We convince ourselves that the “silent majority” agrees with us, and the dissenters are just a loud, irrational minority.

I’ve seen this destroy marketing campaigns. A founder writes copy that appeals to themselves. It’s witty, cynical, and full of jargon. They love it. Their team loves it. The market stares at it blankly because the market doesn’t have the founder’s context.

When the campaign fails, the founder rarely blames the copy. They blame the algorithm. They blame the timing. They blame the “stupidity” of the customer.

The “One Right Way” Fallacy

In engineering, false consensus manifests as dogmatism.

I watched a team rewrite a perfectly functional REST API into GraphQL because “everyone is moving to GraphQL.” They weren’t solving a performance problem; they were solving a social anxiety problem. They assumed that because their Twitter feed was talking about graph edges, the entire industry had shifted overnight.

The reality was that 99% of the industry was still running on boring, profitable REST endpoints.

When we assume consensus, we stop looking for alternatives. We stop A/B testing because we “know” the winner. We skip the user research because “I am the user.”

You are not the user. You are a power user with equity, insider knowledge, and a specific bias toward the solution you built. You are the least representative person in the room.

Breaking the Hallucination

You cannot cure yourself of this bias. It’s hardwired. But you can build systems to bypass it.

1. The Pre-Mortem Before launching a feature or a policy, ask the room: “Let’s assume this fails spectacularly. Why did the users hate it?” This forces the team to step outside their own optimism. It compels you to simulate a user who doesn’t think like you.

2. Seek Disconfirming Evidence The natural instinct is to look for data that supports your view. Invert it. If you believe your pricing is fair, explicitly hunt for data that suggests it’s too high. If you think the UI is intuitive, put it in front of a drunk person or a relative over 60. Watch them struggle. That struggle is reality; your Figma file is theory.

3. Diversify the Input Stream If all your news comes from Hacker News and all your friends are developers, your sample size is effectively 1. Read things written by people who hate your industry. Talk to customers who churned. The goal isn’t to agree with them, but to realize that they exist in large numbers.

4. The “100 People” Heuristic Whenever you make a generalization (“Nobody uses email anymore”), visualize a stadium of 100 randomly selected humans. Not 100 tech workers. 100 humans. How many of them use email? Suddenly, your “nobody” looks a lot like “everybody except my three friends on Discord.”

The Ambiguity of Leadership

There is a nuance here. Leadership requires vision, and vision often requires ignoring the consensus.

If Steve Jobs had listened to the consensus, he wouldn’t have removed the floppy drive. If Henry Ford asked people what they wanted, they would have said faster horses.

But there is a difference between betting against the consensus and falsely assuming the consensus is on your side.

The former is a calculated risk. The latter is a delusion.

Great leaders know they are outliers. They know their vision is weird. They know the market doesn’t “get it” yet. They accept the friction. They don’t pretend that the friction doesn’t exist.

Don’t confuse conviction with consensus. You can be right when everyone else is wrong, but you better be sure you aren’t just projecting your own shadow on the wall and calling it a crowd.

Final Thought

The next time you find yourself saying “It’s obvious that…” or “Surely everyone knows…”, stop.

That is the sound of your brain trying to save energy. It’s the sound of the False Consensus Effect taking the wheel.

Pause. Check the data. Ask someone who disagrees with you.

You might still be right. But at least you won’t be betting the company on a reflection in the mirror.

I remember walking past a glass-walled conference room in our old Budapest office and seeing three of my senior engineers huddled inside. The door was shut. The whiteboard was covered in diagrams. Their body language was intense: leaning in, hushed tones, quick glances at the door.

My stomach dropped. In my head, I immediately ran the git blame on my recent management decisions. Were they quitting? Were they forking the codebase? Were they planning a mutiny because I swapped the coffee vendor?

I knocked and cracked the door, bracing for the impact.

“We’re trying to figure out how Dave fixed that concurrency bug in the legacy payment gateway,” one of them whispered, eyes wide. “The man is a wizard. Look at this race condition handling. It’s filthy. It’s beautiful.”

They weren’t conspiring. They were fanboying. They were gossiping about competence.

It changed how I viewed the “shadow org chart” - the invisible lines of communication that actually run the company.

What if the problem isn’t that people talk behind each other’s backs, but that they usually only do it when something is on fire?

We spend a fortune on “Kudos” platforms, Slack integrations that force public praise, and quarterly review cycles that feel about as organic as a plastic plant. We try to formalize appreciation. But in doing so, we strip it of the one thing that makes feedback actually stick: authenticity.

The Physics of the Whisper Network

There is a strange paradox in human psychology: we trust information more when we think we weren’t supposed to hear it.

If I look you in the eye in a 1:1 and say, “You’re doing a great job,” you process that through a filter. You know I’m your manager. You know I want to retain you. You know I read a book that told me to start meetings with positive reinforcement. You accept the data, but you doubt the source’s neutrality.

But if you hear from Sarah in Marketing that she heard me telling the VP of Product that you “saved our ass on the Q3 launch,” that hits different. That’s raw data. That’s unencumbered by the power dynamic of the direct report relationship.

I used to think my job was to suppress the rumor mill to control the narrative. Now, I realize that the rumor mill is just a high-bandwidth, low-latency network. The network isn’t the problem; the packets we’re sending are.

If you treat gossip as a neutral transport layer, you can start injecting positive payloads.

The Architecture of Positive Gossip

It sounds too simple to work, but the most effective cultural intervention I’ve ever made didn’t involve a slide deck or a consultant. It involved me wandering around the office (and later, DMing people) and “confessing” admiration.

This isn’t about being nice. It’s about data propagation.

Here is the mechanism:

1. Identify the Signal: You see someone do high-quality work.
2. Select the Carrier: Find someone else who knows the subject but wasn’t involved.
3. Transmit the Packet: Tell the Carrier about the work, with high emotion and specificity.
4. The Echo: Wait for it to get back to the subject.

When I tell you that you’re smart, it’s feedback. When I tell your peer that you’re smart, it’s me building your reputation.

Why “Authentic” is a Heavy Word

We throw the word “authentic” around until it loses meaning, but in the context of engineering culture, authenticity is simply the absence of an agenda.

Negative gossip spreads fast because it feels like a survival mechanism. “Did you hear the layoffs are coming?” “Did you hear the new CTO hates Go?” We share this to protect the tribe.

Positive gossip requires a different energy. It requires you to be delightfully irresponsible with praise.

I recall a situation with a junior designer who was struggling with confidence. I could have pulled him into a room and given him a pep talk. Instead, after he presented a new UI mock, I waited until he left the Zoom call. Then I stayed on with the Product Managers and said, “Honestly, I didn’t think he had that in him. That navigation flow is better than anything we had before. I’m actually kind of jealous I didn’t think of it.”

I knew exactly what would happen. Within twenty minutes, a PM messaged the designer: “Hey, you should have heard what Csaba just said about you after you left.”

That message meant more to him than my official performance review ever could. Because it was “stolen” information. It felt true because it was said “behind his back.”

Debugging Your Own Hesitation

You might be reading this and thinking, “This sounds manipulative.” Or perhaps, “I don’t have time to play 4D chess with compliments.”

I get that. I nearly always resist “soft skill” tactics that require calculation. But consider the alternative.

The alternative is a culture where the only things discussed in private are complaints. If you don’t seed the network with positive gossip, the vacuum will be filled with entropy—complaints about technical debt, leadership, or the snack selection.

You have to manually override the default setting of the group.

Think of this like a multi-armed bandit problem. You have limited resources (time, attention, social capital). You can spend them on:

• Formal rewards (bonuses, promotions): High cost, low frequency, medium impact.
• Direct praise: Low cost, medium impact.
• Positive Gossip: Low cost, viral impact.

The trick is that positive gossip pins your thoughts to the table. When you tell a third party that someone is excellent, you are staking your own reputation on that claim. You are co-signing their code, socially.

Implementation Details: How to Gossip Responsibly

If you want to try this, don’t make a grand announcement. Please, for the love of God, do not write a Confluence page about “The New Positive Gossip Initiative.”

Just start doing it. But follow these rules:

1. Specificity is the key (like with all feedback). “Jane is great” is noise. It will be dropped by the network. “Jane refactored that entire module without breaking the API contract, and she did it on Monday without anyone asking” is a signal. It travels.

2. Don’t fake the funk. Engineers have the best bullshit detectors on the planet. If you gossip about someone being good when they are actually mediocre, you destroy the integrity of the network. You become an unreliable node. Only gossip about things that actually impressed you for a good reason.

3. Target the connectors. Every organization has “routers”—people who talk to everyone. The QA lead. The office manager. The staff engineer who floats between teams. Drop your positive gossip packets with them. They have the highest throughput.

4. The “reverse vent” Sometimes, people come to you to vent. It’s natural. Instead of shutting them down or joining in, perform a pivot. Them: “The legacy code is a nightmare.” You: “I know. It’s a mess. Although, did you see how Marcus managed to wrap that legacy turd in a clean interface? I was honestly shocked he pulled that off.”

You acknowledged the pain, but you reused the gossip for praising someone’s competence.

The Problem You Should Be Working On

We often think the job of leadership is decision-making. I’d argue the job is just as frequently environment tuning.

If you are facing a morale problem or a silo problem, your first job isn’t to reorganize the teams. It isn’t to switch from Scrum to Kanban. It is to increase the volume of benevolent noise in the system.

When a team member feels that they are being talked about, they usually feel anxiety. Imagine a team where the sensation of being talked about generates pride.

It creates a psychological safety net. It tells the team: “Even when you aren’t in the room, we aren’t tearing you down. We are marveling at what you built.”

So, here is your homework. It’s small.

Pick one person on your team who did something awesome but thankless this week. Don’t tell them.

Go find their biggest critic, or just the person they sit next to, and whisper, “I can’t believe how well they handled that incident. I would have panicked.”

Then walk away. Let the network do the rest.

The constant pings, meetings about meetings, and context switching are killing our productivity – and worse, our joy in coding.

This article helps engineering leaders and developers understand the science behind flow states and practical ways to reclaim them. You’ll learn specific strategies to redesign your work environment and tooling for maximum focus and productivity.

What Is Flow?

Psychologist Mihály Csíkszentmihályi first introduced the concept of flow in his groundbreaking book Flow: The Psychology of Optimal Experience. He described it as “being completely involved in an activity for its own sake. The ego falls away. Time flies. Every action and thought follows inevitably from the previous one.”
In his research, Csíkszentmihályi found that flow is a state of total immersion—what he called the fusion of action and awareness. The experience is so engaging that people often lose track of time and even physical needs. Artists, scientists, and athletes consistently describe feeling “carried along” by the activity itself (Flow – Wikipedia).
According to his model, three conditions make flow possible:

1. Clear goals and feedback – The person knows exactly what success looks like and gets signals as they progress.
2. A balance between challenge and skill – The activity must stretch abilities but not create paralyzing stress.
3. Deep, focused attention – Distractions fade as the individual becomes fully present in the task.

When these elements align, a person reaches what Csíkszentmihályi called an optimal experience—an intrinsically rewarding state of creativity, control, and satisfaction (Flow Theory – ScienceDirect, Pursuit of Happiness).

The Science of Flow in Software Development

I first noticed the pattern during my time scaling engineering teams at a fast-growing startup. Our velocity metrics looked fine on paper, but something was clearly off. Developers seemed perpetually frustrated, and creative solutions had become increasingly rare.

The culprit? A near-complete inability to achieve and maintain flow states.

Flow, as defined in the research, is “a psychological state of complete immersion and engagement in an activity.” For developers, it’s that magical zone where code seems to write itself, complex problems unravel naturally, and hours pass in what feels like minutes. When engineers experience flow, studies show they demonstrate increased productivity, job satisfaction, and overall well-being.

But the modern development environment seems almost perfectly designed to prevent flow from happening.

The Three Major Flow Blockers

A comprehensive study of 700 software developers identified three categories of barriers that prevent developers from achieving flow:

1. Insufficient Cognitive Challenge

Counterintuitively, one of the most common flow barriers is work that doesn’t provide adequate mental stimulation (Flow Theory – ScienceDirect):

• Tasks perceived as boring or repetitive
• Limited opportunities to apply skills
• Work that fails to engage problem-solving capabilities

I’ve seen this play out countless times. Junior developers assigned to ticket-taking roles without deeper context become disengaged. Meanwhile, senior engineers stuck maintaining legacy systems without tackling novel challenges grow increasingly frustrated.

The key insight: Flow occurs at the intersection of high skill and appropriate challenge. Too easy, and boredom sets in. Too difficult, and anxiety takes over.

2. Situational Barriers

The environment itself often works against flow:

• Interruptions and distractions (66 mentions in the study) – including meetings, notifications, and drive-by questions
• Insufficient requirements (28 mentions) – unclear specifications that prevent progress
• Unrealistic deadlines (28 mentions) – creating pressure that blocks deep focus
• Tooling friction (27 mentions) – including poor development environments

That constant Slack ping? It’s not just annoying – it’s destroying productivity. Research shows that after an interruption, a developer may require up to 23 minutes to reclaim their flow state. With the average developer facing interruptions every 3–10 minutes, the math becomes depressing quickly.

3. Internal Factors

The study also highlighted personal barriers:

• Mental states like stress, anxiety, and motivation issues
• Cognitive limitations, particularly regarding concentration
• Health factors including sleep quality and physical well-being

These internal challenges often arise from or are exacerbated by organizational culture and work design. I’ve observed teams where the “always-on” culture directly correlates with increased anxiety, poorer sleep quality, and ultimately, diminished flow capacity.

Engineering Your Way Back to Flow

After experiencing these problems firsthand and watching them cascade through multiple organizations, I’ve developed specific strategies to reclaim flow:

Design Work for Optimal Challenge

• Map skill levels to challenges: Assign work that stretches but doesn’t overwhelm team members
• Create skill development paths: Ensure even maintenance work includes opportunities for growth
• Implement progressive complexity: Break down large problems into achievable chunks with clear wins

One technique I’ve found effective is the “15% time” approach – dedicating a portion of each sprint to self-directed learning or exploration projects. This provides the cognitive challenge often missing from regular sprint work.

Create Flow-Enabling Environments

• Establish focus blocks: Institute “no meeting” blocks of at least 2–4 hours
• Implement asynchronous communication: Default to documentation and async updates over interruptions
• Design better specifications: Invest in requirement clarity to prevent mid-flow questions

Our team experimented with “Flow Fridays” – entire days dedicated to focused work without meetings or interruptions. The productivity gains were so significant we eventually expanded to include “Focus Mornings” three days a week.

Integrate Flow-Optimized Tooling

Modern developer experience tools are increasingly designed with flow in mind:

• Unified workspaces: Tools like CodeSandbox that combine coding, previewing, and collaboration
• Context preservation: Systems that track and maintain deep context across sessions
• Automation: CI/CD pipelines that maintain momentum through automated testing/deployment

I’ve seen teams achieve remarkable results by implementing tools like:

• GitHub Copilot for reducing “blank page syndrome”
• Pluralsight Flow for tracking and preserving code context
• LinearB for visualizing workflow and preventing context switching

According to Microsoft’s DevEx research, teams using flow-optimized tools achieve 36% faster PR reviews and 58% reduced merge times.

The Manager’s Role in Protecting Flow

As engineering leaders, we have both the responsibility and the opportunity to design systems that enable flow. Here’s my checklist for flow-friendly management:

1. Ruthlessly eliminate unnecessary meetings
2. Create and enforce focus time blocks
3. Set realistic deadlines that allow for creative exploration
4. Invest in tooling that reduces friction and context switching
5. Model healthy boundaries around notifications and availability

One of my most effective interventions was a simple notification audit. We asked developers to track every interruption for a week, then systematically eliminated or batched non-critical alerts. The result was a 40% increase in reported flow time.

Measuring Flow Impact

How do you know if your flow interventions are working? While flow itself is difficult to measure directly, proxy metrics provide insight:

• Cycle time reduction
• Reported focus time increases
• Team satisfaction and engagement scores
• Quality metrics (bug rates, rework percentage)

When we implemented our flow-focused workplace redesign, we saw cycle time decrease by 27% within three months, while developer satisfaction scores improved by 22 points.

The Future of Flow-Optimized Development

The most promising development I’ve seen is the integration of flow principles directly into development tools. Cloud Development Environments can reduce onboarding time by 90% through preconfigured workspaces. VS Code’s Live Share enables collaborative debugging without leaving the IDE.

Modern AI tools, when designed thoughtfully, can enhance rather than disrupt flow states. GitHub Copilot and similar tools reduce cognitive load for routine tasks while preserving developer agency for complex problem-solving.

This also requires the engineers to master their tools, something that we seem to have lost focus on. Letting your engineers spend time on becoming power users of their development tools will boost their productivity.

The future belongs to organizations that understand a fundamental truth: developer productivity isn’t about typing speed – it’s about creating the conditions for sustained, high-quality flow states.

We love to believe the best ideas naturally rise to the top, the most skilled developers get promoted, and politics is just noise that interferes with “real work.”

This belief is deeply ingrained in engineering culture, where technical prowess is revered and anything resembling political maneuvering is dismissed as manipulation.

Well, engineering has never been an apolitical meritocracy. Research from the University of Michigan shows that the view of engineering as purely technical creates major barriers to inclusion and equity because it ignores the social and political dimensions that inevitably shape every technical decision.

Politics: The Invisible Force Shaping Every Decision

Every organization runs on politics - the informal networks of relationships, influence, and power that exist alongside formal hierarchies. You can refuse to acknowledge this reality, but that doesn’t make it disappear. It just means important decisions get made without your input.

Think about the last time a questionable technical decision got pushed through at your company. Maybe it was adopting an overcomplicated architecture, choosing a vendor everyone knew was wrong, or killing a promising project. The issue likely wasn’t that decision-makers were incompetent - it’s that the people with the right technical knowledge weren’t in the room when it mattered.

Meanwhile, someone who understood organizational dynamics was there, building coalitions, presenting compelling arguments, and demonstrating they’d done their homework. Their idea won not necessarily because it was better, but because they understood how to navigate the system while others remained “too pure” for politics.

The Four Dimensions of Political Skill

Political skill in organizations isn’t about scheming or manipulation. It’s a legitimate competency with four key dimensions that every technical leader should develop:

Social astuteness involves accurately reading social cues, understanding others’ motivations, and recognizing power dynamics within the organization. For engineers, this means paying attention to stakeholder concerns beyond just technical requirements.

Interpersonal influence is the ability to adapt your communication style to persuade different audiences effectively. This is crucial when explaining technical decisions to non-technical stakeholders or building support for architectural changes.

Networking ability means developing strategic relationships both within and outside your organization. Those coffee chats with colleagues from other teams aren’t just socializing; they’re building the relationships that enable future collaboration.

Apparent sincerity involves demonstrating authenticity and trustworthiness through consistent actions. Technical credibility combined with reliable follow-through builds the foundation for organizational influence.

Good Politics vs. Bad Politics

As with any competency, this can be used in different ways, so the key distinction isn’t between political and non-political behavior. It’s between constructive and destructive political behavior. Good workplace politics involve acceptable ways of getting recognition for your contributions, having your ideas taken seriously, and influencing what other people think and what decisions get made.

Good politics in engineering looks like:

• Building relationships before you need them, so you have advocates when proposing technical changes
• Understanding what actually motivates stakeholders and framing technical proposals accordingly
• Managing up effectively by keeping leadership informed about what matters and flagging problems early with solutions
• Creating win-win situations where helping other teams also advances your technical goals
• Making your excellent work visible through design documents, presentations, and knowledge sharing

Bad politics involves:

• Manipulating information or people for personal gain
• Taking credit for others’ work or undermining colleagues
• Making decisions based on personal relationships rather than merit
• Creating unnecessary conflict or drama
• Using influence purely for self-promotion rather than organizational benefit

Political Avoidance

When engineers refuse to engage with organizational politics, they pay a steep price:

• Their good ideas get ignored while inferior solutions advance.
• Their teams lose resources to more politically savvy groups.
• They become frustrated with “irrational” decisions without recognizing their role in enabling those outcomes.

Research shows that politically skilled individuals are more likely to be recognized for their contributions, secure promotions, and have successful careers. They’re also more effective at building high-performing teams and driving innovation because they understand how to mobilize organizational resources.

The alternative to good politics isn’t no politics! It’s bad politics winning by default.

When competent engineers opt out, they leave the field to those who may be less qualified but more willing to play the game.

Political Skills for Technical Leaders

The most effective technical leaders are highly political - they just don’t call it that. They use terms like “stakeholder management,” “building alignment,” and “organizational awareness.” But these are political skills, and mastering them is essential for technical leadership success.

Stakeholder management requires identifying all parties affected by technical decisions, understanding their motivations, and tailoring communication strategies accordingly. This isn’t manipulation - it’s ensuring that technical solutions actually solve business problems.

Building consensus involves finding common ground among groups with different priorities and constraints. Technical leaders who excel at this create buy-in for their initiatives and reduce implementation friction.

Managing up means keeping leadership informed about technical realities, risks, and opportunities in language they understand. Leaders who do this effectively protect their teams from unrealistic demands and secure resources for important work.

Closing Words

It’s time to abandon the false dichotomy between technical excellence and political engagement. The best engineers understand that technology is built by humans, for humans, within human organizations. Ignoring the human dimensions doesn’t make you more technical. It makes you less effective.

Political skill isn’t about becoming manipulative or sacrificing your values. It’s about becoming strategic in how you build relationships and exercise influence to achieve better outcomes for your team and organization.

When used ethically, political skills enable technical leaders to protect good ideas, advocate for their teams, and drive meaningful innovation.

Stop pretending you’re above politics. The stakes are too high, and the alternative - letting bad politics dominate by default - serves no one’s interests, least of all those who care most about technical excellence.

We added four new developers to the team of six. And a funny thing happened. Our velocity—the rate at which we shipped working software—didn’t just fail to increase. It went down. Communication tangled, onboarding the new folks consumed our best engineers’ time, and the complexity of the codebase suddenly felt ten times heavier. We were living out Brooks’s Law in real-time, and it was painful.

This post is for engineering managers, tech leads, and senior individual contributors who have felt that pain. It’s for anyone who has realized that building software is governed by a set of unwritten, often counterintuitive, laws. Understanding these principles won’t give you a magic formula for success, but it will provide a powerful mental toolkit to diagnose what’s going wrong and make better decisions under pressure.

⚠️ For each section, I’ve linked more detailed posts about each of them, which go deeper into the topic.

General Principles

• Pareto Principle: For many events, roughly 80% of the effects come from 20% of the causes. This principle is a fundamental law of distribution that appears everywhere in software development. It dictates that value, problems, and effort are rarely distributed evenly. Instead, a small, critical minority of inputs is responsible for the overwhelming majority of outputs.
• Ockham’s Razor: The simplest solution is most likely the right one. In software, this translates to a simple, powerful directive: when faced with multiple solutions that achieve the same outcome, the one with the fewest assumptions, dependencies, and moving parts is almost always the correct choice.

👬 Team & Project Management

⚠️ Click here for the full article

• Brooks’ Law: Adding human resources to a late software project makes it later.
• Price’s Law: In any group, 50% of the work is done by the square root number of people.
• Ringelmann Effect: Individual members of a group become increasingly less productive as the size of their group increases.
• Cagan’s Law: We need teams of missionaries, not teams of mercenaries.
• Peter Principle: People in a hierarchy tend to rise to a level of respective incompetence.

⏱︎ Time & Estimation

⚠️ Click here for the full article

• Hofstadter’s Law: It always takes longer than you expect, even when you take into account Hofstadter’s Law.
• Parkinson’s Law: Work expands so as to fill the time available for its completion.
• Ninety-Ninety Rule: The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent accounts for the other 90 percent.
• Cohn’s Laws of Estimates: Estimates are Waste, Non-Transferable, Wrong, Temporary, and Necessary.

👩‍💻 Coding & Development

⚠️ Click here for the full article

• Knuth’s Optimization Principle: Premature optimization is the root of all evil.
• Kernighan’s Law: Everyone knows that debugging is twice as hard as writing a program in the first place.
• Tesler’s Law: Every application has an inherent amount of complexity that cannot be removed or hidden.
• Spolsky’s Law of Leaky Abstractions: All non-trivial abstractions, to some degree, are leaky.

🏛️ System Architecture

⚠️ Click here for the full article

• Conway’s Law: Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
• Gall’s Law: A complex system that works has evolved from a simple system that worked.
• Hyrum’s Law: With a sufficient number of users of an API, all observable behaviors will be depended on by somebody.
• Postel’s Law: Be conservative in what you do, be liberal in what you accept from others.

🧔 Human Factors

⚠️ Click here for the full article

• Cunningham’s Law: The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer.
• Dunning-Kruger Effect: Low performers are unable to recognize the skill and competence levels of other people.
• Yerkes-Dodson Law: Elevated arousal levels can improve performance up to a certain point.

👩‍🔬 Quality & Testing

⚠️ Click here for the full article

• Linus’s Law: Given enough eyeballs, all bugs are shallow.
• Pesticide Paradox: If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs.
• Sturgeon’s Law: 90% of everything is crap.

🔐 Risk & Security

⚠️ Click here for the full article

• Murphy’s Law: If there is a wrong way to do something, then someone will do it.
• Kerckhoffs’ Principle: A system should be secure even if everything about the system, except the key, is public knowledge.

🐎 Performance & Scalability

⚠️ Click here for the full article

• Amdahl’s Law: The speedup gained from running a program on a parallel computer is greatly limited by the fraction that can’t be parallelized.
• Moore’s Law: The complexity for minimum component costs has increased at a rate of roughly a factor of two per year.
• Wirth’s Law: Software gets slower faster than hardware gets faster.

📊 Metrics & Monitoring

⚠️ Click here for the full article

• Goodhart’s Law: When a measure becomes a target, it ceases to be a good measure.
• Gilb’s Law: Anything you need to quantify can be measured in some way that is superior to not measuring it at all.

🎨 Design & UX

⚠️ Click here for the full article

• Jakob’s Law: Users spend most of their time on other sites, so users prefer your site to work the same way as all the other sites they already know.
• Fitts’ Law: The time to acquire a target is a function of the distance to and the size of the target.

🚧 Product Development

⚠️ Click here for the full article

• Zawinski’s Law: Every program attempts to expand until it can read mail.
• Atwood’s Law: Any application that can be written in JavaScript, will eventually be written in JavaScript.

Putting It All Together

These 56 laws represent decades of collective wisdom from software engineers who’ve learned from both spectacular failures and remarkable successes. They’re not rigid rules, but flexible guidelines that help you make better decisions when facing uncertainty.

The key insight? Software development is fundamentally a human activity. Technology changes rapidly, but human nature remains constant. Laws about communication, psychology, and organizational behavior often matter more than laws about algorithms or architecture.

Start by mastering a few laws that resonate with your current challenges. As you gain experience, you’ll discover which principles apply to your specific context and which situations require breaking the rules entirely.

Remember: these laws describe patterns, not prescriptions. Use them as navigation tools, not religious doctrine. The best software engineers understand the rules so well they know exactly when and how to break them.

Premature optimization is the root of all evil

This principle is a direct assault on a common engineering impulse: the desire to write clever, highly performant code from the outset. It argues that this impulse is not only unhelpful but actively harmful. The time spent optimizing code before it’s been proven to be a bottleneck is time stolen from delivering value and ensuring correctness. The vast majority of significant performance gains come from architectural decisions, not from micro-optimizing individual lines of code.

Why it happens:

• It Obscures Intent: Optimized code is frequently more complex and less readable than its straightforward counterpart. It sacrifices clarity for perceived performance gains, making the code harder to debug, maintain, and modify in the future.
• It’s Based on Guesswork, Not Data: Without profiling a working system under realistic load, any attempt at optimization is pure guesswork. Developers are notoriously bad at predicting where performance bottlenecks will occur. Effort is inevitably wasted on optimizing functions that account for a trivial fraction of the system’s runtime.
• It Addresses the Wrong Problem: Most severe performance issues are architectural sins: N+1 query patterns, chatty API calls, inefficient data structures, or a lack of caching. Focusing on algorithm-level tweaks while ignoring these macro-level issues is a futile exercise that yields negligible real-world impact.

What to do about it:

1. Follow the Mantra: Make It Work, Make It Right, Then Make It Fast. First, write simple, clear code that correctly solves the problem. Second, refactor that code for good design and maintainability. Only as a final step, if and only if you have data proving a performance problem exists, should you optimize the specific, measured bottleneck.
2. Institute a “Profile-First” Rule: Make it a team policy that no performance optimization is undertaken without supporting data. A pull request aiming to improve performance must be accompanied by profiling results or benchmarks that (a) demonstrate the problem’s existence and significance, and (b) prove the proposed solution effectively resolves it.
3. Teach Macro-Optimization Thinking: Train your team to look for performance gains at the architectural level. Encourage questions like: “Can we solve this with one database query instead of 50?” or “Should this synchronous process be an asynchronous job?” These high-level changes deliver orders of magnitude more impact than any local code tweak.

Kernighan’s Law

Everyone knows that debugging is twice as hard as writing a program in the first place

This law is a direct warning against intellectual vanity in programming. It establishes a fundamental relationship: the peak of your cleverness when writing code must be significantly higher than the peak of your cleverness required to debug it. By writing code at the absolute limit of your ability, you leave yourself no cognitive surplus to understand it later when it inevitably breaks.

Why it happens:

• The Loss of Context: When you write a piece of “clever” code, you are immersed in the problem’s context. Six months later, that context is gone. The intricate mental model you built has vanished, and you are left trying to decipher what your past, “smarter” self was thinking.
• Code is Read More Than It Is Written: A single line of code may be written once, but it will be read dozens or hundreds of times by teammates, future maintainers, and yourself. Optimizing for write-time cleverness at the expense of long-term readability creates a massive net loss in productivity for the entire team.
• Cleverness Obscures Intent: The primary purpose of code is not just to instruct the computer, but to communicate its intent to other humans. “Clever” code, with its dense syntax and non-obvious tricks, prioritizes mechanical efficiency over human communication, making it brittle and dangerous to modify.

What to do about it:

1. Write “Boring” Code: Strive to write code that is simple, obvious, and predictable. Use well-known patterns and clear, descriptive variable names. Your goal should be that a new team member can understand the code’s purpose without needing a detailed explanation.
2. Make Clarity a Primary Feature: Treat readability as a non-negotiable requirement, on par with correctness and performance. During code reviews, explicitly ask the question: “Is this code clear?” If the answer is no, it should be rejected and simplified, no matter how technically correct or “clever” it is.
3. Favor Verbosity Over Terseness: A slightly longer, more explicit block of code is almost always superior to a dense one-liner that accomplishes the same thing. Use intermediate variables to give names to complex sub-expressions. Use simple if/else blocks instead of nested ternary operators. The extra lines are a small price to pay for a massive gain in clarity.
4. Comment the “Why,” Not the “What”: If you must write a complex piece of code to solve a genuinely hard problem, do not use comments to explain what the code is doing—the code itself should do that. Instead, use comments to explain why the complexity is necessary. Document the business constraints or performance requirements that forced you to abandon a simpler solution.

Tesler’s Law: Every application has an inherent amount of complexity that cannot be removed or hidden

Also known as the Law of Conservation of Complexity, this principle states that for any given process, there is a core of complexity that cannot be reduced. It can only be moved. The central design question is not if this complexity will be handled, but who will handle it. Will you absorb the complexity in your backend logic, making the user’s experience simple? Or will you push it to the user, forcing them to make choices and configure options? The complexity must reside somewhere.

Why it happens:

• Business Logic is Inherently Complex: Real-world processes have rules, edge cases, and conditional logic. A feature like booking a flight involves dates, time zones, seat availability, and pricing rules. This complexity is intrinsic to the problem domain; it cannot be wished away.
• The “Zero-Sum” Nature of System Design: Simplifying one part of a system often complicates another. A beautifully simple, one-click UI for ordering a product requires a sophisticated backend system that can handle inventory, payments, shipping logic, and user defaults. Conversely, a simple backend might require a complex UI with many forms and dropdowns.
• Abstractions Shift, They Don’t Eliminate: Every abstraction (APIs, frameworks, libraries) is a tool for managing complexity. It doesn’t destroy the complexity; it encapsulates it. The underlying difficulty is still present and can leak through, especially during debugging or when handling failures.

What to do about it:

1. Consciously Allocate Complexity: Your primary job as a designer or developer is to decide where the complexity should live. For most consumer applications, the goal is to shoulder the burden yourself. You write more complex code so the user has a simpler experience. For expert tools (like a developer’s IDE or a data scientist’s notebook), you might deliberately expose some complexity to the user in exchange for greater power and flexibility.
2. Identify the Irreducible Minimum: Before building, explicitly ask, “What is the absolute minimum set of inputs and decisions required to accomplish this task?” This helps define the core complexity you are forced to manage. Anything beyond that is accidental complexity you have introduced yourself and should be challenged.
3. Audit Your Abstractions: When you adopt a new tool that promises simplicity, always ask, “Where did the complexity go?” Did it move into a complex configuration file? Is it hidden in a way that will make debugging impossible? Understanding this trade-off is critical. There is no magic; every simplified interface has a corresponding complexity cost somewhere else in the system.

Spolsky’s Law of Leaky Abstractions: All non-trivial abstractions, to some degree, are leaky

Abstractions are the bedrock of modern software development. They allow us to work with complex systems—like databases, networks, or operating systems—without needing to understand every detail of their internal implementation. However, this law asserts that no abstraction is perfect. Inevitably, details from the underlying layer “leak” through, forcing the developer to confront the very complexity the abstraction was meant to hide.

Why it happens:

• Performance is a Stubborn Detail: An abstraction can hide how something is done, but it can’t hide how long it takes. An Object-Relational Mapper (ORM) abstracts away SQL, but when it generates an N+1 query that brings the database to its knees, the underlying reality of database performance has leaked through, demanding knowledge of SQL to fix.
• Failure Modes are Unavoidable: An abstraction cannot perfectly insulate you from the failure modes of the system it represents. An API client library might provide a simple getData() method, but when the network fails, it leaks TCP/IP errors. The developer must then understand the nature of network failures to handle them robustly.
• Semantic Mismatches: Sometimes the simplified model offered by the abstraction doesn’t perfectly match the nuanced behavior of the underlying system. A file system abstraction might try to provide a uniform interface, but the subtle differences in file locking between Windows and Linux will eventually leak through and cause bugs.

What to do about it:

1. Learn One Layer Down: This is the most critical takeaway. Do not be a “framework-only” developer. If your job involves using React, have a functional understanding of the DOM. If you use an ORM, learn to write and analyze SQL. If you use Docker and Kubernetes, understand the basics of networking and Linux processes. You don’t need to be an expert in the lower layer, but you must be competent enough to debug when the inevitable leaks occur.
2. Choose Your Abstractions Deliberately: Favor abstractions that are transparent about their trade-offs and make it easy to access the underlying layer when needed. An ORM that allows you to drop down to raw SQL is less dangerous than one that completely forbids it. Be skeptical of abstractions that promise too much magic.
3. Debug with the Leak in Mind: When faced with a bizarre or intractable bug, your first question should be, “Is the abstraction leaking?” Use tools to inspect the output of the abstraction. Look at the generated SQL, the raw network requests, or the actual system calls being made. The root cause of the problem is often found in the leaked details.

Jakob’s Law

Users spend most of their time on other sites, so users prefer your site to work the same way as all the other sites they already know

This law is a powerful mandate for convention over unnecessary novelty in user interface design. It posits that users have built a powerful mental model for how the web works based on their cumulative experience across thousands of other applications. Your application is a guest in their digital life. To be a good guest, you must follow the house rules they have already learned. Violating established patterns forces users to learn a new model, creating friction and cognitive load that drives them away.

Why it happens:

• Conservation of Cognitive Energy: Users do not want to spend their limited mental energy learning how your unique navigation menu works. They want to spend it achieving their goal (e.g., buying a product, reading an article). By using familiar patterns, you lower the cognitive cost of using your application, making it feel intuitive and effortless.
• The Power of Habit: Common interactions are deeply ingrained habits. Users instinctively look for a logo in the top-left to go home, a shopping cart in the top-right, and a search bar near the top of the page. Deviating from these conventions doesn’t feel creative; it feels broken.
• Transfer of Expectation: When a UI element looks like a standard component (e.g., a dropdown menu), users expect it to behave like one. If your “creative” dropdown violates those behavioral expectations, you create confusion and erode the user’s trust in your interface.

What to do about it:

1. Default to Convention: When designing any standard UI component—be it a login form, a data table, or a settings page—your first step should be to research how the most popular applications handle it. The problem has likely already been solved. Adopt the prevailing pattern.
2. Focus Innovation on Your Core Value: Do not waste your team’s limited creative budget on reinventing the date picker. Save your innovative energy for the parts of your application that are truly unique to your domain and deliver your core value proposition. For everything else, be boringly predictable.
3. Use a Design System to Enforce Consistency: A robust design system is the most effective tool for implementing Jakob’s Law at scale. It provides a canonical, pre-vetted, and conventional component for every common UI need. This prevents individual teams from introducing novel (and likely confusing) patterns, ensuring a consistent and intuitive experience across your entire product.
4. Use Usability Testing to Confirm, Not Discover: If users are consistently struggling with a basic element in your UI, the problem is not the user. It is almost certainly a violation of a design convention they have learned elsewhere. Use testing to identify and eliminate these moments of friction, bringing your design back in line with user expectations.

Fitts’ Law

The time to acquire a target is a function of the distance to and the size of the target

This is a predictive model of human movement that has profound implications for all interface design. It states that hitting a target—be it a button on a screen or a physical object—is faster and easier when the target is larger and closer. This isn’t a suggestion; it’s a fundamental principle of human biomechanics. Ignoring it results in interfaces that feel clumsy, slow, and frustrating.

Why it happens:

• Motor Precision: Small, distant targets require more precise motor control and finer adjustments, which takes more time and increases the probability of error. Large, close targets can be acquired with faster, less precise movements.
• Cognitive Effort: While rooted in motor skills, the law has a cognitive component. Interfaces that adhere to Fitts’s Law require less conscious thought to navigate. Users don’t have to carefully aim their pointer; they can move quickly and confidently, reducing mental friction.
• The Magic of Edges: The edges and corners of a screen are effectively “infinitely large” targets in one dimension because the pointer cannot overshoot them. This makes them the fastest possible targets to acquire, a principle leveraged by macOS’s top menu bar and the Windows Start button.

What to do about it:

1. Prioritize by Size and Position: Make your most important and frequently used UI elements (e.g., the primary call-to-action on a page) the largest and most prominent targets. Place them in positions that are easy to reach from the user’s likely previous point of interaction.
2. Make Destructive Actions Harder to Hit: Conversely, use Fitts’s Law for safety. Make dangerous or irreversible actions (like “Delete Account”) smaller, place them further away from common interaction areas, or require an extra click. This deliberate increase in target acquisition time acts as a natural speed bump, preventing catastrophic errors.
3. Minimize Travel Distance: Group related elements together. A “Save” button should be located near the form fields it acts upon, not at the opposite corner of the screen. In a mobile app, place primary navigation elements within easy reach of the user’s thumb.
4. Apply it Metaphorically to API Design: Fitts’s Law can be extended beyond GUIs. Think of the data a client needs as the “target.” A “chatty” API that requires multiple round trips to gather all necessary information has a very large “travel distance.” A well-designed API (e.g., using GraphQL or a Backend-for-Frontend pattern) allows the client to acquire all the data in a single call—a large target with zero distance—making the entire interaction vastly more efficient.

Cunningham’s Law

The best way to get the right answer on the internet is not to ask a question; it’s to post the wrong answer

This law observes a peculiar quirk of human psychology that is highly effective for soliciting technical help. A direct question asking for help can often be ignored, as it requires altruistic effort from an expert. However, a confidently stated wrong answer is a magnet for correction. It leverages the human desire to demonstrate expertise and correct inaccuracies, often resulting in a faster and more detailed response than a simple plea for assistance.

Why it happens:

• The Impulse to Correct: For many experts, the drive to fix a factual error is stronger than the drive to help a stranger. A wrong statement is a challenge to their knowledge, and responding is an act of defending the truth (and demonstrating their superior understanding).
• Lower Cognitive Load: Answering a broad question like “How do I configure Webpack?” requires a lot of effort. Correcting a specific, flawed statement like “I just need to add this one line to my webpack.config.js to enable tree-shaking, right?” is a much smaller, more targeted task. It gives the expert a clear entry point to share their knowledge.
• Demonstrating Prior Effort: Posting a wrong answer inherently proves that you have already tried to solve the problem yourself. It signals that you are not just lazily asking for a handout, which makes experts more willing to engage and share their time.

What to do about it:

1. Frame Your Problem as a Flawed Solution: When you’re stuck, formulate your query as a proposed (and likely incorrect) solution. Start with your goal, state your flawed understanding, and present your wrong answer. For example: “I need to optimize my database query. My understanding is that adding an index to every column is the best practice, but my performance is still slow. What am I missing?”
2. Be Confident, but not Combative: Present your wrong answer with a degree of confidence, but be prepared to be corrected. The goal is to trigger the corrective impulse, not to start an argument. Your aim is to get information, not to win a debate.
3. Use It as a Tool, Not a Gimmick: This isn’t about trolling or being intentionally obtuse. The most effective use of this law is when the “wrong answer” is your genuine, best-effort attempt at a solution. It’s a powerful tool for getting unstuck when you’ve reached the limits of your own knowledge, turning your confusion into a catalyst for expert engagement.

Dunning-Kruger Effect

Low performers are unable to recognize the skill and competence levels of other people

This psychological principle explains a common and dangerous dynamic on engineering teams. The skills required to be a competent developer are the very same skills required to recognize competence. A junior engineer who doesn’t understand the importance of maintainability, security, or architectural trade-offs is incapable of recognizing the absence of those qualities in their own work. This leads to the paradox where your least experienced engineers are often the most certain, while your most senior engineers are acutely aware of how much they don’t know.

Why it happens:

• The “Unknown Unknowns”: Low performers lack the metacognitive ability to realize they are low performers. They have not yet been exposed to the full scope and complexity of the domain, so their mental map of “what it takes to be good” is incomplete. They judge their work against this flawed, smaller map and find it sufficient.
• The Curse of Knowledge: Conversely, highly competent engineers often struggle to accurately assess the abilities of others. They find it difficult to remember what it was like not to know something, and may underestimate the difficulty of a task for a less experienced colleague.
• Feedback Deficits: In environments where direct, critical feedback is avoided, an individual’s inaccurate self-assessment is never challenged. Without external calibration, the overestimation of the junior and the imposter syndrome of the mid-level developer are allowed to fester.

What to do about it:

1. Create Objective Yardsticks: Don’t rely on subjective feelings of “good code.” Establish clear, objective standards. Use checklists for pull requests, define explicit coding standards, and create architectural decision records (ADRs). This provides a non-confrontational way to reveal gaps in knowledge. The feedback shifts from a personal “your approach is naive” to an impersonal “this does not meet the team’s documented standard for X.”
2. Implement Structured Peer Feedback: Use structured 360-degree feedback cycles where engineers are required to comment on the work of their peers against specific competencies. This forces a calibration. The junior receives concrete data showing how their impact is perceived, and the senior receives validation that their expertise is recognized and valuable, combating imposter syndrome.
3. Mandate Mentorship and Pair Programming: The most effective way to expose a junior to their “unknown unknowns” is to pair them with a senior on a complex task. Through observation and guided practice, the junior begins to see the deeper considerations they were previously missing. This is the fastest way to accelerate an engineer from “unconscious incompetence” to “conscious incompetence,” which is the first, critical step toward true mastery.

Yerkes-Dodson Law

Elevated arousal levels can improve performance up to a certain point

This law explains the critical difference between productive pressure and destructive stress. It dictates that performance follows an inverted U-shaped curve in response to pressure. Too little pressure leads to boredom and low performance. Too much leads to anxiety and burnout. The leader’s challenge is to keep their team in the “optimal arousal” zone—the peak of the curve where focus and effectiveness are maximized.

Why it happens:

• Low Arousal (Boredom): With no deadlines, unclear goals, or unchallenging work, there is no impetus to focus. This state encourages procrastination, over-engineering simple problems, and a general lack of engagement. Performance is poor due to inertia.
• Optimal Arousal (Flow State): When a team faces a challenging but achievable goal, their focus narrows. The brain filters out distractions, prioritizing creative problem-solving to meet the demand. This is the state of “flow,” characterized by high engagement and peak performance. The pressure is a motivating force.
• High Arousal (Burnout): When pressure becomes excessive—through impossible deadlines, constant emergencies, or a toxic culture—it triggers a threat response. Cognitive function degrades. The focus narrows to a counterproductive tunnel vision, impairing strategic thinking and increasing simple errors. This is the path to exhaustion and breakdown.

What to do about it:

1. Apply Pressure with Purpose: Pressure must be tied to clear, meaningful, and achievable goals. A vague demand to “go faster” is just noise. A specific challenge like, “Let’s land this critical feature in the next two-week sprint,” creates focused, productive tension. Use well-defined, short-term goals to guide the team’s energy.
2. Manage Work in Sprints, Not Marathons: No team can sustain peak performance indefinitely. The key is to create cycles of stress and recovery. Structure work into periods of intense focus (sprints, launch pushes) followed by periods of lower-intensity work (tech debt reduction, planning, hack weeks). This allows the team to recharge, preventing a slide into the burnout zone.
3. Act as a Pressure Regulator, Not an Amplifier: A leader’s job is to modulate stress. Be a sensor for the team’s state. Are bug rates increasing? Is communication becoming terse? Are people consistently working late without a corresponding increase in output? These are signs of overload. Your role is to intervene by de-scoping work, defending the team from external pressures, and reinforcing that long-term sustainability is the goal.

When a measure becomes a target, it ceases to be a good measure

This is the cardinal rule of metrics and the most common trap in management. It states that the moment a measure is used as a target for reward or evaluation, its value as an objective indicator is destroyed. The system being measured will be manipulated to optimize for the metric itself, often at the expense of the actual, desired outcome. In engineering, this means if you make “lines of code” a target, you’ll get verbose, bloated code. If you make “story points” a target, you’ll get inflated estimates and artificially small tasks.

Why it happens:

• The Path of Least Resistance: It is almost always easier to game a proxy metric than it is to achieve the real goal the metric was supposed to represent. Hitting a numeric target becomes the job, displacing the more complex work of delivering genuine value.
• Malicious Compliance: When people are pressured to hit a specific number, they will comply with the letter of the law while violating its spirit. They will close tickets without properly fixing the bug or deploy code that meets the spec but fails to solve the user’s problem.
• Focus on Outputs, Not Outcomes: Simple, countable metrics (outputs) like “commits” or “deployments” are easy to measure and target. The real goal (outcome), such as “improved user satisfaction” or “reduced system downtime,” is harder to quantify. Goodhart’s Law pushes organizations to focus on the easy-to-measure outputs, even when they become disconnected from valuable outcomes.

What to do about it:

1. Measure Processes, Not People: Use metrics to understand the health of your development system, not to evaluate individual performance. Track metrics like cycle time (how long it takes an idea to get to production) to identify bottlenecks in your process, not to rank engineers against each other.
2. Use a Dashboard of Counter-Balancing Metrics: Never rely on a single metric. Instead, use a “dashboard” of metrics that balance each other out. For example, pair a speed metric like “Deployment Frequency” with a quality metric like “Change Fail Rate.” This makes it much harder to game the system, as optimizing for one metric at the expense of the other will be immediately visible. The DORA metrics are an excellent example of such a balanced dashboard.
3. Tie Targets to Business Outcomes: When you must set targets, tie them as closely as possible to real business or customer value. Instead of targeting “10 features shipped,” target a “5% reduction in customer churn.” This forces the team to focus on solving the real problem, rather than just hitting a proxy. The “how” is left to the team, but the “why” is clear and difficult to game.

On the other hand, I’ve written about Why Goodhart’s Law Isn’t All That Useful…

Gilb’s Law

Anything you need to quantify can be measured in some way that is superior to not measuring it at all

This law is a direct challenge to the common excuse, “But that’s too subjective/complex to measure.” It argues that for any desirable quality—be it user satisfaction, code maintainability, or developer productivity—an imperfect proxy metric is vastly superior to having no metric at all. The act of defining a measurement, even a flawed one, forces clarity of thought and provides a baseline against which to judge progress. If you cannot measure it, you cannot meaningfully improve it.

Why it happens (Why this principle is necessary):

• Vagueness Prevents Action: Without measurement, goals remain ambiguous platitudes. “Improve user experience” is a wish, not a plan. “Reduce user clicks for the core workflow from an average of 7 to 4” is a measurable, actionable goal.
• Measurement Forces Definition: The process of trying to measure a fuzzy concept like “code quality” forces you to define what you mean. Is it test coverage? Cyclomatic complexity? The rate of production bugs? This act of definition is often more valuable than the resulting number, as it creates a shared understanding within the team.
• Perfection is the Enemy of Progress: Teams often get stuck in “analysis paralysis,” endlessly debating the flaws of every proposed metric. Gilb’s Law encourages a pragmatic approach: start with a “good enough” metric now, learn from it, and improve it later. An imperfect signal is better than no signal.

What to do about it:

1. Start with a Proxy Metric: When faced with a seemingly unmeasurable quality, find a reasonable proxy. To measure “developer morale,” you could start by tracking voluntary team event attendance or responses to a simple weekly poll. It’s not perfect, but it’s a data point where before you had none.
2. Decompose the Concept: Break down large, abstract goals into smaller, measurable components. “Improving platform stability” can be decomposed into “increase mean time between failures (MTBF),” “decrease mean time to recovery (MTTR),” and “reduce the number of P1 incidents per month.”
3. Iterate on Your Metrics: Treat your metrics like code. Your first attempt will likely have flaws. Use it, observe its shortcomings, and then refactor or replace it. The goal is not to find the perfect metric on day one, but to continuously evolve your ability to measure what matters.
4. Use Metrics for Insight, Not as a Weapon: This is the crucial companion to Goodhart’s Law. The initial purpose of a new metric should be for observation and learning, not for setting performance targets. Use it to understand the system and spark conversations. Only once a metric is well-understood and stable should it be cautiously considered as part of a balanced dashboard of targets.

The speedup gained from running a program on a parallel computer is greatly limited by the fraction that can’t be parallelized

This law provides the mathematical justification for why simply throwing more hardware (cores, servers, threads) at a performance problem often yields disappointing results. It states that the maximum performance gain is capped by the sequential part of your process. If 10% of your application’s runtime is a single-threaded, serial task, then even with an infinite number of processors, you can never make your application more than 10x faster. That serial portion becomes the ultimate bottleneck.

Why it happens:

• Inherent Sequential Logic: Most processes have components that must execute in order. This can be initializing the system, reading a configuration file, acquiring a central lock, or aggregating final results from all parallel workers. These steps cannot be sped up by adding more resources because they can only be done by one worker at a time.
• The Law of Diminishing Returns: The first few processors you add provide a significant boost because they attack the large, parallelizable portion of the work. However, as more processors are added, the parallel portion’s runtime shrinks toward zero, leaving the fixed-duration serial part to dominate the total execution time. The return on each additional processor diminishes rapidly.
• Coordination Overhead: In practice, adding more parallel workers isn’t free. It introduces communication and synchronization overhead. The effort required to split the work, distribute it, and collect the results can itself become a new bottleneck, further limiting the theoretical gains predicted by the law.

What to do about it:

1. Profile Before You Parallelize: Never optimize based on assumption. Before you invest in more hardware or a complex multi-threaded design, use a profiler to precisely measure your application. You must identify what percentage of the runtime is spent in serial execution versus parallelizable execution.
2. Focus Obsessively on the Serial Fraction: The most dramatic performance improvements come not from making the parallel part faster, but from shrinking the serial part. Relentlessly attack the bottlenecks. Can that initial data load be made asynchronous? Can you break a coarse, global lock into multiple fine-grained locks? Can you redesign the algorithm to reduce the final, single-threaded aggregation step?
3. Architect for Parallelism from the Start: When designing a new system for scale, consider Amdahl’s Law. Choose algorithms and data structures that are inherently parallelizable. Favor approaches like sharding or partitioning data to avoid centralized chokepoints. A system designed with a small serial fraction from the beginning will scale far more effectively than one that has parallelism bolted on as an afterthought.

Moore’s Law

The complexity for minimum component costs has increased at a rate of roughly a factor of two per year

Wirth’s Law

Software gets slower faster than hardware gets faster

These two laws exist in a state of permanent tension. Moore’s Law observes that the number of transistors on a chip—a proxy for raw hardware capability—doubles approximately every two years. Wirth’s Law counters that software gets slower more rapidly than hardware gets faster. The result is the frustrating reality that despite exponential gains in hardware power, modern applications often feel just as sluggish as their predecessors. Moore’s Law provides a “performance dividend,” and Wirth’s Law explains how we immediately squander it.

Why it happens (Why Wirth’s Law usually wins):

• Layers of Abstraction: Modern software is built on mountains of abstraction—operating systems, virtual machines, containers, frameworks, and countless libraries. Each layer adds safety and boosts developer productivity but imposes a performance tax. Since developer time is typically more expensive than CPU cycles, we consistently make the economic choice to trade machine efficiency for human efficiency.
• Rising User Expectations & Feature Bloat: Software is never “done.” The performance gains from new hardware are immediately consumed by demands for more complex features: higher-resolution graphics, real-time collaboration, more powerful analytics, and richer UIs. The baseline of what is considered an acceptable application is constantly rising, eating every available hardware cycle.
• Developer Complacency: Fast hardware makes developers lazy. When there is no immediate performance pain on a developer’s high-end machine, there is little incentive to write efficient code. Inefficient algorithms and bloated dependencies are accepted because the hardware is powerful enough to brute-force through them, creating a cycle of inefficiency.

What to do about it:

1. Stop Expecting a Free Lunch: The era of relying on single-core speed improvements from Moore’s Law is over. Gains now come primarily from multi-core processors, which software cannot automatically leverage without careful, parallel design (see Amdahl’s Law). You must actively manage performance; the hardware will no longer save you by default.
2. Establish a Performance Budget: Treat performance as a feature. Define explicit, non-negotiable performance targets for your application (e.g., “API response time must be under 100ms,” or “page load must be under 2 seconds”). Integrate performance testing into your CI/CD pipeline to catch regressions automatically. This makes the cost of bloat visible and forces a deliberate conversation about trade-offs.
3. Conduct Dependency Audits: Every new library or framework you add is a performance liability. Before adding a dependency, ask: “Is the productivity gain from this library worth its performance cost?” Regularly audit your project to identify and remove unused or overly costly dependencies.
4. Optimize for the User, Not the Developer: While developer productivity is important, it cannot be the only consideration. Remind the team that the user is not running their high-end development machine. Test on lower-specced hardware and slower network connections to build empathy and reveal the true performance cost of your architectural decisions.

Every program attempts to expand until it can read mail.

This law is a cynical but accurate observation on the lifecycle of successful software. The natural trajectory of any useful program is to accumulate features until it becomes a bloated, unfocused platform. The reference to “reading mail” is metaphorical; it represents the ultimate, all-encompassing “platform” feature that is completely disconnected from the program’s original purpose. The law is a warning that feature creep is not an accident but an inevitable gravitational force that must be actively resisted.

Why it happens:

• Success Attracts Requests: A program’s success is its own worst enemy. The more users it acquires, the more diverse their needs become. These users will relentlessly request features to solve their adjacent problems, pulling the product in countless different directions to avoid having to switch to another tool.
• The Feature Parity Arms Race: The competitive landscape creates immense pressure to match the feature set of rival products. This leads to a reactive development cycle where the roadmap is dictated by a competitor’s checklist rather than a coherent product vision.
• Organizational Gravity: It is often easier for a product team to justify its existence and demonstrate progress by shipping new features than by doing the less glamorous work of refining, simplifying, or removing existing ones. The product’s expanding surface area becomes a proxy for the team’s output.

What to do about it:

1. Have a Written and Enforced Product Vision: The most potent defense is a clear, concise vision statement that defines what the product is and, more importantly, what it is not. This document serves as a constitution, providing a framework for saying “no” to requests that don’t align with the core purpose.
2. Make “No” the Default Answer: Every new feature should be considered guilty until proven innocent. The burden of proof must be on the proposed feature to demonstrate overwhelming value and alignment with the vision. A culture of strategic refusal is essential to protect the product’s focus and prevent the accumulation of “barnacle” features.
3. Focus Relentlessly on the Core “Job to be Done”: Sharply define the primary problem your users “hire” your product to solve. Every feature decision should be evaluated against a single question: “Does this help the user do that core job better?” If the answer is no, the feature is likely a distraction.
4. Favor Integration over Assimilation: Instead of building every requested adjacent functionality, provide robust APIs and integrations. Let other best-in-class tools handle those jobs. This allows your product to be a powerful, connected part of a user’s workflow without absorbing the complexity and maintenance burden of becoming a monolithic “everything-platform.”

Atwood’s Law

Any application that can be written in JavaScript, will eventually be written in JavaScript.

This law is less a statement about the technical superiority of JavaScript and more a profound observation on ecosystem gravity and the path of least resistance. It recognizes that the language with the greatest ubiquity, the largest repository of pre-built solutions (npm), and the ability to run on both the client and the server holds a powerful, gravitational advantage. Developers will inevitably use the most convenient and accessible tool, and for a vast spectrum of modern applications, that tool is JavaScript.

Why it happens:

• Unavoidable Ubiquity: JavaScript is the only language that runs natively in every web browser on the planet. This gives it a unique and unassailable beachhead. Any application with a web component must interact with JavaScript, making it a constant presence.
• The Full-Stack Advantage: The advent of Node.js allowed developers to use a single language, toolchain, and mental model across the entire stack. This dramatically reduces cognitive overhead and simplifies team structure, making it the most efficient choice for many organizations.
• Ecosystem Gravity: The npm registry is the largest software library in the world. The answer to “how do I solve X?” is almost always a quick npm install away. This creates a powerful feedback loop: more developers lead to more libraries, which in turn attracts more developers.
• Low Barrier to Entry: The accessibility of JavaScript creates a massive global talent pool. It’s easier to hire for and easier for new developers to start with, ensuring its continued dominance in the workforce.

What to do about it:

1. Acknowledge JavaScript as the Default: For many standard web applications and services, JavaScript/TypeScript is the default, baseline choice. You must have a strong, specific, and evidence-based reason to deviate from it. Fighting this default for dogmatic reasons is often a poor business decision.
2. Define Your “Escape Hatches”: Identify the specific domains where JavaScript’s weaknesses are a critical liability for your product. This typically includes high-performance computing, low-level systems programming, or complex data science. For these areas, deliberately choose a more suitable language (like Go, Rust, or Python) and treat it as a strategic exception.
3. Mandate a Type System: For any non-trivial JavaScript project, do not treat TypeScript (or a similar type system) as optional. Mandate it. This is the single most effective tool for mitigating JavaScript’s scalability and maintainability issues, allowing you to manage the complexity that comes with building large applications.
4. Invest in Polyglot Capabilities: While acknowledging JavaScript’s gravity, avoid creating a monoculture. Strategically cultivate expertise in a second or third language that complements JavaScript’s weaknesses. This ensures your organization has the flexibility to choose the truly right tool when the problem domain demands it, rather than just the most convenient one.

Given enough eyeballs, all bugs are shallow.

Born from the open-source movement, this law posits that the difficulty of finding a bug is inversely proportional to the number of skilled people looking at the code. A bug that seems impossibly obscure to a single developer becomes obvious when exposed to multiple perspectives. Software quality is a function of collective scrutiny, as every individual developer has cognitive biases and blind spots.

Why it happens:

• The Author’s Blind Spot: The developer who wrote the code is often the least qualified to find its flaws. They review the code through the lens of their original intent, reading what they meant to write, not what they actually wrote. A fresh set of eyes is free from this bias.
• Diversity of Expertise: A single developer cannot be an expert in everything. A “shallow” bug to a security engineer (e.g., an injection vulnerability) might be invisible to a developer focused solely on business logic. Different reviewers bring different lenses—performance, accessibility, database efficiency, security—each capable of spotting a class of bug others would miss.
• Distributed Cognitive Load: Thoroughly vetting a piece of code is mentally taxing. Distributing this effort across multiple reviewers allows for a more comprehensive analysis. One person might focus on the high-level logic, another on edge cases, and a third on style and consistency, leading to a more robust review than any single person could manage alone.

What to do about it:

1. Mandate Rigorous Code Reviews: Make peer review a non-negotiable part of your development process. Set a clear standard (e.g., “no code merges without two approvals”) and treat it as a critical quality gate, not a rubber-stamp formality.
2. Cultivate a Culture of Constructive Criticism: Model and reward thorough, critical feedback. Frame reviews as a collaborative effort to improve the code, not as a personal judgment of the author. An environment where engineers are afraid to ask tough questions is an environment where bugs will thrive.
3. Systematize Cross-Team Reviews: Break down team silos. Encourage or require engineers to review code from outside their immediate team. This cross-pollination not only catches more bugs by introducing diverse perspectives but also spreads knowledge and best practices throughout the organization.
4. Utilize Pair and Mob Programming for Critical Code: For the most complex or high-risk parts of your system, apply Linus’s Law in real-time. Pairing (two developers) or mobbing (a whole team) on a single piece of code bakes the review process directly into creation, catching bugs the instant they are typed.

Pesticide Paradox

If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs.

Borrowing its name from agriculture, this principle states that an automated test suite, like a pesticide, loses its effectiveness over time. A suite that never changes is excellent at catching regressions—ensuring that old, fixed bugs don’t reappear. However, it becomes progressively worse at finding new or different kinds of bugs, giving a false sense of security while the underlying quality of new code may be degrading.

Why it happens:

• Implicit Adaptation: Developers begin to write code that satisfies the existing test suite. They know the specific conditions being checked and ensure their code passes, but this offers no guarantee against flaws in areas or conditions the tests don’t cover.
• Codebase Evolution: The application is not static. As new features are added and old ones are refactored, new code paths and edge cases are introduced. A static test suite does not evolve with the codebase, meaning its coverage of the current application state steadily decreases over time.
• Inurement to Specific Flaws: The test suite becomes perfectly tuned to find a specific class of bug—the ones its authors anticipated. It remains blind to entire categories of errors that were not considered during its creation, such as novel security vulnerabilities, performance regressions, or concurrency issues.

What to do about it:

1. Treat Tests as Living Code: Continuously review, refactor, and expand your test suite. Every new feature must be accompanied by new tests that cover its logic. When an existing feature is changed, its tests must be updated to reflect the new reality. A “test-first” or TDD approach naturally encourages this.
2. Diversify Your Testing Portfolio: Augment your unit tests with other methods designed to find different kinds of bugs. Introduce integration testing, property-based testing, and end-to-end testing. Each method attacks the code from a different angle.
3. Use Production Bugs to Fortify Tests: For every bug that escapes to production, write a new automated test that reproduces it before you fix it. This ensures your test suite learns from its failures and becomes progressively stronger.
4. Embrace Exploratory Testing: Schedule time for skilled humans to intentionally try to break the application. Unlike scripted tests, exploratory testing leverages human curiosity and intuition to uncover unexpected interactions and novel failure modes.

Sturgeon’s Law

90% of everything is crap.

This blunt axiom is not an expression of cynicism but a powerful filter for strategic focus. It posits that the vast majority of any creative or operational output is low-value. In software, this means that most feature ideas will fail to impact key metrics, most lines of code in a mature system are rarely executed cruft, and most agenda items in a status meeting are informational noise. The critical work is to separate this 90% of dross from the 10% of gold.

Why it happens:

• The Cost of Ideas is Zero: Generating ideas is cheap and easy, leading to a massive volume of feature requests, suggestions, and “what ifs.” The cost of implementing these ideas, however, is extremely high. Without a strong filter, this imbalance naturally leads to a backlog dominated by low-value work.
• Organizational Entropy: Systems and processes tend toward disorder. Over time, products accumulate features that were once relevant but are now obsolete. Code is added but rarely removed. Meetings are added to the calendar but never questioned. This accumulation of low-value assets creates drag on the entire organization.
• Loss Aversion: It is psychologically harder to remove something than to add it. Teams are often afraid to deprecate a feature, even one with near-zero usage, for fear of angering a handful of users. This leads to bloated, unfocused products that are difficult to maintain and confusing for new users.

What to do about it:

1. Measure Everything, Prioritize Ruthlessly: Instrument your application to understand which features are actually used and which provide the most value. Use this data to build a prioritization framework that brutally favors the 10% of work that impacts core business goals.
2. Practice Strategic Abandonment: Make feature deprecation and code removal a celebrated, first-class engineering activity. Regularly schedule time to identify and delete unused code, obsolete features, and pointless processes. This isn’t just “cleanup”; it’s a strategic act that reduces complexity, lowers maintenance costs, and improves focus.
3. Focus on Problems, Not Features: Instead of asking “What should we build?”, ask “What is the most important user problem we can solve right now?” This reframing naturally filters out a huge number of low-value “nice-to-have” feature ideas and directs the team’s energy toward the 10% of work that truly matters to customers.
4. Apply a “Value Audit” to Processes: Regularly question recurring activities. For every standing meeting, ask: “What decisions are made here that couldn’t be made asynchronously?” For every report, ask: “What action is taken based on this data?” If the answer is unclear, eliminate the activity. This frees up the organization’s most valuable resource—time—for high-impact work.

If there is a wrong way to do something, then someone will do it

In software engineering, this is not a cynical joke; it’s the fundamental principle of defensive design. It dictates that if there is an incorrect way for a user to interact with your UI, an invalid way for a developer to call your API, or a way for bad data to enter your system, it is not a matter of if but when it will happen. A robust system is one that anticipates and gracefully handles this inevitability.

Why it happens:

• User Error and Exploration: End-users are not programmers. They will enter text into number fields, use the back button at the worst possible moment, and click buttons in an order you never anticipated. This isn’t malice; it’s a natural consequence of human interaction with a complex system.
• Misunderstood Contracts: The developers consuming your API will misread the documentation, misunderstand a data type, or fail to handle an error case. Their system will send you malformed data or call your endpoints in unexpected sequences.
• Hostile Intent: A subset of interactions will be deliberately malicious. Attackers will probe every input for security vulnerabilities like SQL injection or cross-site scripting, intentionally trying to trigger failure modes you didn’t foresee.

What to do about it:

1. Practice Defensive Programming: Trust nothing. Treat every input from outside your immediate scope of control—whether from a user, another service, or a database—as potentially invalid or hostile until proven otherwise. Validate data formats, check for nulls, and sanitize all inputs before processing them.
2. Design to Fail Safely: When an error inevitably occurs, ensure it does so gracefully. An invalid user action should result in a clear, helpful error message, not a cryptic stack trace or a crashed application. A failing downstream service should trigger a controlled fallback or circuit breaker, not a cascading failure that takes down your entire system.
3. Make the Right Way the Easy Way (Poka-yoke): The best way to prevent errors is to make them impossible through design. In a UI, disable the “Submit” button until the form is valid. In an API, use strong typing and non-nullable fields to make it impossible to pass invalid data. Guide the user or developer toward the correct path so that they have to go out of their way to do the wrong thing.
4. Assume Malice by Default: When designing security, assume every input is an attack. This shifts the mindset from “preventing accidental mistakes” to “defending against a determined adversary,” leading to far more resilient and secure systems.

Kerckhoffs’ Principle

A system should be secure even if everything about the system, except the key, is public knowledge

This is the foundational principle of modern cryptography and a direct refutation of “security through obscurity.” It asserts that the strength of a secure system must not depend on the secrecy of its design, its source code, or its algorithms. Instead, its security must rest solely on the secrecy of a single, small piece of information: the key. A system that is only secure because no one knows how it works is, by definition, insecure.

Why it happens (Why this principle is critical):

• Secrets Don’t Stay Secret: System designs are inevitably exposed. Source code can be leaked by insiders, reverse-engineered by competitors, or discovered by attackers. Relying on the secrecy of your method is a fragile and temporary strategy.
• Keys are Disposable; Designs Are Not: If your security depends on a secret algorithm and that algorithm is compromised, you must perform a costly and complex redesign of your entire system. If your security depends on a key and that key is compromised, you simply revoke the old key and issue a new one. This makes the system far more resilient and manageable.
• Public Scrutiny Creates Strength: The world’s most secure cryptographic algorithms (like AES and RSA) are public knowledge. They are trusted precisely because they have been subjected to decades of intense scrutiny by thousands of experts trying to break them. A proprietary, secret algorithm has never faced this trial by fire and is likely riddled with flaws.

What to do about it:

1. Assume the Attacker Has the Source Code: This should be your default mental model when designing security features. If an attacker had your complete codebase, would your system still be secure? If the answer is no, because you’ve hardcoded a secret or are relying on a hidden process, your design is flawed.
2. Never Roll Your Own Crypto: Do not invent your own encryption or hashing algorithms. Use well-known, industry-standard, and publicly vetted libraries and protocols. The security of these systems has been proven through years of public analysis; the security of your custom solution has not.
3. Isolate Secrets from Logic: Your application’s logic (the “how”) should be separate from its secrets (the “what”). The logic can be open and reviewed. The secrets—API keys, database passwords, encryption keys—must be rigorously protected.
4. Focus on Robust Key Management: Since the entire security of the system rests on the keys, their management is your most critical task. Use dedicated secret management tools (like Vault, AWS KMS, or Azure Key Vault), enforce strict and granular access controls, automate key rotation, and maintain detailed audit logs for all access.

Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure

Your software architecture will mirror your team structure. If you want microservices, organize teams around services. If you want monoliths, keep teams integrated.

Software boundaries form along lines of communication. If two teams have to file a Jira ticket and schedule three meetings to agree on an API change, they will naturally avoid creating new APIs. They’ll find ways to cram functionality into the existing, overloaded endpoints.

This law isn’t a curse; it’s a tool. It’s the basis for the “Inverse Conway Maneuver.” Want independent, scalable microservices? Create small, independent, full-stack teams, each with ownership over a specific business domain. Design your org chart to match the architecture you want.

Gall’s Law

A complex system that works has evolved from a simple system that worked

This law is a powerful argument for evolutionary design over grand, top-down creation. It asserts that you cannot successfully build a complex system in a single act of “Big Design Up Front.” The interdependencies are too numerous and the unknowns too great. All successful, large-scale systems begin as small, functional systems that incrementally grow in complexity over time, incorporating real-world feedback at each step.

Why it happens:

• The Hubris of the Whiteboard: A whiteboard diagram cannot capture the nuance and friction of reality. It ignores network latency, database contention, API versioning, and a thousand other real-world constraints. Systems designed entirely in this sterile environment are brittle and collapse upon first contact with production traffic.
• The Feedback Imperative: A simple, working system generates immediate feedback. You learn from its performance, its usage patterns, and its failure modes. This feedback is the most crucial input for guiding the system’s evolution. A “Big Design” approach operates in a feedback vacuum, guaranteeing its assumptions are wrong.
• Complexity Hides Flaws: In a complex system designed from scratch, it is impossible to know if a fundamental architectural assumption is flawed until the very end, when the cost of changing it is astronomical. An evolutionary approach validates core assumptions early and often, when the cost of being wrong is low.

What to do about it:

1. Build a “Walking Skeleton” First: Do not start by designing the entire cathedral. Start by building a simple, functioning shed. Your first goal should be to create the absolute simplest possible end-to-end implementation of your system that provides a tiny sliver of value. This might be a single API endpoint that touches the database and returns a hardcoded value. Get it deployed and working.
2. Evolve, Don’t Build: Once your simple system is working, grow it incrementally. Add one feature, one integration, or one performance improvement at a time. Ensure the system remains stable and functional after each change. This iterative process allows complexity to emerge naturally and safely, guided by real-world needs and feedback.
3. Prioritize Flow Over Features: In the early stages, your primary goal is not feature completeness but establishing a flow of value. Can you get code from a developer’s machine into production reliably? Can you monitor it? Can you get feedback? Optimizing this deployment and feedback loop is far more important than building out the perfect architecture diagram.
4. Embrace Refactoring as a Core Practice: In an evolutionary system, refactoring is not a sign of failure; it is a sign of health. As the system grows and you learn more, you will need to revisit and improve earlier design decisions. This continuous refinement is the engine of sustainable evolution, allowing you to adapt the system without starting over.

Hyrum’s Law

With a sufficient number of users of an API, all observable behaviors will be depended on by somebody

Also known as The Law of Implicit Interfaces, this is a sobering rule for anyone who maintains a public-facing system. It states that the effective contract of your API is not what you write in your documentation, but the sum of all its observable behaviors. This includes performance characteristics, the exact text of error messages, and even your bugs. If a user can observe it, someone, somewhere, will build a dependency on it.

Why it happens:

• Pragmatism over Purity: Users are trying to solve their problems as quickly as possible. If they discover that your API accidentally returns an extra, undocumented data field that saves them from making another call, they will use it. They don’t care that it’s not in the official contract; they care that it works.
• Accidental Features: What you see as a bug, a user might see as a valuable feature. For example, if an endpoint consistently returns items in a specific sorted order due to an implementation detail, users will build UIs that rely on that order, breaking spectacularly when you later “fix” it by changing the sort logic.
• The Law of Large Numbers: At scale, even the most obscure edge case will be encountered and exploited. With millions of API calls, every observable quirk of your system becomes part of someone’s critical path.

What to do about it:

1. Minimize Your Public Surface Area: The most effective defense is to expose as little as possible. Design minimalist APIs that return only the data specified in the contract. Keep implementation details (like internal methods or data structures) strictly private. If users can’t see it, they can’t depend on it.
2. Be Explicit and Strict in Your Contracts: Use strong schemas (e.g., OpenAPI, GraphQL schemas) to rigorously define your API’s inputs and outputs. This makes the intended contract machine-readable and clear. Being strict in what you return prevents accidentally exposing new behaviors.
3. Version Aggressively: When you must make a change that could violate an implicit dependency—even if it’s fixing a bug—treat it as a breaking change. Introduce the fix in a new version of the API (/v2/). This allows legacy users to continue relying on the old behavior while new users adopt the corrected version.
4. Monitor Usage Before Changing Anything: Before “fixing” any behavior, use logging and analytics to understand how your API is actually being used in the wild. You may be surprised to find that a significant number of users rely on the very quirk you intend to remove. Communication and long deprecation windows are essential.

Postel’s Law

Be conservative in what you do, be liberal in what you accept from others

Often called the Robustness Principle, this is a fundamental design guideline for building resilient and cooperative networked systems. It prescribes a two-part philosophy for communication: be absolutely precise and conformant in the data you emit, but be as flexible and tolerant as possible when interpreting the data you receive. This creates systems that are easy to rely on, yet forgiving of others’ imperfections, leading to more stable integrations overall.

Why it happens:

• Systems are Heterogeneous: In any distributed environment, you will be communicating with services written by different teams, in different languages, on different schedules. Expecting every client to perfectly adhere to your specification at all times is unrealistic and leads to brittle connections.
• Preventing Cascading Failures: A service that is overly strict in what it accepts becomes a weak link. If it rejects a request due to a trivial, non-breaking formatting error (like an extra, unknown field), it can cause a failure in the client system. A more liberal service can ignore the minor error and fulfill the request, keeping the entire workflow alive.
• Fostering Future-Proofing and Evolution: A client built to be liberal in what it accepts won’t break when a server adds new, optional fields to its response. A server that is liberal won’t break when a client sends extra context. This dynamic allows systems to evolve independently without constantly shattering their integrations.

What to do about it:

1. On Sending (Be Conservative): Adhere meticulously to your published specification. If your API contract says a field is an integer, send an integer, not a string. Do not add new fields to a response without versioning the API. Your goal is to be a predictable, reliable, and “boring” producer of data so that your consumers can trust you completely.
2. On Receiving (Be Liberal): Design your parsers and validation logic to be tolerant. Ignore unknown fields in a JSON payload rather than rejecting the entire request. If the user’s intent is clear, try to accommodate minor variations (e.g., accepting a date in a few common formats). Provide sensible defaults for any optional or missing data.
3. Know the Boundary of Liberality: This principle is not an excuse for sloppy design or accepting ambiguous input. Be liberal with formatting, but remain strict with semantics. For example, you might accept an extra, harmless field in a request, but you must firmly reject a request that is semantically invalid or could lead to data corruption (e.g., an e-commerce order with a negative quantity). The goal is robustness, not recklessness.

Adding human resources to a late software project makes it later

This classic law reminds us that software development isn’t factory work. You can’t simply throw more people at a problem and expect it to resolve faster. New team members need onboarding, coordination overhead increases, and communication complexity grows exponentially.

Why it happens:

The cost of communication and coordination doesn’t scale linearly; it scales exponentially. The number of communication channels in a team is n(n-1)/2. A team of 5 has 10 channels. A team of 10 has 45. You also have the ramp-up cost; new people are a net negative on productivity for weeks, sometimes months, as they consume the time of your existing team members.

What to do about it:

Instead of adding people to the critical path, find ways to partition the work. Can a new sub-team take on a distinct, parallelizable piece of the project? Can you descale the project’s scope to meet the deadline? Often, the best way to speed up is to remove work, not add people.

Price’s Law

In any group, 50% of the work is done by the square root number of people

This is one of those laws that feels deeply unfair, but once you see it, you can’t unsee it. On a team of 16 engineers, this law predicts that four of them will produce half of the meaningful output. On a team of 25, it’s five. It’s a power-law distribution that shows up everywhere, from academic citations to software commits.

I remember leading a 20-person platform team responsible for a critical set of internal services. We were tracking commits, pull requests, and closed tickets, and on the surface, productivity looked reasonably distributed. But when a major outage hit our authentication service, who was on the emergency call at 2 AM? The same three people who had designed it. When we needed to refactor the data model for our most complex service, who led the design review and wrote the foundational code? The same three people, plus one other senior engineer.

The other 16 people weren’t lazy—they were writing documentation, fixing minor bugs, and attending meetings. They were doing work. But the critical, high-leverage, foundational work that determined the success or failure of the platform was consistently driven by a small, core group—the square root of the team.

Why it happens:

This isn’t about some people working 10x harder. It’s about a combination of talent, experience, and, most importantly, context. The engineers who have been there longer, who have deep knowledge of the system’s quirks, and who understand the “why” behind the architecture can simply operate with more leverage. They can solve in an hour a problem that would take another developer a week of research. Their contributions are multiplicative; they unblock others and create platforms for the rest of the team to work on.

What to do about it:

Your first instinct might be to “fix” this imbalance. Don’t. You’ll never make everyone’s output equal, and trying to do so is a recipe for frustration. Instead, your job as a leader is to manage this reality:

1. Identify and Unleash: First, you have to be honest about who these people are. They are not always the loudest or the most visible. They’re the ones people turn to when they’re truly stuck. Once you’ve identified them, your primary job is to protect their time and focus. Shield them from low-value meetings and organizational drag. Point them at the gnarliest, most ambiguous problems—the ones that, if solved, create the most leverage for everyone else.
2. Raise the Median: For the rest of the team, the goal isn’t to turn them into that top tier. It’s to raise the overall team average. The best way to do this is to use your high-leverage engineers as multipliers. Have them lead mentorship programs, establish clear engineering patterns, build better tooling, and run tough but fair code reviews. Their job isn’t just to solve the hard problems, but to make it easier for everyone else to solve the medium ones.
3. Manage the Risk: This concentration of expertise is also your single biggest risk. If one of those four engineers on my 16-person team left, I didn’t just lose 1/16th of my team; I lost a much bigger chunk of its effective output. They are your biggest flight risks because they know their value. You must actively work to de-risk their departure through aggressive knowledge sharing, pair programming on critical components, and insisting on high-quality documentation for their designs. Your goal is to make their knowledge organizational knowledge, not just individual knowledge.

Ringelmann Effect

Individual members of a group become increasingly less productive as the size of their group increases

Early in my career, I was part of a four-person “tiger team” that built the first version of our company’s mobile API. We were unstoppable. We sat together, made decisions in minutes, deployed multiple times a day, and knew every corner of the codebase. We didn’t need a project manager because we could literally shout across the desk to sync up. The product was a huge success.

So, the company decided to “invest” in our success. Our team of four grew to twelve over the next six months. We were told this would triple our output. Instead, our velocity ground to a halt. Our daily stand-up, once a 5-minute huddle, became a 30-minute status report where everyone tuned out. A simple database schema change that used to be a 10-minute conversation now required a formal design review meeting with twelve people, each with an opinion. We were drowning in process, and the original magic was gone. We learned the hard way that individual productivity is not additive; in fact, it’s often subtractive in large groups.

Why it happens:

This isn’t just about communication overhead, though that’s a big part of it (see Brooks’ Law). The Ringelmann effect points to two deeper psychological factors:

• Loss of Motivation (Social Loafing): In a small group, your individual contribution is highly visible and feels critical. If you don’t do your part, the team fails, and everyone knows it. In a group of twelve, it’s easy to think, “My effort doesn’t matter as much. Someone else will pick up the slack.” Your sense of individual impact becomes diluted, so you unconsciously pull less hard on the proverbial rope.
• Diffusion of Responsibility: In a four-person team, ownership is crystal clear. If the authentication service goes down, everyone knows it’s Sarah’s code. In a twelve-person team, ownership becomes fuzzy. Is it a backend issue? A deployment script problem? Is the new guy supposed to be monitoring that? This ambiguity leads to tasks being dropped and a general lack of accountability.

What to do about it:

As a leader, you must be a bulwark against the Ringelmann Effect. The solution isn’t to work everyone harder; it’s to change the structure of the work itself.

1. Honor the “Two-Pizza Rule”: This isn’t just a cute Amazon aphorism; it’s the most effective defense against this effect. Keep your teams small enough that they can be fed by two pizzas—typically 5 to 9 people. This size is the sweet spot that maximizes skill diversity while minimizing coordination overhead and motivation loss.
2. Divide and Conquer (Intelligently): When a product’s scope grows to legitimately require more than 9 people, do not create a 15-person “super team.” Instead, split them into two or more smaller, mission-focused teams. The key is to divide them along lines of ownership, not technical layers. Create a “Search & Discovery” team and a “Checkout & Payments” team, not a “Frontend Team” and a “Backend Team.” This re-establishes clear ownership and a strong sense of mission for each smaller group.
3. Make Contributions Visible: Actively fight the dilution of individual impact. Ensure that work is clearly attributed and that successes are celebrated publicly, connecting individual efforts to team outcomes. When someone fixes a critical bug or ships a valuable feature, call it out. This reinforces the idea that every person’s contribution is seen and matters.

Cagan’s Law

We need teams of missionaries, not teams of mercenaries

A team of mercenaries is given a specification and paid to build it. Their job is to execute a plan. A team of missionaries is given a problem and empowered to solve it. Their job is to achieve an outcome. Mercenaries build features; missionaries defeat user problems. The latter consistently produces superior results because they operate with a fundamentally different level of ownership and engagement.

Why it happens:

• Ownership of Outcome: Mercenaries are accountable for output (“Did you ship the feature?”). Missionaries are accountable for the outcome (“Did we reduce churn?”). This focus on impact forces a higher level of critical thinking and creativity. The team is empowered to challenge requirements that don’t serve the goal.
• Intrinsic Motivation: Purpose is a powerful motivator. A belief in the mission creates resilience when facing inevitable technical debt, changing requirements, or project setbacks. Mercenary teams get demoralized by obstacles; missionary teams are energized by the challenge of overcoming them to reach the objective.
• Better Solutions: The engineers closest to the code often have the most insight into technical possibilities and constraints. A mercenary culture silences this, demanding adherence to a spec. A missionary culture leverages it, expecting the team to discover the best solution, not just implement the assigned one.

What to do about it:

1. Frame Work as Problems, Not Specs: Don’t hand your team a ticket that says, “Build a three-tabbed settings page.” Instead, frame the work as, “Our users are struggling to configure their notification preferences, causing frustration and support tickets. Find the best way to solve this.” Provide the context and the success metric, then let the team own the solution.
2. Connect Teams Directly to Users: Nothing builds a sense of mission faster than direct exposure to user pain and success. Have engineers sit in on sales calls, read raw support tickets, and observe user testing sessions. This creates empathy and transforms abstract requirements into tangible human problems that need solving.
3. Measure and Reward Outcomes: Shift the definition of “done.” “Done” isn’t when the code is merged; it’s when the business metric has moved. Stop celebrating “velocity” (output) and start celebrating “a 15% reduction in onboarding time” (outcome). Align the team’s definition of success with the user’s and the company’s.

Peter Principle

People in a hierarchy tend to rise to a level of respective incompetence

We promote our best engineer to be a manager, and six months later, she’s miserable, her team is adrift; we’ve lost our best engineer and gained a struggling manager. Sound familiar?

Why it happens:

The skills that make a great individual contributor (deep technical focus, solo problem solving) are often the opposite of what makes a great manager (delegation, communication, empathy, strategic thinking). We reward excellence in one role with a promotion to a completely different role.

What to do about it:

• Dual Career Tracks: Create a viable, prestigious, and well-compensated path for senior ICs (Staff, Principal, Distinguished Engineer). Promotion shouldn’t automatically mean becoming a people manager.
• Try Before You Buy: Let potential managers act as a “tech lead” on a project or mentor an intern. Give them a taste of the role before making the switch permanent.
• Train, Don’t Assume: New managers need rigorous training in coaching, feedback, and project management. Don’t just throw them in the deep end.

It always takes longer than you expect, even when you take into account Hofstadter’s Law

This isn’t a joke; it’s a fundamental truth about creative work. Software development is a process of discovery, not a predictable assembly line. You can’t perfectly estimate the time it will take to solve a problem you’ve never solved before.

Why it happens: The “unknown unknowns.” You can plan for the work you know about, but you can’t plan for the third-party API that has a critical bug, the cryptic legacy code you have to integrate with, or the security vulnerability discovered mid-sprint.

What to do about it: Stop treating estimates as promises. Use ranges instead of single numbers (“This is likely to take 3–5 weeks”). Your confidence in an estimate should be directly proportional to how much you know. An estimate for a task you’ve done ten times is reliable. An estimate for a novel R&D project is a guess. The goal is not to be right but to be less wrong over time. Embrace uncertainty and re-forecast often.

Parkinson’s Law

Work expands so as to fill the time available for its completion

This law explains the strange time-bending nature of software tasks. A feature given a two-week estimate will invariably take two weeks, filled with research, refactoring, and extensive testing. The same feature, given a hard one-week deadline, will often be completed in that week, stripped down to its essential components. The deadline itself, not the work, frequently defines the effort.

Why it happens:

• Lack of Urgency: A generous deadline removes the pressure to find the most direct path. The work is padded with lower-priority activities, such as gold-plating (adding non-essential polish), exploring tangential technical curiosities, or prematurely optimizing code that isn’t a bottleneck.
• Perfectionism as Procrastination: Without a forcing function, engineers can fall into the trap of seeking a “perfect” solution rather than an effective one. The extra time is consumed by over-engineering and handling hypothetical edge cases that provide diminishing returns.
• The “Student Syndrome”: Humans tend to start work at the last possible moment. A two-week task often sees little progress in the first week, as the perceived deadline is still far away. The real work then begins under pressure in week two.

What to do about it:

1. Use Timeboxing and Aggressive Scoping: Instead of asking, “How long will this take?”, frame the question as, “What is the simplest version of this we can ship in three days?” Fix the time, and be ruthless about adjusting the scope to fit. This forces prioritization and focuses the team on delivering value quickly.
2. Break Down Work into Smaller Quanta: Parkinson’s Law thrives on large, amorphous tasks. A three-month project will expand to fill three months. By breaking it into a series of one-week deliverables, you create multiple, smaller deadlines. This maintains a constant sense of manageable urgency and prevents work from drifting.
3. Create Artificial Deadlines for R&D: For tasks without a hard external deadline (e.g., technical debt reduction, research spikes), impose one. Give the team a fixed budget of time (e.g., “Take two days to investigate a new library and report back”). This prevents open-ended research from becoming a time sink and forces a concrete outcome.

Ninety-Ninety Rule

The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent accounts for the other 90 percent

This rule captures the painful chasm between “it works on my machine” and “it’s running reliably in production.” The initial feature development—the “happy path” where everything goes as expected—is often the fastest and most gratifying part. The final, brutal stretch involves the “invisible work” required to make software robust, secure, and maintainable. This last 10% routinely demolishes timelines and destroys morale.

Why it happens:

• Exponential Edge Cases: The happy path is one linear flow. The unhappy paths (network failures, invalid inputs, race conditions, downstream service errors) are numerous and complex. Thoroughly handling these edge cases can require more code and testing than the core feature itself.
• Integration Hell: Code that works perfectly in isolation often breaks when combined with other systems. Unforeseen conflicts, mismatched data contracts, and subtle environmental differences between staging and production create a minefield of bugs that only surface at the very end.
• The “Production-Ready” Tax: A feature isn’t done until it has proper logging, monitoring, alerting, documentation, and security hardening. This work is non-negotiable but often mentally discounted or forgotten during initial estimation, leading to a massive, unplanned effort at the end of the cycle.

What to do about it:

1. Expand Your “Definition of Done”: “Done” is not when the feature is coded. “Done” must mean it is tested, documented, monitored, and successfully deployed. Create a checklist for what “done” entails for every piece of work. This forces the “last 10%” to be considered from the beginning, not as an afterthought.
2. Integrate Continuously and Deploy Early: The longer you wait to merge and deploy code, the more painful the integration will be. Practice continuous integration to surface conflicts in small, manageable increments. Deploying to a staging environment early in the development process reveals the “production-ready” gaps when they are still cheap to fix.
3. Make the Invisible Work Visible: Do not bury the “production tax” in your estimates. Explicitly create sub-tasks for “Add logging,” “Create dashboard,” “Write integration tests,” and “Update deployment pipeline.” This makes the true cost of the feature visible to all stakeholders and ensures time is budgeted for it, rather than being a surprise.

Cohn’s Laws of Estimates

Estimates are Waste, Non-Transferable, Wrong, Temporary, and Necessary

Estimation is the great paradox of software development. It’s a practice that is simultaneously flawed at a fundamental level and absolutely essential for coordinating any non-trivial effort. Engineers resent the time spent on it and the false precision it implies, while the business cannot function without some way to forecast and plan. Mastering this paradox requires accepting its constituent truths.

Why it happens:

• Waste: The act of estimation produces zero direct value for the end-user. It is pure internal overhead—time spent debating points or days is time not spent writing code.
• Non-Transferable: An estimate is an expression of one person’s (or team’s) understanding of a problem, filtered through their specific skills and experience. The estimate made by a senior engineer cannot be handed to a junior engineer with the expectation that it will hold.
• Wrong: Because software development is a process of discovery, not manufacturing, an estimate is a prediction about an unknown future. Unforeseen technical hurdles, changing requirements, and hidden complexities guarantee that nearly every estimate will be incorrect in retrospect.
• Temporary: An estimate is a snapshot based on the knowledge available at a single point in time. The moment work begins and the first line of code is written, new information is discovered that instantly makes the original estimate obsolete.
• Necessary: Despite all these flaws, we must estimate. We need to decide if a project is viable, coordinate dependencies between teams, create roadmaps, and provide stakeholders with a general idea of when to expect new functionality. Anarchy is the only alternative.

What to do about it:

1. Use Ranges, Not Single Numbers: Stop giving single-point estimates. Instead of “five days,” say “this is likely a 4- to 10-day task.” This communicates uncertainty honestly and conditions stakeholders to think in terms of probability, not promises. The wider the range, the higher the uncertainty.
2. Focus on Relative Sizing: Instead of estimating in hours or days, use abstract story points or t-shirt sizes (S, M, L, XL). The goal is not to predict the exact duration, but to quickly determine if Task A is roughly twice the effort of Task B. This is faster (less waste) and more accurate for near-term planning.
3. Estimate Collaboratively and Just-in-Time: The people doing the work must be the ones estimating it (respecting the “Non-Transferable” law). Use techniques like planning poker to get a quick consensus. Crucially, only estimate work for the immediate future (e.g., the next sprint or two). Detailed long-range estimates are almost pure fiction.
4. Re-forecast Frequently: Treat your roadmap as a living document, not a stone tablet. Continuously update your forecasts based on the team’s actual, measured velocity and new information learned. This embraces the “Temporary” nature of estimates and builds trust through transparency, rather than by defending a known-wrong plan.

You’ll get insights into fostering a culture where experimentation isn’t just a buzzword, but the engine driving innovation and problem-solving in your software teams.

We’re talking about how autonomy and trust, when properly understood and implemented, can unlock the creative potential that’s likely dormant in your organization.

I’ve seen it in just about every company I’ve worked at: teams are itching to try new things. Seriously. That spark, that desire to poke, prod, learn, and build something better? It’s almost always there, buried under layers of process, fear, or just plain misunderstanding. What’s usually missing isn’t the will, but the way – the environment that actually lets them experiment.

And let’s be clear: for software teams, continuous experimentation isn’t some optional perk. It’s not a “nice-to-have” for a Friday afternoon. It’s a fundamental, non-negotiable requirement for tackling the gnarly, complex problems we face every day and for adapting to a landscape that changes faster than you can refresh your newsfeed.

But here’s the rub: meaningful experimentation is only truly possible when teams have a healthy dose of autonomy. And that autonomy? It’s born from two critical parents: freedom and trust.

Freedom

Now, whenever I mention “freedom,” someone in the back of the room (virtual or otherwise) inevitably shifts in their seat. I can almost hear the internal monologue: “Oh great, here we go. So, teams just do whatever they want? Pure chaos. Forget it.”

Hold on. That’s a common, and frankly, lazy, misunderstanding. Autonomy isn’t a synonym for anarchy. It’s not about developers running wild, deploying to production on a whim with untested, half-baked ideas dreamt up over a lukewarm coffee. That’s not freedom; that’s irresponsibility, and it’s a fast track to a dumpster fire.

True, productive autonomy can, and must, exist within well-defined strategic and architectural boundaries. Think of it like a jazz ensemble: incredible improvisation, individual expression, and creative exploration happen, but they happen within the shared structure of the song – the key, the tempo, the chord progression. That structure doesn’t stifle creativity; it enables it by providing a common ground and a sense of direction.

These boundaries still allow for genuine autonomy. They empower teams to explore a multitude of solutions to diverse problems, all while staying aligned with the overarching business goals and technical vision. It’s about having a defined playground, not a meticulously scripted play.

Boundaries

So, what do these “strategic and architectural boundaries” actually look like? They’re not about dictating every line of code or every UI element. They’re about establishing the wider context.

• Strategic Boundaries: These are tied to the “why.” A team experimenting with a new feature that directly contradicts a core business or technical strategy isn’t exercising autonomy; they’re just off-piste.
  • What are the company’s core objectives for this quarter? This year?
  • Which customer segments are we targeting?
  • What are the key business metrics we need to move?
  • What are our non-negotiables from a compliance or legal standpoint?
• Architectural Boundaries: These are tied to the “how” at a macro level. I remember a startup I worked at. One team, full of bright engineers, decided to rewrite a core service in Haskell. Why? Because it was “interesting.” Admirable curiosity, but it was completely disconnected from the company’s strategic need for rapid iteration with their existing Python/Go ecosystem and the available talent pool. That wasn’t an experiment within useful boundaries; it was a distraction. Clear architectural guidelines could have channeled that innovative energy into something more aligned.
  • What’s our core tech stack? (And what’s the well-reasoned process for proposing deviations?)
  • What are our security and data privacy standards?
  • What are our performance and scalability requirements?
  • Are there existing platforms or services they should leverage to avoid reinventing the wheel?

The leader’s job here isn’t to be the oracle who foresees all technical choices. It’s to articulate these guardrails. You define the sandbox, the available tools, and the ultimate goal of the castle they’re building. How they arrange the sand, what turrets they design? That’s where their autonomy shines.

Trust

This is where it gets really interesting, and often, really uncomfortable for some leaders. If we genuinely trust our teams to deliver outcomes – the results we hired them for – then we must also trust them to make the vast majority of decisions on how to achieve those outcomes.

Trust means letting go. It means consciously moving away from the comfort blanket of control and focusing your energy on communicating intent with crystal clarity, rather than issuing a never-ending stream of step-by-step instructions.

I’ll be honest, this was a tough one for me early in my management career. I’d come up as an engineer, and I knew how things “should” be done (or so I thought). My instinct was to dive into the details, to “help” by specifying the approach. The result? Teams that waited for my input, engineers who were hesitant to try something new unless I’d blessed it, and a bottleneck that had my name written all over it. It took a few painful lessons (and some blunt feedback from a brave senior engineer) for me to realize that my “help” was actually hindering.

Micromanagement, even when it comes from a place of good intentions, is a potent creativity killer. It signals a lack of trust, and when trust is absent, why would anyone stick their neck out to experiment? The safest path becomes simply doing what they’re told.

Intent Over Instructions

So, what’s the alternative to detailed directives? It’s clear, compelling intent.

Teams shouldn’t be handed a 50-page specification document detailing every button and API endpoint with the implicit message: “Build this. Exactly this.” That’s treating them like code monkeys, not the intelligent problem-solvers they are.

Instead, they should be given a clear sense of purpose.

• “We need to reduce customer churn in this segment by 10% over the next quarter.”
• “Our goal is to improve the onboarding conversion rate for new users by making the first-run experience more intuitive and engaging.”
• “We need a way to process this new data stream that allows for near real-time analytics without compromising the performance of the core application.”

Notice the difference? These statements define the problem and the desired outcome. They don’t prescribe the solution.

When intent is communicated effectively, and that foundational layer of trust is present, something magical happens: teams take ownership. They don’t just own the execution of tasks; they own the outcome. And this deep sense of ownership is precisely what ignites meaningful, purposeful experimentation. They’re not just trying things for the sake of it; they’re actively searching for the best path to achieve that clearly stated goal.

Ownership

Think about it. If you’re told exactly what to build and exactly how to build it, where’s the incentive to experiment? Your job is to follow the blueprint. But if you’re told, “We need to get to that mountain peak, and here are the constraints (time, resources, safety gear),” suddenly your brain kicks into high gear. What’s the best route? Should we try that less-traveled path? What if we combine these two approaches?

That’s ownership.

When teams are truly empowered to own the “how,” they transform from passive recipients of tasks into active, engaged problem-solvers. It’s no longer about trying to figure out what their manager thinks is the best solution. It’s about rigorously exploring the problem space and discovering what actually works.

I saw this firsthand at a SaaS company. We had a feature that was underperforming. The initial reaction from higher up was a list of “enhancements” they wanted the team to build. Instead, we pushed back (gently!) and reframed the problem: “The goal is to increase active usage of this feature by 20%. Team, how can we best achieve that within our current technical framework?”

The team dove in. They talked to users. They dug into the analytics. They brainstormed. They proposed three small, parallel experiments, each testing a different hypothesis about why usage was low. Two experiments yielded modest gains, but the third, a somewhat counterintuitive simplification of the UI, was a massive win.

They wouldn’t have found that if they’d just been implementing a pre-defined list. They found it because they owned the outcome and were free to experiment to get there.

The Payoff

When teams are truly free to experiment (within those sensible boundaries we discussed), the benefits extend far beyond just stumbling upon better solutions.

• They Learn. Rapidly. Each experiment, whether it “succeeds” or “fails” (and I use those terms loosely because all well-designed experiments yield learning), provides valuable data. This data fuels a virtuous cycle of learning and iteration.
• They Become More Scientific. Instead of endless debates based on gut feelings or who has the loudest voice, the conversation shifts. “What’s our hypothesis? How can we test it? What data do we need to gather? What did we learn?” They start to systematically compare approaches, gather evidence, and make decisions informed by that evidence.
• Debates Transform into Data Points. How many hours have been lost in meeting rooms arguing whether technique A or technique B is superior? If you’re unsure, and the cost of finding out isn’t prohibitive, don’t debate endlessly. Experiment! Build a small version of A, a small version of B, measure, and let the data guide you. This isn’t about abdicating critical thinking; it’s about augmenting it with empirical evidence.

This shift towards a more scientific, evidence-driven approach is transformative. It depersonalizes decisions, reduces reliance on “HIPPO” (Highest Paid Person’s Opinion) decision-making, and fosters a culture of intellectual honesty.

What This Actually Looks Like (And What It Definitely Isn’t)

Creating this environment isn’t about setting up a formal “Department of Experimentation” or having “Innovation Days” once a quarter (though those can have their place if done right). It’s about weaving experimentation into the fabric of daily work.

• Small, Iterative Bets: Think less “moonshot R&D project” and more “let’s try tweaking this algorithm and see if it improves performance by 2% this week.” Small, fast feedback loops are key.
• Psychological Safety is a must: If an experiment doesn’t yield the expected outcome, it’s not a “failure” to be punished; it’s a data point to be learned from. Teams need to know they can try things and “be wrong” without fear of retribution. This is probably the single hardest, yet most critical, cultural element.
• Celebrate Learning, Not Just “Wins”: Did an experiment prove a long-held assumption wrong? Great! That’s valuable learning that prevents you from going further down a dead-end path. Share those learnings widely.
• It’s Embedded, Not Isolated: Experimentation shouldn’t be the sole domain of a few senior engineers or a dedicated R&D team. Every product team, every platform team, should be thinking about how they can test their assumptions and iteratively improve.

I once worked with a C-level who thought “experimentation” meant letting one team go off for six months to build something totally new with zero check-ins. Surprise, surprise, it didn’t end well. That wasn’t experimentation; that was an uncontrolled gamble. Real experimentation is disciplined, iterative, and integrated.

Your Role: Cultivate the Greenhouse

Ultimately, building systems that allow for and encourage experimentation isn’t just about making better software. It’s about making our organizations smarter, more adaptable, and more resilient. It helps us understand our products, our users, and even ourselves as an organization much more deeply.

As a leader, your primary role isn’t to have all the answers or to dictate the path. It’s to be the chief gardener. You create the conditions – the fertile soil of trust, the clear sunlight of intent, the protective boundaries of strategy and architecture – in which your teams can grow, explore, and blossom. You provide the water and nutrients (resources, support, removal of obstacles), but the specific shape and beauty of what grows? That comes from them.

So, take a look at your teams, your processes, your own leadership style. Where can you inject a bit more freedom? How can you build more trust? How can you clarify intent instead of just issuing instructions?

What’s one small experiment you can run this week to start fostering a more experimental culture in your own patch?

It’s not just a little broken. It’s leaning-tower-of-Pisa broken, and the ground is getting softer thanks to our new AI overlords-in-training.

The Great LeetCode Hamster Wheel

Remember spending, what, 100, 200 hours grinding LeetCode problems? I sure do. Nights and weekends sacrificed to the gods of Big O notation, praying you’d recognize the pattern for that one obscure dynamic programming problem the interviewer pulls out. You memorize dozens, hundreds of patterns, hoping the two you get asked in a 45-minute pressure cooker match something you crammed.

The argument goes: “Hey, if it potentially doubles your salary, 200 hours is a killer ROI!” And sure, on paper, maybe. But that logic conveniently ignores the fact that acing a contrived puzzle tells you almost nothing about whether someone can actually build software people want to use. Or worse, whether they can keep the ridiculously high-paying job they just landed. I’ve seen brilliant LeetCode ninjas arrive on the job and struggle to understand basic application architecture or collaborate effectively. The ROI calculation suddenly looks a lot less rosy then, doesn’t it?

The LeetCode Arms Race Is Getting Worse

As Chungin Lee demonstrated, LeetCode interviews have become even more pointless in the AI era. These problems are now trivially solvable by AI systems, making them perhaps the least valuable skill to test for in human engineers.

I’ve watched countless colleagues spend 100–200 hours preparing for FAANG interviews. That’s five full workweeks grinding through hundreds of algorithmic problems for an interview where they might face just one or two challenges.

According to recent research, the technical bar for interviews has risen “approximately one standard deviation higher” in 2025, with LeetCode “hard” problems now becoming the norm at places like Google. As one senior engineer put it: “I used to think that LeetCode ‘hard’ problems were never asked at Google. Now they seem to have become the norm.”

You Won’t Use These Skills in Real Life

Unless you work on specialized teams building low-level algorithms, you simply won’t use most of these skills outside of interviews.

In my 15+ years building software products, I’ve needed to implement a binary search from scratch exactly zero times. Why? Because every modern programming language already has battle-tested implementations of these algorithms in their standard libraries.

What LeetCode interviews actually test is:

• Your willingness to endure pointless hazing rituals
• Your privilege to have free time for studying
• Your pattern recognition skills for a very specific type of problem
• Your capacity to perform under artificial pressure

None of these correlate strongly with on-the-job performance for most software roles. Worse, this focus on algorithm puzzles represents a massive opportunity cost – the time you spend watching a candidate sweat over “Maximal Square” is time you’re not assessing their ability to read and understand code, communicate trade-offs, or debug realistic issues.

Skills for the Interview, Not the Job

Let’s be brutally honest. Unless you’re one of the lucky few working on hyper-optimized search algorithms or low-level graphics rendering, how often are you really implementing a custom K-Means clustering algorithm or manually balancing a red-black tree in your day job?

In my couple of decades slinging code and leading teams, the answer is basically never. When I need a sophisticated algorithm, I use a battle-tested library written by people far smarter and more specialized than me (or now, maybe an AI suggests one). The only times I’ve really dusted off those deep algorithm skills were:

1. For fun, on a rainy Sunday because sometimes puzzles are genuinely engaging without the Sword of Damocles (a job offer) hanging over your head.
2. Cramming for the next soul-crushing interview cycle.

It’s a skill set largely divorced from the reality of modern application development. We incentivize learning it purely to jump through an artificial hoop.

And here’s the kicker: your interview time is finite. Precious, even. You’ve got maybe 45-60 minutes per interviewer slot. If you spend 30-40 minutes watching a candidate sweat over “Maximal Square” or “Merge k Sorted Lists,” just think about what you aren’t learning about them.

In that same half hour, you could have been assessing:

• How they approach breaking down a small, realistic feature request.
• Their ability to read, understand, and critique a piece of existing (maybe slightly flawed) code.
• How they communicate trade-offs when discussing different technical approaches.
• Their thought process for debugging a non-trivial issue.
• Whether they can write code that isn’t just correct for the puzzle, but also maintainable and understandable by other humans.
• Their grasp of testing principles.
• How they handle ambiguity or ask clarifying questions.

You’re actively choosing not to gather signals on these critical, day-to-day engineering skills. Instead, you’re using that irreplaceable time slot to see if they memorized the trick for finding the longest palindrome. Is that really the best use of everyone’s time? It feels like using a Formula 1 car to deliver a single pizza across the street – impressive in one very specific, irrelevant way, and wildly inefficient for the actual task at hand.

This isn’t just about LeetCode being potentially irrelevant; it’s about the opportunity cost. By focusing on these abstract puzzles, we are actively neglecting to assess the very skills that usually determine success on the job.

So, What Are We Actually Testing?

If LeetCode isn’t testing job-relevant coding skills for most roles, what is it testing?

The charitable interpretation is that it tests raw problem-solving ability and CS fundamentals. Okay, maybe partially. But under extreme time pressure and anxiety? It mostly tests pattern recognition derived from hours of dedicated practice. It signals preparation and, maybe, a certain kind of grit – the willingness to endure something unpleasant and difficult to achieve a goal.

Is persistence valuable? Absolutely. Is this the best, or only, way to gauge it? Hell no. We could probably get a similar signal by asking candidates to assemble complex IKEA furniture blindfolded, but we don’t (though maybe we should?).

The less charitable view? It’s intellectual hazing. A shibboleth. A way for interviewers (often unconsciously) to feel smart by asking questions they themselves might struggle with if they hadn’t just reviewed the solution. It heavily favors people with the free time and resources to grind, potentially excluding brilliant candidates who have other life commitments or simply don’t test well under “gotcha” pressure (hello, neurodivergent colleagues).

Enter the Algorithm-Solving Robots

And now, AI. Models like ChatGPT and dedicated coding assistants can often spit out correct, optimized LeetCode solutions faster than a human can type. If the task is so easily automated, why is human proficiency at it the gold standard for entry? It’s like testing cashiers on their ability to do long division by hand in the age of calculators.

This should be a wake-up call. The least valuable work a human engineer does is the stuff easily replicated by a machine. Our value lies higher up the stack: in understanding context, dealing with ambiguity, designing robust systems, collaborating with squishy humans, making trade-offs, and turning fuzzy business needs into working software. Interviews should focus there.

The Missing Middle: Where Most of Us Actually Live

Software development isn’t a binary choice between writing arcane algorithms and drawing high-level system diagrams on a whiteboard. There’s a vast, crucial middle ground: application development.

This is where most engineers spend their careers. It involves translating requirements, choosing frameworks, writing maintainable code, integrating APIs, setting up CI/CD, debugging tricky concurrency issues, managing state, and a thousand other things that LeetCode barely touches.

Yet, look at a typical FAANG-style interview loop: maybe two algorithm rounds, one system design round. Where’s the part that actually tests if you can, you know, build the application? The assumption seems to be that if you can invert a binary tree and sketch a simplified Twitter architecture, you must be great at everything in between.

That assumption is deeply, demonstrably flawed. It’s magical thinking.

What Algorithm Interviews Actually Signal

Let me be crystal clear: algorithm interviews signal exactly one thing:

You practiced algorithmic challenges enough to recognize their patterns and solve them under pressure.

That’s it. They don’t signal general development skills, problem-solving abilities in ambiguous situations, or your capacity to turn business requirements into working software. They signal pattern recognition and preparation.

In my experience running engineering teams, the strongest correlation with successful hires has nothing to do with their ability to solve algorithm puzzles. It’s their track record of shipping real products, working well with others, and learning continuously.

Okay, But What’s The Alternative?

Look, I don’t have all the answers, and anyone who claims they do is probably selling something. But we can do better than abstract puzzles. The core idea isn’t revolutionary: test skills that are actually relevant to the job.

Instead of LeetCode mediums, consider interview formats that give signals on:

1. Requirement to Code: Give a small, realistic business problem. How does the candidate clarify requirements? How do they translate that into a basic code structure?
2. Code Comprehension & Debugging: Provide a moderately complex (but not intentionally obfuscated) piece of existing code with a subtle bug. Can they read it, understand it, and track down the issue? This is 90% of the job sometimes.
3. API Integration / Usage: Ask them to interact with a simple, fake API. Can they handle requests, responses, errors gracefully?
4. Practical Design Choices: Discuss trade-offs. “We need a background task queue. Should we use Redis, RabbitMQ, or build something simple in-process? Why?” This reveals practical architectural thinking.
5. Refactoring: Give them a slightly messy but functional piece of code. Ask them to improve its readability, maintainability, or perhaps performance, explaining their reasoning.
6. Collaborative Problem Solving: Pair programming on a small, realistic feature. How do they communicate? How do they handle feedback or disagreements?

These aren’t perfect, and they require more thoughtful preparation from the interviewer. But they give much stronger signals about the skills required for day-to-day software development. Resources like CodingChallenges.fyi offer more realistic problems than typical algo puzzles.

So, Should I Just Burn My Algorithms Textbook?

Hold on, not so fast. Understanding Data Structures and Algorithms is important. It forms the foundation. Knowing Big O helps you spot inefficiencies not just in tight loops, but in system interactions too. Understanding tradeoffs between, say, a hash map and a list is crucial for writing performant code. You can’t build solid houses without knowing about foundations, load-bearing walls, and maybe not making the roof out of solid lead.

The problem isn’t learning DSA. The problem is using high-pressure, timed, abstract algorithm puzzles as the primary filter in interviews. But this doesn’t mean we throw the baby out with the bathwater and stop assessing foundational knowledge altogether. We absolutely should check if a candidate understands the tools they’re using.

We can, and should, probe this understanding within the context of more realistic interview exercises. For instance:

• During a code review or refactoring task: “I see you chose a List here to store these items. What are the performance characteristics if this collection grows to millions of entries, and we need to frequently check if an item exists? Would another data structure potentially be more efficient? Why?” This gets at complexity understanding without a contrived puzzle.
• While discussing their proposed solution to a feature: “Okay, you’re proposing this loop nested inside another loop to process the data. Can you talk me through the time complexity of that approach? Is it O(n), O(n^2), something else? How might that scale?” Again, analyzing their relevant code.
• Deeper dives on language specifics: “You’re using a Python dict (or a Java HashMap, etc.) extensively here. Can you briefly explain how that works under the hood? Why is lookup typically so fast? Are there any edge cases where performance might degrade?” This tests deeper knowledge relevant to the tools they’d actually use.

These kinds of questions, woven into a discussion about actual code or system design relevant to the job, give you valuable signals about a candidate’s foundational understanding. It tests if they can apply the concepts, not just regurgitate a memorized solution to “Merge k Sorted Lists” while their palms are sweating.

So, learn the fundamentals, absolutely. Understand complexity. But do it for your own growth, when you have the time and space to actually internalize it, not just cram patterns for an interview. And as interviewers, let’s test that understanding in ways that reflect how it’s actually used on the job.

The Bitter Pill: Sometimes You Still Gotta Dance

Now, the reality check. Am I saying you should just refuse all LeetCode interviews on principle? If you have that luxury, maybe. But for most people seeking jobs at companies that still use this process (and let’s face it, that’s a lot of them), you might just have to play the game.

If the job you want requires passing a LeetCode gauntlet, then you need to prepare for that gauntlet. It stinks, but rent doesn’t pay itself. Do what you need to do. (There are plenty of resources out there, the original text even lists some).

The Market Is Bifurcating, But Change Is Coming

The paradox of 2025’s tech market is that we’re witnessing a bifurcation not just in opportunities, but in interview practices as well.

For engineers in AI and ML, the market resembles the 2021 boom – multiple offers, aggressive compensation, and expedited processes. One Bay Area staff engineer specializing in AI infrastructure reportedly received an offer from Meta exceeding $1 million in total compensation. But for engineers in “core domains” like frontend, backend, and mobile, the picture looks drastically different.

Similarly, Big Tech companies are doubling down on traditional interview formats while smaller companies innovate with more practical assessments. As one FAANG head of recruiting admitted: “The inertia of these processes is enormous. These companies have built entire recruiting machines around their current processes, with years of calibration data.”

What we’re witnessing is an inversion of historical patterns: for the past decade, interview practices pioneered by Google trickled down to smaller companies. Now, innovation is bubbling up from more agile organizations, with Big Tech watching from behind.

Let’s Fix This Mess

My goal here isn’t just to rant (okay, maybe a little). It’s to push for change. As leaders, as interviewers, as engineers, we shape the hiring culture. I don’t use LeetCode-style questions in my interviews anymore unless the role specifically demands deep algorithmic expertise (which is rare).

If you’re designing an interview process, think critically about what skills you actually need for the role. Is it puzzle-solving under pressure, or is it building, debugging, and maintaining real-world software? Optimize your interview process to test for that.

Stop cargo-culting hiring practices just because Google or Meta does it. Let’s value the skills that actually matter, not just the ones that are easiest to quantify with a pass/fail on a coding puzzle. Cut it out.

Look, the hard truth is that technical excellence alone won’t get you a seat at the table where important decisions happen. You can architect beautiful systems all day long, but if you can’t translate that work into business impact using language leadership understands, you’re screwed.

I spent years nodding along in meetings while secretly Googling acronyms under the table. What a waste of time. The reality is that this stuff isn’t actually complicated – it’s just deliberately obscure to maintain the MBA industrial complex.

So here’s my gift to you: 20 business terms explained in plain language that will make you dangerous in budget meetings. No MBA required.

Revenue Metrics

Let’s start with how companies track their income:

1. ARR (Annual Recurring Revenue)

This is the holy grail metric that VCs obsess over. Take the money customers pay you every month, multiply by 12, and voilà – ARR. $10k MRR = $120k ARR. It’s that simple. If your customers are paying yearly, it’s even simpler. Unlike that distributed consensus algorithm you’re debugging, this math actually IS straightforward. ARR is one of the predictors of “will we all have jobs next year?” so pay attention.

2. MoM (Month-over-Month Growth)

The percentage your metrics went up (hopefully not down) since last month. 10% MoM growth sounds cute until you realize that compounds to ~3x yearly. That’s the difference between “we’re raising another round” and “we’re updating our LinkedIn profiles.” YoY (Year-over-Year) is the same but for years, for when your growth is too depressing to look at monthly.

3. NRR (Net Revenue Retention)

Measures revenue growth from existing customers, including upsells and churn. Over 100% means you’re growing without adding a single new customer – basically printing money. Below 100% means you’re in a leaky bucket, and no amount of new customers will save you. Investors will pay multiples for 120%+ NRR because it means your product isn’t garbage.

4. GRR (Gross Revenue Retention)

Unlike its sexier cousin NRR, GRR ignores upsells and only measures if customers are sticking around. If 9 out of 10 customers bail, but the last one doubles their spend, your NRR looks great (congrats on growing!), but your GRR is a horrifying 10% (everyone hates you). Good GRR means your product is sticky; good NRR means you’re also extracting more value. You want both.

Cost Metrics

Now let’s look at how costs are categorized:

5. COGS (Cost of Goods Sold)

This is what it ACTUALLY costs you to deliver your service – the “if we add one more customer, these costs go up” stuff. For software companies, this includes cloud infra directly tied to usage, support people who handle tickets, and those third-party APIs you’re praying don’t jack up their prices.

Here’s the part most engineers miss: Not ALL your AWS bill is COGS. That k8s cluster you’ve overprovisioned that could handle 10x your current load? The base cost isn’t COGS because it doesn’t scale with each new user. But the S3 storage that grows with user data? Pure COGS. This distinction matters because gross margins depend on it, and VCs obsess over gross margins.

6. OpEx (Operating Expenses)

Everything else you’re burning money on: your salary, that fancy office nobody wants to commute to, the marketing team’s budget for branded socks. Basically, stuff you could theoretically cut without immediately turning off the service. I say “theoretically” because we’ve all seen what happens when companies take this too literally – just look at the “Twitter experiment” where they fired 80% of staff and somehow the site still (mostly) runs — for now…

7. CapEx (Capital Expenditures)

CapEx is what you spend on stuff you could theoretically sell later – physical assets like servers, buildings, or that ping pong table nobody uses anymore. Unlike the money you burn on SaaS subscriptions or salaries, CapEx gets “depreciated” over time, meaning the accountants pretend it loses value gradually rather than being an immediate expense. Yes, this matters for taxes and balance sheets. No, you probably don’t need to care unless you’re running the company.

When you spend money on COGS (Cost of Goods Sold) and OpEx (Operating Expenses), that money is gone – it’s a pure expense that you can’t recover.

But purchasing something like a car works differently. The car is an asset you own. If you decide to sell it after 2 years, you’ll get some money back. However, the car’s value typically decreases over time. That decrease in value is called depreciation, and it’s calculated as part of the OpEx for each year you own the asset.

8. Burn Rate

The speed at which your company is setting money on fire. If you’re spending $250K monthly but only bringing in $50K, you’re burning $200K per month. With $1M in the bank, your runway is 5 months. After that, it’s game over – no more payroll, no more free snacks, no more jobs. This is why founders look increasingly haunted as the runway shortens. When an exec starts talking about “focusing on efficiency,” they’re telling you the burn rate is terrifying them.

Profitability Metrics

How do we measure if a business is actually making money?

9. Gross Margin

After you deliver your service, what percentage of revenue do you actually keep? That’s gross margin. Take your revenue, subtract COGS, divide by revenue, and you get your gross margin percentage. If you make $1M and spend $500K on direct costs, you’ve got a 50% gross margin.

This number varies WILDLY by industry. Hardware companies like Tesla (18%) and driver-dependent services like Uber (33%) have brutally low margins because physics and humans are expensive. Meanwhile, SaaS companies like Figma are printing money at 90% margins because bits are basically free to copy. This is why VCs throw money at software and not hardware – software margins are pornographic by comparison.

OpenAI is a fascinating case with negative gross margins – they’re literally paying for you to use their service. Not a strategy I’d recommend unless you have Sam Altman’s Rolodex of investors.

10. Net Margin

Gross margin is a lie – it pretends your engineers and office space are free. Net margin tells the real truth by accounting for ALL your expenses. Figma might have 90% gross margins, but if they’re blowing billions on marketing, their net margin could still be negative. This is the “are we actually making money or just shuffling VC cash around?” metric.

11. EBITDA (Earnings Before Interest, Taxes, Depreciation, and Amortization)

The most obnoxious acronym in finance, and finance loves acronyms. EBITDA is basically “how profitable would we be if we ignored all this annoying accounting stuff?” It strips out interest payments, taxes, and how quickly your assets lose value.

Why this nonsense metric? Two reasons:

1. It lets you compare companies that have different tax situations or debt levels
2. It’s a way for unprofitable companies to pretend they’re almost profitable.

When a company trumpets they are “EBITDA positive,” translate that to “we’re not actually profitable, but we’re getting closer, please don’t sell our stock.”

12. Default Alive/Default Dead

Paul Graham’s brutal binary: based on current growth and burn rate, will your company reach profitability before running out of money? Default alive startups can breathe – they’ll survive even if the VC money printer stops. Default dead startups are in a race against the clock, desperately trying to grow faster or cut costs before the cash runs out.

This is why the “move fast and break things” era is ending – companies with insane burn rates, but mediocre growth are realizing they’re default dead. No amount of ping pong and cold brew will save them.

On the other hand, a startup might have a high burn rate, but if it has healthy growth and good margins, it might reach a break-even point before it runs out of cash.

Customer Metrics

How do we track customer behavior and satisfaction?

13. CAC (Customer Acquisition Cost)

How much cold, hard cash does it take to acquire one paying customer? If you’re blowing $50K on Google ads and landing 500 customers, that’s $100 CAC. This is the metric that exposes the “growth at all costs” lie – any idiot can buy growth by setting money on fire in the Google and Facebook ad engines. Companies with long-running astronomical CAC are just doing customer acquisition wrong, full stop.

14. LTV (Lifetime Value)

How much revenue will a customer generate before they inevitably leave you? If customers pay $100/month and stick around for 14 months on average, that’s $1,400 LTV. This is pure financial modeling, not reality, but investors will judge you on it anyway.

The golden ratio is LTV:CAC, and you want at least 3:1. Spending $1,300 to acquire a customer worth $1,400 means you’re basically breaking even after COGS and OpEx – congrats on building a sophisticated money-laundering operation! At 4:1 or higher, you’ve got a real business. But if it’s too high (like 10:1), you’re probably not aggressive enough on growth and leaving market share on the table.

15. Retention

Are your customers sticking around or running for the exits? Measured as the percentage that stay with you month-over-month or year-over-year. What “good” looks like varies wildly – B2B SaaS might expect 98%+ monthly retention, while consumer apps would kill for 40%.

Know your industry benchmarks, or you’ll either panic needlessly or miss catastrophic problems.

16. Churn

Retention’s evil twin. If 5% of users bail each month, that’s 5% churn. Sounds small until you do the math and realize you’re losing 46% of your customers yearly. Compounding works against you here – a seemingly modest monthly churn can mean you’re replacing your entire customer base annually. Not great for that LTV formula!

17. NPS (Net Promoter Score)

The “how much do users love us” vanity metric based on a single question: “On a scale of 0-10, how likely are you to recommend us?” Customers scoring 9-10 are “Promoters” (they love you), 7-8 are “Passives” (meh), and 0-6 are “Detractors” (they actively hate you). NPS = % Promoters – % Detractors.

If 40% love you, 30% are neutral, and 30% are writing angry tweets about you, your NPS is 10%. Anything above 0 means more people love than hate you – congrats on clearing that low bar! Above 30% is genuinely good. But remember: customers lie on surveys and happy customers don’t respond, so take NPS with a massive grain of salt.

Real behavior > survey responses.

Strategic Frameworks

Finally, let’s look at how businesses think about their strategic position:

18. AARRR Framework (Pirate Metrics)

The “pirate metrics” framework (because it sounds like “arrr!”) breaks down what actually matters in your product lifecycle:

• Acquisition: How do users find you?
• Activation: Do they have that “holy shit, this is awesome” moment?
• Retention: Do they stick around or ghost you?
• Revenue: Do they pay you actual money?
• Referral: Do they tell friends or keep you as their dirty little secret?

The brilliance is in knowing where your biggest problem lies. Building cool new features for a product nobody discovers is pointless. Adding monetization before users see value is predatory. As an engineering manager, if your team is building “engagement features” when your activation funnel is broken, you’re rearranging deck chairs on the Titanic.

Fix the biggest leak first.

19. TAM (Total Addressable Market)

The theoretical ceiling of how big your business could get if you captured literally every potential customer. It’s the “we’re only capturing 1% of a $10B market!” slide in every pitch deck ever.

VCs obsess over TAM because they need massive returns, not cute lifestyle businesses. TAM is mostly bullshit math – take a huge market, claim some percentage of it could use your product, and voilà.

But if your TAM is genuinely tiny, no amount of execution can create a unicorn. You can’t be the world’s best buggy whip manufacturer when cars exist.

20. Moat

What stops a competitor from copying everything you do and eating your lunch? That’s your moat. Network effects, proprietary data, switching costs, brand loyalty – these are modern moats. In the AI era, data moats are becoming even more critical – the company with the most user data to train on wins.

If your company doesn’t have a clear moat, you’re in trouble. Engineers often think technical sophistication is a moat, but unless you’re doing quantum computing, it probably isn’t – someone will reverse-engineer your approach. Great UX isn’t a moat either unless it’s backed by uniquely deep user understanding.

If you can’t articulate why customers would stay with you even if a cheaper alternative appeared, you don’t have a moat.

Will This Make You Better at Your Job? Absolutely.

Holy hell, we’ve only scratched the surface here. There’s a whole universe of funnel metrics, cohort analysis, cap tables, and other corporate hieroglyphics that business folks throw around. But this covers the crucial 20 that have repeatedly saved my ass when advocating for my team.

Look, I’ve watched brilliant technical leaders get steamrolled in planning meetings because they couldn’t articulate how their work impacted the metrics the company actually cares about. Don’t be that person.

Next time you hear a term you don’t understand, write it down, look it up later, and add it to your arsenal. Do yourself a favor though – don’t pretend to know something when you don’t. Just ask. “I’m not familiar with that term – could you explain it?” works wonders and actually builds respect. Most people are making half this stuff up anyway.

The moment you start connecting your team’s work to metrics like gross margin or COGS reduction, you’ll watch executive eyes light up. Your boring refactoring project suddenly becomes a strategic initiative that “addresses technical debt to maintain our gross margin as we scale.” Same work, completely different reaction.

Then we killed it before release.

Why? Because while we’d built exactly what I specified, I had never clearly articulated why we were building it. The team executed flawlessly against requirements that, as it turned out, solved the wrong problem entirely.

Had I simply started with a clear “why,” someone would have spotted the disconnect months earlier.

The Missing Purpose Epidemic

This scenario plays out constantly across our industry. Teams build features, products, and entire systems without a clear understanding of the purpose behind them.

The symptoms are everywhere:

• Engineers implement requirements without questioning odd specifications
• Product interfaces become cluttered with rarely used features
• Technical decisions optimize for the wrong constraints
• Teams celebrate shipping rather than solving the core problem

One study found that up to 64% of features in custom-built software are rarely or never used. This isn’t an engineering failure—it’s a purpose clarity failure.

The Justification Test

I now apply a simple test to every project: Can everyone involved complete this sentence in nearly identical ways?

“We are doing this because _____.”

When I’ve run this exercise with teams, the results have been shocking:

• A data migration team gave 7 different answers
• A feature team couldn’t articulate any concrete user benefit
• A platform team described an entirely different set of priorities than leadership had intended

If your team can’t align on why they’re doing something, they’re not aligned on what they’re really building—regardless of how detailed your specifications are.

The Purpose Cascade

A clear “why” creates a purpose cascade that transforms how teams operate:

Clear Why → Aligned Priorities → Better Decisions → Appropriate Solutions

When my teams have a rock-solid understanding of purpose:

• They question requirements that don’t serve the core goal
• They propose simpler solutions I hadn’t considered
• They make better technical tradeoffs without my input
• They measure success by problem solved, not features shipped

The “Why” Deficit

If this is so obvious, why do so many leaders skip it?

In my experience, three factors drive this deficit:

1. Assumption of obviousness: “Surely everyone understands why we’re doing this?”
2. Fear of scrutiny: A clear purpose invites questions about whether this is the best approach
3. Purpose uncertainty: The leader themselves isn’t entirely clear on the underlying why

The last point is particularly common. Many projects exist because someone important wants them, not because they serve a clear purpose. Without the courage to clarify purpose, teams execute on proxy metrics instead.

The Clarity Checklist

Before kicking off any significant effort, I now ensure I can clearly articulate:

1. The problem being solved: What specific pain point or opportunity are we addressing?
2. The impact of solving it: How will we measure success in business or user terms?
3. The cost of not solving it: What happens if we do nothing?
4. The beneficiaries: Who specifically will benefit and how?
5. The non-goals: What related problems are we explicitly NOT trying to solve?

If I can’t answer these questions in simple language, I’m not ready to ask a team to invest their time and talent.

Communicating Purpose Effectively

Beyond having clarity yourself, how you communicate purpose matters deeply:

• Use human terms, not business jargon: “Help users find answers faster” beats “Increase engagement metrics”
• Connect to concrete user stories: “Jane spends 30 minutes per day on this tedious task” is more compelling than “Users waste time”
• Explain the why before the what: Purpose first, specifications second
• Repeat constantly: Purpose isn’t a one-time announcement—it requires regular reinforcement

I’ve found the most effective approach is having the team itself articulate the why back to me. If they can’t, that’s my failure, not theirs.

The Permission Effect

Perhaps the most powerful outcome of purpose clarity is what I call the permission effect: When teams understand the why, they feel empowered to challenge the how.

My most successful projects weren’t executed exactly as I envisioned—they were improved by teams who understood the purpose well enough to find better approaches than I had conceived.

Without a clear why, teams focus on compliance with specifications. With a clear why, they focus on solving the actual problem—which is what we really want.

The Leadership Obligation

You can delegate execution. You can even delegate decisions. But you cannot delegate purpose clarity.

If you can’t clearly articulate why a project matters, don’t expect your team to figure it out through osmosis. They’re talented, but they’re not mind readers.

Start with why. Everything else follows.

• Motivational speakers at quarterly all-hands
• Inspirational quotes painted on walls
• Recognition programs with elaborate point systems
• Surprise team-building activities

Besides being the most toxic place I’ve worked at so far, in one year, our engineering velocity dropped 40%.

Motivation without systems is like revving an engine with no wheels.

The Motivation Industrial Complex

The corporate world has created an entire industry around employee motivation – an endless stream of hacks, incentives, and psychological tricks to squeeze more effort from teams.

It’s mostly garbage.

I’ve managed teams across five companies, and I’ve reached an uncomfortable conclusion: Systems beat motivation. Every. Single. Time.

Here’s why: Motivation is fickle, systems are reliable.

The Energy Tax

Every obstacle in your workflow creates what I call an “energy tax” – a psychological cost paid before any actual work happens.

When an engineer faces:

• A test environment that’s perpetually broken
• Ambiguous requirements that change mid-sprint
• Development environments that take days to set up
• Approvals that bottleneck through unavailable people

…their motivation gets spent before they write a single line of code.

No amount of inspirational speeches can overcome dysfunctional systems.

The System Advantage

Systems aren’t sexy. They don’t make for inspirational LinkedIn posts. But they’re the backbone of high-performing teams.

In my most successful leadership role, we obsessed over systems:

• Deployment pipelines that worked reliably
• Clear decision frameworks everyone understood
• Documentation that actually reflected reality
• Onboarding that got people productive in days, not weeks
• Feedback mechanisms with genuine follow-through

The result? We didn’t need motivation hacks. The team stayed energized because their energy went into meaningful work, not fighting broken processes.

The Reliability Test

Here’s a simple test: When a new team member joins, how much of their success depends on:

A) Finding the right people to ask for help B) Following documented, reliable processes

If it’s mostly A, you don’t have systems – you have tribal knowledge dressed up as a workflow.

Systems vs. Bureaucracy

Now, a warning: Systems aren’t bureaucracy.

Systems reduce cognitive load and increase predictability. Bureaucracy does the opposite.

I’ve seen well-meaning leaders try to “systematize” by creating elaborate processes that actually make things worse. That’s not what I’m advocating.

Good systems are:

• Documented simply
• Followed consistently
• Improved continuously
• Designed to remove friction, not add control

The Maintenance Mindset

The hard truth about systems is they require maintenance. They’re not “set it and forget it.”

This is where many leaders fail. They implement a system, declare victory, then focus on the next shiny initiative. Six months later, the system is obsolete or ignored.

Effective leaders build in system maintenance as a core activity, not an afterthought. They recognize that keeping systems relevant is as important as creating them in the first place.

The Real Motivator

Want to know the most powerful motivator I’ve found in 15 years of leadership?

Progress without drama.

When teams can make consistent progress without heroics, crisis management, or confusion, intrinsic motivation follows naturally.

Systems create the conditions for this kind of progress. Motivation hacks merely disguise the systemic problems preventing it.

Where to Start

If you’re leading a team drowning in motivation initiatives but starving for functional systems, start here:

1. Map one critical workflow end-to-end
2. Identify the three biggest friction points
3. Fix them ruthlessly
4. Document the improved process
5. Repeat

No motivational speaker required.

Your team doesn’t need another inspiring talk or recognition program. They need systems they can trust. Build those, and motivation will take care of itself.

“I’m such a valuable manager,” I thought. “They can’t function without me.”

Then my boss gave me a brutal reality check: “You’re not creating a team. You’re creating dependents.”

That conversation changed everything. I realized I wasn’t the hero—I was the bottleneck.

The Problem with Problem-Solving

Every time you solve a problem for your team, three things happen:

1. You reinforce that problems should flow to you
2. You deny someone the opportunity to grow through solving it
3. You add to your own cognitive load

As I analyzed my calendar, I discovered I spent 75% of my time solving problems that my team members could have handled themselves—if only I’d let them.

The math was unsustainable: As the team grew, so did my problem backlog. I couldn’t scale.

The Coaching Alternative

The alternative sounds simple but requires discipline: Stop solving problems. Start coaching others to solve them.

When a team member brings you a problem, resist the urge to provide the answer. Instead:

1. Ask what they’ve tried so far
2. Guide them with questions, not solutions
3. Help them develop their approach, not adopt yours
4. Support their implementation, even if it differs from what you’d do

The first few times I tried this, it felt agonizing. I could see the solution so clearly! Surely it was more efficient to just tell them?

But when I measured outcomes over time, the coaching approach consistently outperformed direct problem-solving:

• Solutions were better tailored to the implementer’s skills
• Team confidence and self-sufficiency increased
• Similar problems stopped appearing on my desk
• My workload became manageable

The Questions That Unlock Growth

I’ve developed a simple framework of questions that transform me from problem-solver to coach:

• “What would you do if I weren’t available?”
• “What’s the worst that could happen with your approach?”
• “How would you break this down into smaller decisions?”
• “What information are you missing to decide?”
• “What’s stopping you from moving forward?”

These questions force critical thinking without providing answers. They build problem-solving muscles rather than dependency.

The Decision-Making Spectrum

Not all problems should be coached, of course. I use a simple spectrum to determine my approach:

Decide: High-stakes, time-sensitive issues requiring your authority or expertise. Rare.

Advise: Complex problems where they lead but benefit from your guidance. Occasional.

Coach: Problems within their capability that build critical skills. Frequent.

Delegate: Routine decisions they should own completely. Most common.

The mistake most managers make? We spend too much time in “Decide” mode when we should be operating primarily in “Coach” and “Delegate.”

Building the Problem-Solving Muscle

Coaching isn’t just asking questions—it’s systematically building problem-solving capacity:

1. Start with smaller problems where failure has low consequences
2. Gradually increase complexity as confidence grows
3. Provide safety nets rather than solutions
4. Celebrate attempts, not just successes
5. Debrief the process, not just the outcome

When I implemented these practices, my team’s problem-solving capabilities improved dramatically. Problems that once required my involvement became routine matters they handled independently.

The Leadership Paradox

The ultimate paradox of leadership: The less your team needs you for day-to-day problem-solving, the more effective you are as a leader.

Your value isn’t measured by how many problems you solve, but by how many problems your team can solve without you.

I now judge my success by a simple metric: How many decisions happen without my involvement that I completely support?

The higher that number, the better I’m doing my job.

Your New Superpower

The next time someone brings you a problem, resist the hero urge. Don’t swoop in with solutions. Instead, take a breath and ask, “What do you think we should do?”

Then listen. Guide. Coach.

Your superpower isn’t having all the answers. It’s developing a team that can find them without you.

“Tell me about your performance management approach,” I replied.

“That’s not the issue,” he insisted. “We just hired the wrong people.”

After twenty minutes of discussion, a pattern emerged: unclear expectations, inconsistent feedback, and a culture that avoided difficult conversations. The “low performer problem” was actually a leadership problem in disguise.

I’ve seen this scenario repeat countless times across organizations. Leaders identify team issues while remaining blind to their own role in creating them.

Here’s the uncomfortable truth: Every team problem is ultimately a leadership problem.

The Leadership Reflection

This principle initially feels unfair. Surely, some problems exist independently of leadership? Some team members are just difficult, unmotivated, or incompetent, right?

While individual factors certainly exist, persistent team problems always trace back to leadership decisions:

• “Toxic team members” → Leaders who permit harmful behaviors
• “Communication breakdowns” → Leaders who haven’t built communication systems
• “Missed deadlines” → Leaders who accept unrealistic commitments
• “Quality issues” → Leaders who prioritize speed over excellence
• “Unmotivated team” → Leaders who haven’t connected work to purpose

The longer I lead, the more I see my teams as perfect mirrors reflecting my own leadership choices—both good and bad.

Beyond Blame

The leadership reflection principle isn’t about blame. It’s about agency.

When I view team problems as leadership problems, I shift from frustration to action. Instead of asking “Why won’t they…?” I ask “What have I…?”

• “Why won’t they collaborate?” becomes “What have I done to reward or prevent collaboration?”
• “Why won’t they speak up?” becomes “What have I done when people raised concerns?”
• “Why won’t they take ownership?” becomes “What have I done that signals I don’t trust them?”

This reframing transforms helplessness into opportunity. I can’t control individual personalities, but I can control the conditions, incentives, and culture that shape behavior.

The System You Built

I made a painful discovery early in my leadership career: My team’s behavior wasn’t random—it was the predictable outcome of the system I had created.

When my engineers avoided addressing technical debt, it wasn’t because they didn’t care about code quality. It was because I had:

• Celebrated only on-time feature delivery
• Failed to allocate time for maintenance
• Created a promotion system that rewarded visible features over invisible stability

The team was rationally responding to the environment I had built. Their behavior perfectly reflected my true (not stated) priorities.

The Ownership Principle

Taking ownership for team problems doesn’t mean taking all the action. Paradoxically, it often means stepping back.

When facing team challenges, I follow a three-step process:

1. Own the problem: “This situation exists partly because of my choices.”
2. Identify leadership actions: “Here’s what I’ll change about my approach.”
3. Enable team ownership: “How can I support you in addressing this together?”

This approach models the accountability I want to see while creating space for team members to exercise their own agency.

The Practical Applications

Let’s apply this principle to common team challenges:

“We have interpersonal conflicts”

• Leadership reflection: Have I created clear behavioral expectations? Have I modeled constructive disagreement? Have I addressed previous conflicts promptly?
• Leadership action: Establish team norms, mediate current conflicts, create channels for early feedback

“The team misses deadlines”

• Leadership reflection: Have I taught estimation skills? Have I created realistic expectations? Have I provided focus or allowed too many priorities?
• Leadership action: Improve planning processes, limit work in progress, create better feedback loops

“People don’t take initiative”

• Leadership reflection: What happens when people try new approaches? How have I responded to failure? Am I providing clear direction while allowing autonomy?
• Leadership action: Celebrate appropriate risk-taking, create lower-stakes opportunities, clarify decision authority

The Exceptions Test

You might be thinking: “But what about when a team member is just genuinely problematic regardless of leadership?”

Even these situations reflect leadership choices:

• Hiring decisions (Who did we bring onto the team?)
• Performance management (How are we addressing issues?)
• Cultural reinforcement (What behaviors do we tolerate?)

If someone truly cannot succeed despite your best leadership efforts, the accountability still lies with you: to make the tough decision to move them to a role where they can succeed or out of the organization entirely.

The Final Mirror

The ultimate test of this principle comes when you’re ready to blame external factors entirely beyond your control.

Even here, leadership accountability remains:

• “We don’t have enough resources” → How am I utilizing available resources? How effectively am I advocating for what we need?
• “Company politics block us” → How am I navigating relationships and building necessary alliances?
• “The market changed suddenly” → How prepared was I for potential shifts? How quickly am I helping the team adapt?

The most effective leaders I know share this trait: they instinctively look inward before looking outward when facing challenges.

They understand that while not every circumstance is within their control, their response always is. And that response shapes everything about how their team performs.

If you want to understand your leadership, look at your team. They’re the most honest mirror you’ll ever have.

I asked how he knew. His answer was revealing: “Nobody ever pushes back on our direction.”

After sitting in on three team meetings, I had to deliver some uncomfortable news: He didn’t have collaboration. He had compliance. And they’re not remotely the same thing.

The Sound of Fear

Silence in meetings isn’t consensus—it’s often a blaring alarm that trust has left the building.

I discovered this the hard way when launching a major product overhaul at my second startup. The room fell quiet after I shared the vision. I mistook the silence for alignment and marched forward.

Six months and $2M later, I learned the truth: The team had immediate, serious concerns but didn’t feel safe expressing them. They complied with a plan they knew was flawed because speaking up felt riskier than staying silent.

If people aren’t speaking up, you don’t have a “quiet” team. You have a trust problem.

The Compliance Trap

The compliance trap works like this:

1. Leader presents an idea
2. Team senses disagreement is unwelcome (explicitly or implicitly)
3. Team offers surface-level agreement
4. Leader misinterprets compliance as commitment
5. Problems emerge later that could have been prevented
6. Leader wonders why nobody spoke up sooner
7. Trust erodes further

This cycle creates the illusion of alignment while guaranteeing failure. Worse, it becomes self-reinforcing: each round of silent compliance followed by inevitable problems makes speaking up feel even riskier.

The Signals You’re Missing

How do you know if you’re mistaking compliance for commitment? Watch for these warning signs:

• Questions are clarifying, never challenging
• Feedback comes only after decisions are implemented
• 1:1 conversations reveal concerns never mentioned in groups
• People agree quickly without meaningful discussion
• The phrase “as you suggested” appears frequently in communication
• Implementation happens slowly despite apparent agreement

The Trust Equation

In my experience, psychological safety in teams follows a simple formula:

Trust = (Consistency × Vulnerability) ÷ Power Distance

Let me break this down:

• Consistency: How reliably you respond to input (even disagreement) with openness rather than defensiveness
• Vulnerability: Your willingness to admit uncertainty, mistakes, and limitations
• Power Distance: How wide the perceived gap is between your authority and the team’s

Teams speak up when trust outweighs perceived risk. Simple as that.

Breaking the Silence

Transforming compliance into real commitment requires deliberate action:

1. Make disagreement explicit. “If everyone agrees with this approach, that’s concerning because we haven’t heard any risks or alternatives.”
2. Reward concerns publicly. “That’s exactly the kind of issue I need to hear—thank you for raising it.”
3. Demonstrate changed thinking. Nothing builds trust like visibly changing your mind based on team input.
4. Create structured dissent. Assign someone the explicit role of challenging the approach in every significant decision.
5. Manage your reactions. Your response to the first brave person who speaks up determines whether others will follow.

The Commitment Test

Want to know if you have commitment or just compliance? Try this simple test:

Present a significant direction, then leave the room. Have someone neutral observe what happens next. If the conversation continues with honest debate, you have commitment. If it immediately shifts to other topics or includes eye rolls, you have compliance.

During a particularly challenging quarter, I tried an experiment: I deliberately presented an approach I knew was flawed. Not a single person on my team questioned it in the meeting. That told me everything I needed to know about our trust levels.

Silence Is Data

Remember this: Silence isn’t the absence of data—it is data. Often, it’s the most important signal that something is fundamentally broken in your team dynamic.

Leaders who celebrate their “aligned” teams without probing that alignment are setting themselves up for failure. True alignment can handle scrutiny. Compliance collapses under it.

The most powerful phrase in a leader’s vocabulary isn’t “I have decided.” It’s “What am I missing?”

Don’t mistake quiet for quality. The most dangerous problems aren’t spoken—until it’s too late.

After managing a ton of people across multiple companies and industries, I’ve reached a conclusion that transformed how I lead: People inherently want to do good work. Your actual job as a manager is to remove whatever stands in their way.

The Motivation Myth

The management industry has built a billion-dollar empire on the premise that employees need to be motivated, incentivized, and cajoled into performing well. This premise is fundamentally wrong.

The truth I’ve observed repeatedly is far simpler: Most people already have intrinsic motivation. What they lack are clear paths to apply it.

I learned this lesson the hard way when I inherited a “low-performing” team. My first instinct was to implement performance improvement plans, increased monitoring, and “motivational” interventions.

The results? Performance dropped even further.

What’s Actually Happening

When I finally stopped trying to “fix” the team and instead asked what was preventing them from doing their best work, the floodgates opened:

• Contradictory directives from different stakeholders
• Technical debt that turned simple tasks into nightmares
• Approval processes that added days to tasks that took hours
• Incomplete requirements that forced constant rework
• Tools and systems that actively fought against productivity

They weren’t unmotivated—they were barricaded.

The Obstacle Audit

I began a practice I now implement with every team: the obstacle audit. It’s a simple exercise with profound results:

1. Ask everyone: “What prevents you from doing the best work of your career here?”
2. Classify each obstacle (process, technical, resource, clarity, etc.)
3. Tackle the top three immediately

In one case, removing just two major obstacles (an outdated approval chain and a flaky test environment) increased team throughput by 62% in three weeks. No “motivation” required.

The Manager as Bulldozer

This perspective reframes the manager’s role entirely. You’re not a motivator, scorekeeper, or taskmaster.

You’re a bulldozer, clearing the path ahead of your team.

The best management days of my career haven’t been when I gave inspiring speeches or crafted clever incentives. They’ve been when I:

• Eliminated three approval steps from our deployment process
• Fixed the budget problem preventing a critical hire
• Resolved conflicting priorities between product and engineering
• Secured maintenance time to fix persistent technical issues

None of these actions “motivated” the team. They simply removed the frustrations preventing motivated people from applying their energy productively.

Signs You’re Not Getting It

How do you know if you’re still trapped in the motivation mindset rather than the obstacle-clearing one? Watch for these warning signs:

• You spend more time tracking output than removing barriers
• Your first response to performance issues is “motivation” rather than “what’s in the way?”
• Team meetings focus more on goals than on identifying and resolving obstacles
• You feel more like a supervisor than a support system

The Permission Problem

Perhaps the most insidious obstacle is the one managers unconsciously create: the permission barrier.

Teams that must constantly seek approval, validate decisions, or justify approaches will inevitably slow down and play it safe.

I was startled to discover how often I was the obstacle. My team didn’t need my brilliant insights—they needed me to quit being a bottleneck.

A senior engineer once told me, “I don’t need you to tell me what to do. I need you to run interference so I can do what I already know needs doing.”

The Path Forward

Want to transform your effectiveness as a manager? Try this today:

1. Assume everyone on your team fundamentally wants to excel
2. Ask directly: “What’s preventing you from doing your best work?”
3. Focus 80% of your energy on eliminating those obstacles
4. Measure your success not by how you “drive” performance, but by how effectively you remove barriers

The team that appears unmotivated is usually just a team drowning in obstacles. Stop throwing them motivational life preservers and start draining the water.

Your job isn’t to push the boulder up the hill. It’s to clear the path, so your team can roll it down.

The most painful leadership lesson I ever learned cost my company six months of work.

I ignored my team’s warnings about a technical approach because I was “the expert.” The project failed spectacularly. In the post-mortem, it became painfully clear: four different engineers had identified the exact problem that ultimately killed the project.

I just hadn’t been listening.

The Expertise Paradox

The higher you climb in management, the more your job becomes making decisions with imperfect information. Yet simultaneously, the further you drift from the ground-level details where the best solutions often hide.

This creates what I call the expertise paradox: The more authority you have to make decisions, the less equipped you become to make them correctly on your own.

The antidote is deceptively simple but surprisingly rare: Assume your team collectively knows more than you do. Then actually listen to them.

The Illusion of Contribution

In a particularly revealing study at Stanford, researchers found that leaders consistently overestimated their contributions to team discussions by about 30%. Even more telling: the higher their status, the larger this perception gap became.

I’ve seen this dynamic play out in countless meetings:

1. Manager asks for input
2. Team offers ideas
3. Manager unconsciously filters everything through their pre-existing view
4. Manager “synthesizes” (translation: barely modifies their original idea)
5. Team disengages from future discussions

This illusion that we’re truly considering input while actually dismissing it creates a dangerous feedback loop:

• Team stops offering candid thoughts
• Manager receives increasingly filtered information
• Decisions get worse
• Manager doubles down on their “experience” and “intuition”

The Listening Challenge

For one month, I tried an experiment with my leadership team. Before any decision discussion, we’d write down our initial position. After hearing everyone’s input, we’d revisit our original thinking and note what changed.

The results were uncomfortable but illuminating. Most of us changed less than 10% of our thinking despite hearing multiple perspectives. We were going through the motions of listening without actually being influenced.

Real listening requires something that feels almost dangerous: the willingness to be changed by what you hear.

The Collective Intelligence Advantage

Research on collective intelligence is unambiguous: diverse groups consistently outperform even the brightest individuals when addressing complex problems. But this only works when everyone’s input is genuinely valued.

The best ideas in your organization aren’t sitting in your head. They’re distributed across your team, often in unexpected places:

• The junior developer who asks “naive” questions that expose flawed assumptions
• The QA specialist who understands edge cases you’ve never considered
• The customer support rep who knows exactly how users actually interact with your product
• The new hire who brings patterns from another industry that could transform yours

Practical Tactics for Better Listening

Want to access this distributed intelligence? Try these approaches:

• Ask twice. The first answer is often safe and political. The second answer, after explicitly asking again, tends to be more honest.
• Speak last. As a leader, your ideas have disproportionate weight. By holding your thoughts until everyone has spoken, you avoid anchoring the discussion.
• Request disagreement. Explicitly ask: “What’s wrong with this approach?” or “What am I missing here?”
• Credit publicly. When someone’s input shapes a decision, announce it widely. This creates cultural permission for others to speak up.
• Track idea origins. Keep notes on whose ideas contributed to key decisions, then review periodically to spot patterns of whose input you might be systematically undervaluing.

The Leadership Paradox

The true paradox of leadership is this: your authority comes from your position, but your effectiveness comes from acknowledging what you don’t know.

The strongest signal of leadership confidence isn’t having all the answers—it’s being secure enough to recognize when others have better ones.

I keep a small note on my desk now: “The smartest person in the room is the room itself.”

Listen to it.

My mentor finally pulled me aside and said: “There is no right decision. There’s just the decision you make and how well you execute it.”

I dismissed his advice as lazy thinking. Surely, there was an objectively correct choice if I just analyzed thoroughly enough.

I was utterly wrong.

The Perfect Decision Fallacy

As engineers-turned-leaders, we’re particularly susceptible to what I call the perfect decision fallacy—the belief that enough analysis will reveal the one “correct” choice.

This mindset comes from our technical backgrounds, where problems often have optimal solutions. Sorting algorithms have provable efficiency. System designs have measurable performance characteristics.

But leadership decisions exist in a fundamentally different domain:

• They involve humans with unpredictable behaviors
• They require forecasting inherently uncertain futures
• They balance competing values with no clear hierarchy
• They entail accepting unknowable opportunity costs

There is no “right” decision. There are just decisions with different tradeoffs.

The Cost of Certainty

The pursuit of the perfect decision carries hidden costs:

1. Analysis paralysis: The organization stalls while awaiting your verdict
2. Illusory guarantees: You believe thorough analysis eliminates risk (it doesn’t)
3. Brittle responses: When reality diverges from predictions, you lack flexibility
4. Ownership avoidance: Teams don’t commit because it’s “your” perfect solution

I’ve witnessed $10M decisions made quickly and effectively, while $50K decisions languished for months because someone was searching for the mythical “right answer.”

Decisions as Experiments

After years of painful lessons, I’ve adopted a different mindset: Treat decisions as experiments, not solutions.

When deciding between microservices vs. monolith, in-house vs. vendor, or hire vs. train, I now ask:

• “What’s our confidence level with current information?”
• “How reversible is this decision?”
• “What’s the cost of delay vs. the value of more data?”
• “How can we test our assumptions fastest?”

This framework replaces the paralyzing search for certainty with the liberating pursuit of learning.

The Confidence Threshold

Not all decisions warrant the same deliberation. I use a simple framework to calibrate my approach:

• Low-stakes, reversible decisions: Make them quickly with available information (70% confidence)
• Medium-stakes, partially reversible: Gather core data, decide, then adapt (80% confidence)
• High-stakes, irreversible decisions: Analyze thoroughly, but recognize perfect information is impossible (90% confidence)

Notice that even the most consequential decisions don’t require 100% confidence—because 100% doesn’t exist outside of mathematics.

Execution Trumps Selection

A mediocre decision executed brilliantly consistently outperforms a “perfect” decision executed poorly.

When we built our payment processing system, we chose a technical approach that, in retrospect, wasn’t ideal. But we:

• Built robust monitoring around it
• Created clear ownership
• Established regular review cycles
• Committed fully to its success

The result outperformed similar teams with “better” technical choices but weaker execution.

Decision Quality vs. Decision Outcome

Perhaps the most important lesson: Don’t confuse good outcomes with good decisions or bad outcomes with bad decisions.

Some of my best decisions led to failures due to unforeseeable factors. Some of my worst, most rushed decisions succeeded through sheer luck.

Evaluating decisions solely by outcomes creates a distorted feedback loop that rewards luck and punishes thoughtfulness.

Instead, evaluate decisions by:

• The process used given time constraints
• The information considered given available data
• The principles applied given stated values
• The adaptations made as new information emerged

The Freedom of Acceptance

Accepting that perfect decisions don’t exist isn’t an excuse for sloppy thinking. It’s liberation from an impossible standard that prevents effective leadership.

Once I embraced the inherent uncertainty in leadership decisions, I:

• Made choices more quickly
• Committed to them more fully
• Adapted them more willingly
• Judged myself less harshly

The quest for perfect decisions is a path to leadership paralysis. The acceptance of “good enough with great execution” is the path to impact.

Make the best decision you can with the information you have. Then focus your energy where it actually matters: turning that imperfect decision into successful reality.

I was alone in the office, triple-checking a critical deployment scheduled for the next morning. I discovered a security flaw in code I had personally approved. I had two choices: quietly fix it and tell no one, or document my mistake in the team’s change log.

No one would ever know if I covered it up.

I logged the error, explicitly noting that I had missed it in review, and fixed it. I thought nothing of it until six months later when one of my engineers mentioned it during a 1:1.

“That’s when I knew you were different,” she said. “You didn’t have to own that mistake. No one would have known.”

Except someone did know. And it mattered more than any speech I could have given.

The Invisible Scorecard

As leaders, we operate under a persistent delusion: that some of our actions are unseen, therefore inconsequential.

This is fundamentally wrong.

Your team maintains a constant, detailed accounting of your behavior—especially the parts you think no one notices:

• How you act when executives are in the room vs. when they’re not
• Whether you take credit or distribute it
• If you follow the processes you impose on others
• How you respond to pressure when no one’s looking

These unwitnessed moments constitute the truest expression of your leadership. They form the invisible foundation of trust on which everything else stands.

The Consistency Gap

The gap between what you preach and what you practice creates a credibility tax on everything you say.

I’ve worked with managers who:

These leaders failed to understand a fundamental truth: Your team doesn’t hear what you say nearly as clearly as they see what you do.

The After-Hours Test

Want to know your real leadership principles? Look at what you do when:

• No one would know if you took a shortcut
• The right thing is inconvenient or costly
• There’s no external reward for integrity

These moments reveal your actual leadership philosophy—not the one in your LinkedIn profile.

The Hidden Standard

Years ago, I shadowed a VP engineering widely respected for building high-integrity teams. I wanted to understand his secret.

After two weeks, I realized something profound: He didn’t have separate public and private behaviors. The standard he set with his team was the exact standard he followed when working alone.

If the deployment checklist required two reviews, he found two reviewers for his own code—even for trivial changes, even when behind schedule.

His consistency wasn’t performative. It was habitual.

The Leadership Tax

Understand this: As a leader, you pay a tax that individual contributors don’t.

You must follow your own rules more rigorously than you expect others to follow them. You must uphold your stated values even when they’re inconvenient. You must embody your team culture even when no one’s watching.

This tax isn’t fair, but it’s non-negotiable. The moment you believe certain principles apply to the team but not to you, your leadership has already failed.

The Cultivation of Character

Leadership character isn’t built through grand gestures. It’s forged through hundreds of small, often invisible decisions:

• Admitting “I don’t know” when you could have faked expertise
• Giving credit to someone who isn’t in the room to receive it
• Upholding quality standards when deadlines press
• Respecting the process even when you could bypass it
• Owning mistakes that you could have concealed

These moments don’t make compelling stories at leadership conferences. They rarely earn promotions or recognition. But they create the foundation of trustworthy leadership.

The True Measurement

I’ve come to believe the true measurement of leadership isn’t what happens when you’re in the room. It’s what happens when you’re not.

Are decisions made with the same care? Are values upheld with the same rigor? Does quality remain non-negotiable?

If yes, you’ve succeeded at the most fundamental leadership task: making your presence unnecessary by embedding your principles into the team’s DNA.

Not through speeches or mandates, but through the quiet consistency of your example—especially when you think no one’s watching.

Because someone always is.

After 15 years building and leading engineering teams, I’ve noticed a pattern so consistent it might as well be a natural law: Every bad manager avoids accountability like it’s radioactive.

The Blame Shield

Bad managers construct elaborate defense mechanisms. They create organizational structures not for efficiency but for plausible deniability. They build what I call “blame shields.”

I once reported to a VP who insisted on a convoluted approval chain for all technical decisions. This wasn’t to ensure quality – it was so he could point fingers when things went south. “Well, the architecture team signed off on it” became his mantra when projects failed.

What’s fascinating is how predictable these behaviors become once you recognize them:

1. They speak in vague directives (“make it better” or “fix it”)
2. They document selectively (capturing praise, avoiding paper trails of their mistakes)
3. They rewrite history in real-time (“I never said that” or “You misunderstood me”)

The Truth About Accountability

Here’s the counterintuitive reality about accountability: embracing it gives you more power, not less.

When I was a new engineering manager, I botched a major release schedule. I had two choices: distribute blame across the team or own it completely. I chose the latter, telling my CEO: “I misjudged the complexity and made overly optimistic promises. Here’s my plan to fix it.”

Instead of losing respect, something unexpected happened. My team worked harder to help solve the problem. My CEO trusted me more, not less. My explicit ownership created implicit authority.

Accountability isn’t about taking blame – it’s about claiming the power to improve things.

The Fear Factor

Why do so many managers run from accountability? Fear.

They fear judgment. They fear looking incompetent. They fear losing control. But mostly, they fear that accountability means punishment.

This creates a toxic cycle:

• Avoid accountability → Create confusion about responsibilities → Problems don’t get solved → Team loses trust → Manager feels more threatened → Avoid accountability harder

Breaking the Cycle

Want to know if you’re sliding into this trap? Test yourself:

• When was the last time you said, “I was wrong” without following it with “but…”?
• Do you spend more time explaining why something failed or fixing it?
• In postmortems, do you focus more on process failures or people failures?

The fix is deceptively simple but brutally difficult: deliberately practice accountability when the stakes are low.

Start with small acknowledgments. “I underestimated how long that would take.” “I missed that edge case in planning.” “I should have asked more questions before approving that approach.”

These small moments build the accountability muscle for when it truly matters.

The Accountability Advantage

The managers I respect most share a superpower: they take responsibility for outcomes before they even happen.

They say things like:

• “If this approach fails, that’s on me, not the team.”
• “I’m asking you to try something unproven, so I’ll absorb the risk.”
• “The timeline is aggressive, but I’ve committed us to it, so I’ll help clear obstacles.”

This forward-looking accountability creates psychological safety, encourages reasonable risk-taking, and builds unwavering loyalty.

The Bottom Line

After coaching dozens of engineering leaders, I’ve come to believe that accountability isn’t just a virtue – it’s a competitive advantage.

Teams move faster when they don’t waste energy on blame games. Innovation flourishes when people aren’t afraid to fail. And paradoxically, the leaders who most readily admit their limitations are the ones who end up with the fewest actual failures.

Want to be a better manager? Start by owning your mess.

My friends at a high-growth fintech startup recently shared a painful story. Their engineering organization had implemented an extensive metrics program tracking things like completed tickets and bug count without their severity considered. Leadership celebrated these numbers in all-hands meetings, complete with leaderboards and recognition for top performers.

Meanwhile, their actual product development crawled to a halt. They were optimizing for vanity metrics while ignoring the elements that actually drive engineering success.

I’m not saying that measuring some of these can’t be useful once you’ve really understood that you have a specific problem in the relevant area, but these are not real performance metrics. You know, outcome over output…

This pattern repeats itself across our industry with alarming regularity. We fall in love with what’s easy to measure, not what actually matters.

The SPACE framework changed my entire perspective on measuring developer productivity. Created by researchers from GitHub, Microsoft, and the University of Victoria, it breaks down productivity into five critical dimensions that actually matter. Let’s dive into each one.

What is the SPACE framework?

The SPACE framework gives engineering leaders a multidimensional lens to actually understand engineering effectiveness, not just mindlessly track output. Developed by Nicole Forsgren, Margaret-Anne Storey, and their team at Microsoft Research in 2021, it’s essentially a rebellion against the shallow “how many tickets did you close?” metrics that plague our industry.

Unlike the garbage productivity metrics most companies still use, SPACE acknowledges that engineers aren’t just code-producing robots. It looks at Satisfaction and well-being alongside Performance, Activity, Communication, and Efficiency. It’s the first framework I’ve seen that doesn’t pretend developer happiness is some optional nice-to-have rather than a fundamental driver of sustainable engineering excellence.

Satisfaction and Well-being: The Foundation

This dimension hits close to home. At a previous company, we lost three engineers in two months before realizing we had a burnout issue. Developer happiness isn’t (just) about free snacks and ping pong tables – it’s about sustainable work patterns and meaningful impact.

Key indicators I now track:

• Work-life balance metrics (after-hours commits, weekend work patterns)
  • metrics
  • productivity
  • engineering
• Learning and growth opportunities

According to recent research, the four horsemen of developer burnout are poor work-life balance, constant disruptions, overwhelming workload, and inefficient tooling. Sound familiar? These are all measurable and fixable problems.

Performance: Outcomes Over Output

Here’s where most companies get it wrong. They measure lines of code, number of commits, or PR velocity. But these metrics are like measuring a writer’s productivity by counting words – it misses the point entirely.

Real performance metrics I’ve found valuable:

• Feature adoption rates
• Customer impact metrics
• System reliability improvements
• Technical debt reduction impact
• Time-to-value for new features

The key is measuring outcomes, not output. When my team rebuilt our authentication system, we didn’t track the number of files changed – we tracked the reduction in support tickets and improved login success rates.

Activity: The Daily Reality

Activity isn’t just about coding. Modern developers spend their days across a spectrum of tasks, and understanding this rhythm is crucial for improving productivity.

What to actually measure:

• Time distribution across different types of work
• Code review participation patterns
• Documentation contributions
• Technical design involvement
• Mentorship and knowledge sharing activities

Real talk: A recent developer survey showed that engineers spend only 60% of their time actually coding. Understanding where the other 40% goes is crucial for optimization.

Communication and Collaboration: The Force Multiplier

I once worked with a team that had stellar individual developers but couldn’t ship features on time. The problem? Broken communication patterns. This dimension is about how effectively your team works together.

Critical metrics to watch:

• Code review response times
• Cross-team collaboration frequency
• Knowledge sharing effectiveness
• Documentation quality and usage
• Meeting efficiency ratings

One surprising finding: 74% of developers face delays waiting for feedback, with 70% spending at least three hours weekly in feedback limbo. That’s pure waste we can measure and fix.

Efficiency and Flow: The Productivity Engine

Flow state – that magical zone where developers are most productive – is fragile. Interruptions, blocked tasks, and process friction all break it. Measuring and protecting flow is crucial.

What we track:

• Time blocked on dependencies
• Context switching frequency
• Deployment pipeline efficiency
• Build time trends
• Interruption patterns

The data is clear: 44% of developers feel they spend too much time in meetings. At one of my past companies, we implemented “no-meeting Wednesdays” after measuring interruption patterns, leading to a visible increase in completed story points.

But knowing the framework exists isn’t enough – you need to know how to actually use it.

Let’s dive into what I’ve learned about making SPACE work in the real world.

Pick Your Metrics (But Not Too Many)

The first trap I see leaders fall into is trying to measure everything. Don’t. Start with three metrics that matter right now for your team’s specific context. And here’s a counterintuitive tip from Dr. Jenna Butler, one of SPACE’s co-authors: include one metric where you’re already excelling.

Why? Because improving in new areas shouldn’t come at the cost of what you’re already doing well. When my team was struggling with frequent production incidents, we kept tracking our strong code review practices while adding metrics around deployment confidence and time-to-recovery.

Context Is Everything

Your metrics should reflect your current reality. A team building a new product needs different measures than one maintaining critical infrastructure. At a previous company, we shifted our metrics entirely when moving from growth phase to optimization phase:

Growth Phase Metrics:

• Feature delivery speed
• Time to first deployment
• Engineer satisfaction scores

Optimization Phase Metrics:

• System reliability
• Code maintenance efficiency
• Cross-team collaboration effectiveness

The Time Horizon Trap

One detail that often gets overlooked: how long should you stick with your chosen metrics? Dr. Butler makes a compelling point – changing metrics every quarter is too frequent. Humans need time to adapt behaviors, and systems need time to show meaningful change.

In my experience, the sweet spot is usually 6–9 months, unless you hit one of two conditions:

1. The metric has plateaued at an acceptable level
2. The metric no longer drives useful decisions

From Metrics to Action

Here’s where most teams get stuck – they collect data but never turn it into action. The key is involving your entire team in the process. When we noticed our deployment confidence dropping, I didn’t mandate a solution. Instead, we:

1. Shared the data with the entire engineering org
2. Created space for engineers to discuss their experiences
3. Let teams propose and own their solutions
4. Measured the impact of changes

The results were surprising. Different teams came up with different approaches that worked for their specific contexts. Some improved their testing practices, others implemented better staging environments, and one team completely revamped their feature flagging system.

The Leadership Layer

One question I frequently get: should different levels of leadership look at different metrics? While a CTO and an engineering manager might need different levels of detail, the core metrics should align throughout the organization.

Think of it like a pyramid:

• Organization-wide SPACE metrics at the top
• Team-specific additions in the middle
• Individual team actions and experiments at the base

This creates alignment while maintaining flexibility where it matters most – at the team level where the actual work happens.

Making It Real

Let me be direct: frameworks like SPACE are useful only if they drive actual improvements in how your team works. Here’s my simple template for making that happen:

1. Pick 3–4 metrics that matter NOW
2. Make sure one is a current strength
3. Share data transparently
4. Let teams own their solutions
5. Stick with it long enough to see real change
6. Adjust based on results, not arbitrary timeframes

Remember – the goal isn’t to have perfect metrics. The goal is to build a more effective engineering organization. Use SPACE as a tool toward that end, not as an end in itself.

Your team’s productivity story is unique. Measure what matters for your context, involve your engineers in the process, and be patient enough to see real results. The data might surprise you – and that’s exactly the point.

What metrics are you tracking? I’d love to hear about what’s working (or not working) for your team.

3 AM pages aren’t heroic — they’re a system failure.

I’ve spent countless nights staring at alerts, wondering if I should wake up the senior engineer. After a decade of both holding the pager and building on-call systems at companies ranging from tiny startups to successful, sizable companies, I’ve learned that the biggest on-call problems aren’t technical — they’re cultural. Here’s my comprehensive guide to building a sustainable on-call culture.

The Reality of Modern On-Call

Let’s start with a truth that might ruffle some feathers: If your engineers are regularly getting woken up at night, your system is broken. Not just technically, but organizationally.

I learned this lesson the hard way at my first startup. We were a team of four engineers, running a service used by millions. Our on-call rotation was brutal — two people alternating weeks, getting paged 3–4 times per night. We wore those interruptions like badges of honor. “This is just how things are in high-scale systems,” we told ourselves.

Then I joined my next gig, a much larger company. My first week, I noticed something strange: despite handling traffic several orders of magnitude larger than my previous company, the on-call engineers were sleeping through most nights. That’s when I realized we’d been doing it wrong all along.

The Hero Trap: Why Engineers Break Themselves

Most engineers’ first on-call rotation goes something like this: Your pager goes off at 2 AM. Your heart races. You dive in, determined to fix it yourself. Three hours later, you’re still debugging, barely coherent, when a teammate logs in and solves it in 10 minutes.

This “hero” mentality breaks both engineers and systems. Here’s why:

The Cost of Hero Culture

• Sleep deprivation impairs judgment similar to alcohol
• Heroic fixes often address symptoms, not root causes
• Teams become dependent on tribal knowledge
• Documentation remains poor because “heroes” just handle it
• Engineers burn out and leave

At my last company, we lost our best infrastructure engineer because of hero culture. He was the only one who could fix certain problems, so he got called for everything. After six months of interrupted sleep, he quit. The irony? Once he left, we were forced to address our systemic issues properly.

The New On-Call Mindset: Triage Over Heroics

Your job isn’t to fix everything yourself — it’s to ensure issues get addressed properly. Let’s break down what this means in practice.

The Triage Framework

When that alert hits, ask these questions in order:

1. System Impact
   • Which services are affected?
   • Is this customer-facing?
   • Are we losing data?
   • Is this affecting revenue?
2. Scale of Impact
   • What percentage of users are impacted?
   • Which regions are impacted?
   • Is this affecting specific customer segments?
3. Urgency Assessment
   • Does this need immediate attention?
   • What’s the cost of waiting until morning?
   • Are there temporary workarounds?
4. Skills/Scope Evaluation
   • Do I have the expertise to fix this?
   • Do I have access to all required systems?
   • Who else needs to be involved?

Real-World Triage Example

A couple of jobs back, one day at 3 AM, we got an alert: “High latency in payment processing service.” Old me would have immediately started debugging. New me went through the framework:

1. System Impact: Payment processing affected, definitely customer-facing and revenue-impacting
2. Scale: 15% of transactions showing high latency, but all eventually succeeding
3. Urgency: Medium — transactions are slow but completing
4. Skills/Scope: Payment system involves multiple teams

Decision: I woke up our payments team lead. Why? Because even though transactions were completing, the revenue impact meant we needed expert eyes on it. They found that a database index issue that was gradually degrading performance. Fixed in 20 minutes once the right person was involved.

The Science of Escalation

Here’s a counterintuitive truth: The best on-call engineers escalate early and often. Let’s break down when and how to escalate effectively.

When to Escalate

• You’ve spent >30 minutes without a clear direction
• The problem affects core business functions
• You need access you don’t have
• The issue involves multiple systems
• You’re not 100% confident in your fix
• You’re tired and might make mistakes

How to Escalate Effectively

1. Prepare Your Information:
   • Timeline of the incident
   • Current system status
   • Actions already taken
   • Relevant logs and metrics
   • Business impact assessment
2. Clear Communication:
   “Hey Alice, we have a P1 incident affecting our payment processor. 15% of transactions are seeing 10x normal latency. I’ve verified it’s not the load balancer or recent deployments. Given your expertise with the payment system, I’d value your insight on this.”
3. Follow-up Documentation:
   • Summary of the discussion
   • Action items agreed upon
   • Next steps and owners
   • Timeline for resolution

Documentation: Your 3 AM Best Friend

Every incident needs three types of documentation:

1. Live Incident Notes

2024-02-10 03:15 UTC - Alert triggered: High latency in payments
2024-02-10 03:17 UTC - Verified issue in metrics: p95 latency 2.3s (normal 200ms)
2024-02-10 03:20 UTC - Checked recent deployments - none in last 24h
2024-02-10 03:25 UTC - Investigated load balancer logs - normal traffic patterns
2024-02-10 03:30 UTC - Escalated to Alice (Payments Lead)

2. Investigation Notes

• System components checked
• Commands run and their output
• Hypotheses tested
• Dead ends encountered
• Resource links consulted

3. Resolution Documentation

• Root cause analysis
• Fix implemented
• Verification steps
• Prevention measures
• Follow-up tasks

Building Systems That Let You Sleep

Every alert should trigger two questions:

1. How do we fix it right now?
2. How do we prevent it from happening again?

System Reliability Checklist

1. Monitoring and Alerting
   • Clear thresholds based on business impact
   • Elimination of alert noise
   • Automated resolution for common issues
   • Runbooks for all alerts
2. System Design
   • Circuit breakers for external dependencies
   • Graceful degradation paths
   • Automated failover where possible
   • Rate limiting and backpressure
   • Transactions and audit trails for critical operations
3. Operational Tools
   • One-click rollbacks
   • Automated diagnostic tools
   • Clear system dashboards
   • Centralized logging
4. Process Improvements
   • Regular disaster recovery testing
   • System architecture reviews
   • Capacity planning
   • Performance testing

The Human Side of On-Call

On-call isn’t just about technical skills. It’s also about:

Clear Communication

• Regular status updates to stakeholders
• Clear escalation paths
• Documented decision-making processes
• Post-incident reviews

Team Support

• Mental health resources
• Rotation flexibility
• Training and shadowing programs
• Recognition and compensation

Stakeholder Management

• Clear incident severity definitions
• Regular communication templates
• Expectations setting
• Business impact assessment

Building a World-Class On-Call Culture

Clear Escalation Paths

Every engineer needs to know exactly whom to contact and when. Here’s a sample escalation matrix:

Severity Levels:

• P0: Critical business impact (Payment system down)
• P1: Significant impact (Major feature unavailable)
• P2: Moderate impact (Performance degradation)
• P3: Minor impact (Non-critical system issues)

Escalation Flow:

1. L1: Primary on-call engineer
2. L2: Service owner/domain expert
3. L3: Engineering manager
4. L4: VP of Engineering

Response Times:

• P0: Immediate response required
• P1: 15-minute response time
• P2: 1-hour response time
• P3: Next business day

Comprehensive Runbooks

Every alert should have:

Context Section:

• Alert meaning and impact
• Normal vs. abnormal values
• Recent changes that might affect it
• Business impact assessment

Diagnostic Steps:

1. Initial verification steps
2. Common causes and solutions
3. Data collection requirements
4. Escalation criteria

Resolution Steps:

• Step-by-step fix procedures
• Verification methods
• Rollback procedures
• Post-resolution tasks

Fair Rotation Management

A healthy rotation includes:

Schedule Structure:

• Maximum 7 days on primary
• Minimum 14 days between rotations
• At least 5 engineers per rotation
• Clear backup scheduling

Compensation:

• Base on-call stipend
• Per-incident compensation
• Time off after major incidents
• Tool and training budget

Support Systems:

• Mental health resources
• Flexible scheduling
• Training programs
• Regular rotation reviews

Measuring Success

How do you know if your on-call culture is healthy? Here are our key metrics:

Technical Metrics:

• Mean Time Between Failures (MTBF)
• Mean Time To Resolution (MTTR)
• Number of night pages
• False positive rate
• Repeat incident rate

Human Metrics:

• Engineer satisfaction scores
• On-call stress levels
• Training completion rates
• Documentation quality scores
• Post-incident review completion

Business Metrics:

• Customer impact duration
• Revenue impact from incidents
• Time to customer notification
• Resolution SLA compliance

The Path Forward

Remember: The goal isn’t to handle every incident perfectly. It’s to learn from each one while maintaining your sanity and your sleep schedule.

Start with these steps:

1. Audit your current state
2. Identify the biggest pain points
3. Implement quick wins first
4. Build long-term improvement plans
5. Regularly review and adjust

Your pager will go off again. But with these principles in mind, you’ll handle it with confidence, clarity, and maybe even get back to sleep afterward.

And if you’re currently in a toxic on-call situation? Sometimes the best thing you can do is find a team that values sustainable engineering practices. Your health matters more than any system.

Prioritize sleep over heroics. Your future self will thank you.

Instead, I said: “I don’t know what’s causing this – yet. Let’s find out together, I know we can.”

That admission changed everything. The room’s energy shifted from panic to focused problem-solving. A junior engineer mentioned seeing similar patterns in our logging system last week. A senior architect pulled up performance metrics showing gradual degradation over the past month. Within hours, we identified a subtle race condition in our caching layer – something we would have missed if we’d rushed to implement the first “obvious” solution.

This moment taught me more about leadership than a decade of management books.

The Science of Uncertainty and Decision-Making

A groundbreaking study from the University of Utah, published in Physical Review E in 2024, validates what many thoughtful leaders have long suspected: quick decisions often come from bias, not insight. The research, led by mathematician Samantha Linn, revealed that early decisions correlate strongly with pre-existing biases, while slower, more deliberate choices show higher accuracy rates.

This isn’t just academic theory. In tech leadership, I’ve watched this play out countless times:

Quick Decision Disasters:

1. The “Just like Google” Syndrome
   • VP pushing microservices because “that’s how Google scales”
   • Ignored differences in team size, skill sets, and actual needs
   • Result: $2M spent, 6 months wasted, system more complex than ever
2. The Feature Factory Fallacy
   • Product team “certain” about user needs
   • Built 47 features in 6 months based on assumptions
   • Reality: 87% of features never used more than once
3. The Architecture Ego Trap
   • Senior architect refused to consider scaling concerns
   • “The design is solid, trust me”
   • Resulted in a 4-hour outage during peak traffic

The Leadership Paradox

Let’s examine what happens when we lean into uncertainty, backed by both research and real-world experience.

The Utah Study’s Key Findings

The research reveals something fascinating about decision-making patterns. Those who made quick decisions showed strong alignment with their initial biases, regardless of available evidence. In contrast, slower decision-makers demonstrated:

• Higher accuracy rates
• Better integration of new information
• More balanced evaluation of alternatives
• Lower influence from initial biases

This maps perfectly to what I’ve seen leading engineering teams.

Real-World Examples

The Database Migration Success Story

At a previous company, we faced critical scaling issues. The “obvious” solution was to switch to the trending NoSQL database everyone was talking about. Instead of rushing in, we said: “We don’t know enough yet.” Here’s what happened:

1. Initial Response
   • Mapped current pain points
   • Ran comprehensive load tests
   • Interviewed teams with similar scale
   • Built small proof-of-concepts
2. What We Found
   • Main issues were in our query patterns
   • Existing database was using only 30% of its capabilities
   • Team needed query optimization skills more than new tech
3. Final Outcome
   • Optimized existing system
   • 10x performance improvement
   • No migration needed
   • Saved 8 months of potential disruption

The Product Market Lesson

An even more dramatic example came from our US market expansion:

The Confident Approach (First Attempt):

• Assumed market needs
• Copied European playbook
• Result: $2.7M lost, product rejected

The Uncertain Approach (Second Attempt):

1. Started with Questions
   • “We don’t know this market”
   • “We don’t understand local needs”
   • “We need to learn before building”
2. Actions Taken
   • Hired local experts
   • Ran small pilots
   • Gathered usage data
   • Iterated based on feedback
3. Results
   • Revenue positive in 4 months
   • 92% customer satisfaction
   • 3x faster market penetration

Building a System Around Uncertainty

I needed a way to systematize this approach. Random uncertainty isn’t helpful – we need structured uncertainty. This led to developing the following system (or may I say “framework”?)

Why Another Framework?

Most decision-making frameworks assume you have all the information you need. But in modern engineering leadership, that’s rarely true. CLEAR is built specifically for situations where uncertainty is high and the cost of being wrong is significant.

The Five Elements of CLEAR

Context (What We Know)

• Verified facts and data
• Current metrics and KPIs
• Documented constraints
• Historical precedents

Example: When facing a microservices decision, Context means listing your actual scaling problems, current performance metrics, team size, and existing architecture limitations.

Limitations (What We Don’t Know)

• Identified knowledge gaps
• Key assumptions
• Potential risks
• Resource constraints

Example: For our US market expansion, Limitations included understanding of local user behavior, regulatory requirements, and technical infrastructure differences.

Exploration (How We’ll Learn)

• Research methods
• Experiments to run
• Data to collect
• People to consult

Example: During our database migration decision, Exploration involved load testing, proof-of-concepts, and consulting teams who’d made similar transitions.

Action (What We Do Now)

• Immediate next steps
• Quick experiments
• Risk mitigation
• Learning activities

Example: When evaluating a new frontend framework, Action meant building small prototypes, running performance tests, and documenting developer experience.

Review (How We Check Progress)

• Success metrics
• Check-in schedule
• Pivot criteria
• Learning documentation

Example: For our product localization efforts, Review included weekly market feedback sessions, monthly performance metrics, and clear criteria for expanding or pulling back.

Type 1/Type 2 Decisions

After introducing this framework, we had to address a crucial question: When should we use it? Not every decision warrants this level of structured uncertainty. Here’s where Jeff Bezos’s Type 1/Type 2 framework becomes invaluable.

Type 1 Decisions: When Stakes Are High

These decisions are nearly irreversible, high risk or have long-lasting implications. They’re the ones that keep engineering leaders up at night:

• Architecture Foundations
  • Moving to microservices
  • Database technology choices
  • Cloud provider selection
  • Core API design
• Team Structure
  • Reorganizations
  • Location strategy (remote/hybrid)
  • Core process changes
  • Hiring strategies
• Product Direction
  • Platform decisions
  • Market focus
  • Core feature removals
  • Major pricing changes

For Type 1 decisions, the CLEAR framework isn’t just helpful—it’s essential. Taking time here isn’t indecision; it’s wisdom.

Type 2 Decisions: When Speed Matters

These are reversible choices where perfect information isn’t necessary:

• Sprint Planning
  • Task prioritization
  • Story point estimates
  • Development tool choices
  • Minor feature tweaks
• Team Operations
  • Meeting schedules
  • Code review processes
  • Documentation formats
  • Development environment setup

For Type 2 decisions, light application of CLEAR might be enough, or you might skip it entirely.

The Psychology of Safe Uncertainty

Building on the previous sections, let’s dive deep into what might be the most critical element: creating an environment where uncertainty becomes a strength rather than a weakness.

Understanding Psychological Safety

The term “psychological safety” was coined by Harvard’s Amy Edmondson, but I’ve seen it play out daily in engineering teams. It’s not just about feeling comfortable—it’s about creating an environment where:

• Engineers question assumptions without fear
• Junior team members challenge senior architects
• Failed experiments are seen as valuable data
• “I don’t know” is the start of discovery, not a sign of weakness

The Three Levels of Safety

1. Personal Safety

• What It Looks Like:
  • Speaking up about knowledge gaps
  • Admitting mistakes early
  • Asking “obvious” questions
  • Challenging popular opinions
• How to Build It:
  • Leaders go first with vulnerability
  • Reward early problem identification
  • Share your own learning journey
  • Make “I don’t know” a strength signal

2. Team Safety

• What It Looks Like:
  • Open discussion of technical debt
  • Honest project status updates
  • Proactive risk identification
  • Collaborative problem-solving
• How to Build It:
  • No blame post-mortems
  • Celebrate identified risks
  • Share credit for successes
  • Joint exploration of unknowns

3. Organizational Safety

• What It Looks Like:
  • Transparent decision-making
  • Open discussion of failures
  • Cross-team learning
  • Systemic problem-solving
• How to Build It:
  • Public learning repositories
  • Cross-team retrospectives
  • Open architecture reviews
  • Shared assumption tracking

Common Barriers to Safety

1. The Expert Trap

When senior engineers feel they must always have answers:

• Solution: Celebrate senior engineers who say “let’s figure this out together”
• Example: Our principal engineer starting architecture reviews with “Here’s what I’m uncertain about…”

2. The Speed Illusion

When teams feel pressure to have immediate answers:

• Solution: Show data on how rushed decisions cost more time
• Example: Our “Decision Speed vs. Outcome Quality” dashboard

3. The Status Game

When knowledge becomes a power tool:

• Solution: Reward teaching and knowledge sharing over knowing
• Example: Our promotion criteria explicitly valuing mentorship, the capability to cope with the unknown and solid documentation

Creating Safe-to-Fail Environments

Bounded Experiments

• Set clear learning objectives
• Define acceptable failure parameters
• Create safe testing environments
• Document learning outcomes

Progressive Disclosure

• Start with small risks
• Build trust through transparency
• Increase scope gradually
• Maintain consistent feedback loops

Handling Resistance and Objections

Let’s address the common pushback you’ll face when implementing this approach:

“We Don’t Have Time for This”

The Objection:

“Moving fast is our advantage. We can’t slow down for all this process.”

The Response:

• Share real data about rework costs
• Show metrics on rushed decision failures
• Present the Utah study findings about bias and speed
• Demonstrate how structured uncertainty actually speeds up good decisions

Example:

“Last quarter, rushed decisions cost us 442 engineering hours in rework. Using a systematic approach on similar decisions, this quarter reduced that to 64 hours.”

“Leaders Should Have Answers”

The Objection:

“The team looks to us for direction. Saying ‘I don’t know’ undermines confidence.”

The Response:

• Share examples of respected leaders embracing uncertainty
• Show how false certainty damages trust
• Demonstrate improved team engagement metrics
• Present case studies of successful uncertain exploration

Conclusion: The Power of Structured Uncertainty

The research is clear: embracing uncertainty leads to better decisions. But more importantly, it builds stronger, more resilient teams.

Remember:

• Quick decisions often mask bias
• Structured uncertainty beats rushed certainty
• Teams thrive when exploration is safe
• Leadership means finding answers, not having them

Your challenge: Tomorrow, when faced with a complex decision, resist the urge to have an immediate answer. Instead, say: “Let’s explore this together”.

Then watch how your team transforms.

Because in the end, the best leaders aren’t those who know everything – they’re the ones who know how to figure out anything.

Back in 1991, a safety researcher named James Reason proposed a revolutionary way of thinking about system failures. He suggested that disasters rarely result from a single point of failure. Instead, they happen when multiple vulnerabilities in different layers of a system align—like holes in slices of Swiss cheese lining up to create a path through the entire stack.

A system fails when its vulnerabilities in multiple protective layers momentarily align, like holes lining up in slices of Swiss cheese.

Reason developed this model after studying catastrophic failures like the 1986 Challenger disaster, where it wasn’t just one component that failed, but a cascade of interconnected issues—from engineering decisions to management processes to communication breakdowns. The model transformed how industries think about safety and reliability, spreading from aerospace to healthcare and beyond.

While Reason originally created this framework for physical safety systems, I’ve found it incredibly powerful for understanding why things break in tech organizations—and more importantly, how to prevent disasters before they happen. In fact, I’d argue it’s more relevant than ever in our world of complex, interconnected systems.

The Stack of Swiss: More Than Just a Tasty Metaphor

Think of your tech infrastructure as a stack of Swiss cheese slices. Each slice represents a different layer of defense, for example:

• Your authentication system
• Input validation
• Error handling
• Monitoring
• Backup systems
• Security protocols
• Human processes

Each of these layers has holes—vulnerabilities, bugs, or failure points. The beauty of the model is that it acknowledges this reality: no single layer will ever be perfect. What matters is how we arrange these imperfect layers to create robust systems.

Learning From My Own Swiss Cheese Disaster

A couple of years ago, my team experienced a major data pipeline failure that perfectly illustrates this model in action. We had:

• A bug in our validation logic (hole #1)
• Monitoring that didn’t catch the invalid data (hole #2)
• A backup system that was temporarily disabled for maintenance (hole #3)

When these holes aligned, we had a complete system failure. The incident taught us that having multiple layers of defense isn’t enough—we need to actively manage how these layers interact.

Beyond Infrastructure: The Human Layer

Here’s where it gets interesting: the Swiss Cheese Model isn’t just about technical systems. Some of the most critical “slices” in your stack are human processes:

• Code review practices
• Deployment procedures
• Incident response protocols
• Team communication patterns

I’ve seen teams with beautiful technical architectures fail because their human layers were full of holes. A rigorous CI/CD pipeline won’t save you if your team has poor communication habits or unclear escalation procedures.

Making Your Cheese Work for You

So how do we apply this in practice? Here’s my approach:

1. Map Your Cheese Layers
   • Document every defensive layer in your system
   • Identify known holes in each layer
   • Look for patterns where holes might align
2. Diversify Your Defenses
   • Don’t rely on similar types of checks at different layers
   • Mix automated and human verification
   • Implement different types of monitoring at different levels
3. Monitor Layer Health
   • Regularly audit each defensive layer
   • Track near-misses where holes almost aligned
   • Maintain and update each layer independently
4. Build Dynamic Defense
   • Create systems that adapt when holes are detected
   • Implement automated responses to potential alignments
   • Foster a culture of proactive hole-patching

The Counterintuitive Truth

Here’s the part that took me years to accept:

💡

Trying to eliminate all holes is not only impossible—it’s counterproductive.

The goal isn’t to have perfect layers; it’s to have complementary layers whose strengths compensate for each other’s weaknesses.

Some of the most reliable systems I’ve built weren’t the ones with the fewest holes, but the ones with the best-arranged holes. They were designed to fail gracefully, detect issues early, and prevent cascading failures.

Post-Mortems: Your Swiss Cheese Detective Tool

Post-mortems are where the Swiss Cheese Model really shines. When analyzing an incident, most teams focus on finding “the root cause” — but this model teaches us that significant failures rarely have a single cause. Instead, use your post-mortems to:

1. Map the Failure Path
   • Identify every defensive layer that was breached
   • Document how each layer failed to catch the issue
   • Understand how these failures interacted
2. Look for “Pattern Holes”
   • Are certain types of issues consistently slipping through multiple layers?
   • Do some layers tend to fail simultaneously under specific conditions?
   • Which combinations of holes appear most frequently?
3. Examine Layer Interactions
   • How did communication flow (or not flow) between teams?
   • Were there handoff points where context was lost?
   • Did automation hide important signals from human operators?

The key is to transform your post-mortems from blame-finding exercises into systematic analyses of your defensive layers. Each incident is an opportunity to understand not just what went wrong, but how your protective measures interact.

I’ve started asking these questions in every post-mortem:

• Which layers of defense were involved?
• How did each layer respond?
• What information was available at each layer?
• How could we have detected this earlier?
• What prevented existing safeguards from catching this?

This approach has revealed patterns we never noticed before. Often, what looks like a monitoring failure also involves gaps in our deployment processes, communication protocols, and system architecture.

Making It Real: Action Items for Tomorrow

Start with these concrete steps:

1. Map your current defensive layers
2. Identify your critical holes
3. Look for potential alignments
4. Plan your next layer of defense

Remember: your goal isn’t to build a perfect system. It’s to build a system that’s resilient even when imperfect. That’s the true power of the Swiss Cheese Model in tech.

The next time someone on your team points out a hole in your system, thank them. They’re not highlighting a failure—they’re helping you prevent the next system failure.

“Your engineers aren’t children, and you’re not their therapist.”

I learned this lesson the hard way during my first year as an engineering manager. I’d spent three weeks playing mediator between two senior engineers, scheduling separate meetings, carefully documenting their grievances, and crafting the perfect resolution plan. The result? Both ended up leaving the company within six months.

That experience fundamentally changed how I approach team conflicts. Here’s what actually works, backed by more than a decade of managing cross-functional engineering teams.

Spotting Conflicts Before They Explode

Most costly team conflicts don’t start with a bang — they simmer quietly until they boil over. Here’s what to watch for:

Technical Warning Signs:

• Increasing number of revert commits: When team members start undoing each other’s work, it often indicates disagreement about technical direction that they’re not discussing openly.
• Parallel implementations of similar functionality: People building duplicate systems can signal they’re avoiding collaboration due to interpersonal tension.
• Unexplained delays in cross-team dependencies: When simple cross-team requests take unusually long, it often means people are avoiding interaction with specific team members.
• Sudden increase in “offline discussions” referenced in PR comments: This usually indicates people are avoiding public disagreement, but aren’t actually resolving their differences.
• One team starting to build “wrappers” around another team’s services: A classic sign of teams losing trust in each other’s work and trying to insulate themselves.

Communication Red Flags:

• Excessive formality in Slack messages: When engineers who were once casual suddenly become formal, they’re often creating paper trails for future escalation.
• Moving discussions from public to private channels: This can indicate people are forming alliances or avoiding public confrontation.
• Declining optional cross-team meetings: Teams starting to isolate themselves is occasionally the first step toward deeper collaboration issues.
• Shoulder-tapping for “quick chats” after meetings: When people consistently want to “discuss offline,” they might be avoiding public disagreement while building resentment.

Early Intervention Strategies That Work

Here’s how to address each warning sign effectively:

For Technical Symptoms:

1. Review git history patterns: Schedule regular “architectural story” sessions where teams explain the evolution of their code. This surfaces underlying disagreements in a neutral, technical context.
2. Set up informal coffee chats with team/tech leads: These casual settings often reveal tensions that haven’t surfaced in formal meetings. The key is to ask open-ended questions about cross-team collaboration.
3. Join more code reviews as observer: Don’t interfere unless necessary, but watch for patterns in how different team members interact. This helps identify if conflicts are personal or truly technical.
4. Schedule architecture review sessions: Create a neutral space where teams must explain their technical decisions to peers. This helps surface underlying conflicts in a constructive way.

For Communication Changes:

1. Increase 1:1 frequency temporarily: Use these sessions to probe deeper into team dynamics without putting anyone on the spot publicly.
2. Add “team dynamics” section to retros: Create structured space for discussing collaboration issues before they become personal conflicts.
3. Create more pair programming opportunities: Forced collaboration can break down artificial barriers and helps people remember their colleagues’ competence. If the conflict is full-fledged, though, this can do more harm.
4. Set up cross-team technical sharing sessions: This rebuilds empathy by helping each team understand others’ challenges.

Direct Resolution Is Non-Negotiable

The moment you notice tension between team members, resist the urge to jump in and fix it. Your first response should be: “Have you talked to them directly about this?”

80% of the time, engineers avoid direct conversations because they’re uncomfortable. Too bad. Professional adults need to handle uncomfortable conversations — it’s part of the job description.

Set clear expectations: “I expect you to have a direct conversation with Alex about this by Friday. Please let me know how it goes.” Give them guidance if needed, but don’t let them off the hook.

When coaching direct conversations, provide a clear framework:

1. State the impact on your work specifically
2. Listen to their perspective without interrupting
3. Propose concrete changes moving forward
4. Set a follow-up time to review progress

Psychological Safety: The Hidden Cost of Conflict

Every unresolved conflict creates ripple effects across your team’s psychological safety. I watched a high-performing team crater after two senior engineers spent months engaging in passive-aggressive code reviews. The impact:

• Junior engineers stopped asking questions in meetings
• People avoided suggesting new approaches
• Code reviews became superficial to avoid conflict
• Innovation practically ceased

Your response to conflicts sets the tone. When you avoid addressing issues directly, you signal that maintaining comfort is more important than maintaining standards. When you play endless mediator, you signal that people aren’t expected to handle their own problems.

The Manager-Direct Report Conflict

This is the trickiest type of conflict because the power dynamic makes it hard for your direct report to address issues openly. I’ve been on both sides of this, and here’s what works:

1. Acknowledge the Power Imbalance:
   • Explicitly state that disagreement won’t affect their role or opportunities
   • Create clear escalation paths to your manager
   • Document all performance discussions separately from disagreements
2. Bring in a Third Party:
   • Ask your manager or a peer manager to mediate
   • Consider moving the report to another team or manager temporarily
   • Have HR present for sensitive discussions
3. Set Clear Boundaries:
   • Separate technical disagreements from performance discussions
   • Create written decision-making frameworks
   • Establish regular feedback sessions with your manager present

Real Example: I once had a senior engineer who fundamentally disagreed with my technical direction for the team. Steps that worked:

• Asked my manager to review our technical discussions
• Created a technical steering committee that included other senior engineers
• Set up skip-level meetings for the engineer with my manager
• Documented all technical decisions with clear rationales
• Kept performance reviews focused solely on objective metrics and actually demonstrated to the engineer that our disagreement didn’t affect their evaluation (they were still meeting expectations)

What Didn’t Work:

• Trying to handle it privately (“Let’s keep this between us”)
• Mixing technical and performance discussions
• Informal resolution attempts without documentation
• Expecting the power dynamic to resolve itself

When Direct Resolution Fails

Sometimes direct conversations don’t work. Maybe there’s too much history, or the power dynamics are complicated (like when a senior engineer and a junior QA engineer clash). That’s when you step in — but not as a mediator.

Here’s my framework:

1. Schedule one meeting with both parties
2. Set ground rules upfront:
   • No interrupting
   • No personal attacks
   • Focus on specific behaviors, not character
   • Each person states what they need to work effectively
3. Document agreed-upon behavior changes
4. Schedule a follow-up in exactly one week

The key? Keep it ruthlessly focused on future behavior changes. The moment someone starts disputing past grievances, interrupt and redirect: “We’re here to agree on how we work together going forward. What specific changes would help?”

The Developer vs. Product Manager Scenario

A common conflict I’ve seen multiple times: A developer feels the PM keeps changing requirements mid-sprint, while the PM feels the developer is inflexible and doesn’t understand business needs.

Here’s how I handle it:

1. First meeting agenda:
   • Developer commits to raising concerns about requirement changes within 24 hours
   • PM commits to consulting developer before accepting scope changes
   • Both agree to cc each other on all requirement-related communications
   • Weekly sync established to review upcoming changes –> make it part of the sprint planning or backlog refinement
2. Follow-up meeting focuses solely on:
   • Were these commitments kept?
   • What’s working/not working?
   • What needs adjustment?

When Things Go Wrong: Real Horror Stories

I’ve seen some spectacular failures in handling team conflicts. Here are some cautionary tales:

The Toxic Code Reviews Spiral:

• Senior engineer Tom started leaving increasingly harsh comments on junior engineer Sarah’s PRs
• Manager noticed but thought “they’ll work it out”
• Sarah started taking twice as long to submit work, triple-checking everything
• Other team members noticed and started walking on eggshells with their own PRs
• Three months later: Sarah quit, two other engineers were actively job hunting
• Team velocity dropped 40%
• Recovery time: 8 months and two new hires

The “Not My Problem” Backend/Frontend War:

• Backend team changed API response format without warning
• Frontend team had to scramble to fix breaking changes
• Frontend tech lead complained to manager
• Manager’s response: “Work it out between yourselves”
• Result: Teams stopped communicating directly
• All communications went through formal RFC documents
• Simple changes took weeks
• Both teams started building redundant systems to avoid dependencies
• Technical debt exploded
• Recovery time: 4 months of architectural redesign

The “Keeps The Peace” Disaster:

• Two senior architects had fundamentally different views on microservice design
• Manager kept alternating between their approaches to “keep everyone happy”
• Architecture became inconsistent
• New team members couldn’t understand why similar problems had different solutions
• Deployment complexity increased exponentially
• Both architects eventually left, frustrated
• Team inherited unmaintainable hybrid architecture
• Recovery time: 18 months of gradual system rewrites

Prevention > Cure

The best way to handle team conflicts is to prevent them. Some practices I’ve found effective:

• Clear team agreements about communication channels and response times
• Regular cross-functional pairing sessions
• Rotation of responsibilities so everyone understands each other’s challenges
• Zero tolerance for passive-aggressive behavior in code reviews or team meetings
• Regular retrospectives with honest discussion about team dynamics
• Explicit discussion of what psychological safety means in practice

The Long Game

Remember: Your goal isn’t to make everyone friends. It’s to maintain a professional environment where people can do their best work. Sometimes that means having tough conversations and making unpopular decisions.

Success looks like:

• Teams focused on shipping value rather than internal drama
• Clear expectations about professional behavior
• Quick resolution of conflicts when they arise
• Team members who can handle disagreements directly and professionally
• High psychological safety despite occasional conflicts

The best engineering managers I know aren’t conflict resolution experts – they’re experts at setting and maintaining professional standards that prevent most conflicts from escalating in the first place.

Your job isn’t to solve every interpersonal issue. It’s to create an environment where professionals can resolve their own conflicts, and to step in decisively when they can’t.

The Loyalty Myth

Tech leaders love talking about loyalty. Building loyal teams. Creating loyalty through culture. Here’s what they miss: loyalty isn’t a program you implement. It’s not free snacks or team hoodies. It’s a series of daily choices.

What Kills Loyalty

I’ve seen these destroy team trust repeatedly:

1. Empty Promises
   • Delayed promotions
   • Forgotten commitments
   • “We’ll fix that next quarter”
2. Convenience Leadership
   • Supporting team members only when it’s easy
   • Changing priorities without explanation
   • Taking credit, deflecting blame
3. False Reciprocity
   • Expecting overtime without giving flexibility
   • Demanding excellence while providing poor tools
   • Preaching growth but cutting training budgets

Building Real Trust

Here’s what actually works:

1. Show Up Daily
   • Fight for your team’s needs
   • Take the hard meetings
   • Share the real information
2. Keep Score
   • Track your commitments
   • Follow through consistently
   • Acknowledge when you fail
3. Give First
   • Protect your team’s time
   • Provide growth opportunities
   • Take blame, give credit

The Reality

A couple of years back, I lost two key engineers to a competitor. The third stayed, saying: “You’ve had my back for three years. I’ve got yours now.”

That’s the thing about loyalty — you can’t demand it. You prove you deserve it, one decision at a time.

Remember: Your team is watching what you do, not what you say.

Warning Signs

Let me share a painful lesson from my last startup. Our team prided itself on rapid incident response. Average time-to-resolution: 45 minutes. Impressive, right?

Wrong. We were missing dozens of warning signals:

• Increasing error rates in non-critical systems
• Growing technical debt in older services
• Rising frequency of “minor” incidents
• Subtle patterns in monitoring data
• Team members quietly raising concerns

The Real Cost

Here’s what firefighting actually cost us:

1. Innovation stopped
2. Team burnout accelerated
3. Technical debt compounded
4. Small problems grew into crises
5. Best engineers started leaving

Prevention Over Reaction

The turnaround started when we implemented three simple rules:

1. Track patterns, not just incidents
   • Log every small issue
   • Look for commonalities
   • Set time aside for trend analysis
2. Create space for maintenance
   • 20% of sprint capacity for system improvements
   • Regular technical debt reviews
   • Proactive monitoring upgrades
3. Reward prevention
   • Celebrate quiet weeks
   • Promote engineers who write reliable systems
   • Share prevention wins in all-hands meetings

Key Insight

The most reliable systems I’ve seen aren’t run by the best firefighters. They’re run by teams that barely fight fires at all. They smell smoke early and fix problems while they’re small.

Remember: Your job isn’t to be the hero who saves the day. It’s to build systems that rarely need saving.

the worst managers invariably find creative ways to dodge it.

Spotting the Pattern

Let me paint you a picture. Last year, I was advising a startup where the engineering director had mastered what I call “responsibility ping-pong.” Whenever a project went sideways, he’d bounce the blame between “unclear requirements,” “team bandwidth,” and my personal favorite — “unforeseen technical challenges.” Sound familiar?

The Three Classic Accountability Dodges

Here’s what I’ve seen repeatedly:

1. The Blame Shifter
   • Points fingers at other departments
   • Uses phrases like “waiting on input from…”
   • Treats retrospectives as blame-finding missions
2. The Fog Creator
   • Drowns issues in vague corporate speak
   • Never commits to specific deadlines
   • Makes everything so complex that ownership becomes unclear
3. The Eternal Optimist
   • Refuses to acknowledge problems until they’re catastrophic
   • Always says, “we’re almost there”
   • Reframes failures as “learning opportunities” without actually learning

Root Causes

Here’s the thing — most of these managers aren’t incompetent. They’re often quite brilliant technically. The root cause? They never learned that accountability isn’t about taking blame — it’s about owning outcomes.

I learned this lesson the hard way when I had to shut down a failing project I’d championed. Standing in front of my team and admitting I’d made the wrong call was incredibly uncomfortable. But something unexpected happened: team trust increased dramatically.

Making Changes

Want to shift from dodgeball to actual leadership? Start here:

1. Own the outcomes (good and bad)
2. Make commitments crystal clear
3. Create feedback loops that expose problems early
4. Normalize talking about failures
5. Reward people who raise issues early

Key Insight

The most counterintuitive thing I’ve learned? The more accountability you embrace, the less you need to worry about being blamed. Teams instinctively trust leaders who own their mistakes and focus on solutions.

Remember: your team notices everything. They see the dodge. They see the ownership. They’re just waiting to see which type of leader you choose to be.

Ever notice how often we throw around the word “just” in engineering discussions? I cringe every time I hear:

“Can’t we just use Docker to containerize the app?” “Why don’t we just add Redis for caching?” “I checked the docs – we just need to implement GraphQL, should be straightforward!”

It’s not that these suggestions are wrong or that anyone’s being intentionally dismissive. But that innocent little word “just” carries a ton of hidden implications that can poison our technical discussions.

The Invisible Baggage of “Just”

1. It Oversimplifies Complex Problems

When someone says ”just”, they’re essentially declaring something to be simple. But here’s the thing – in software engineering, nothing is as simple as it seems. Let’s break down that casual suggestion to “just implement GraphQL.”

Here’s what actually needs consideration:

• How will this impact our existing REST endpoints? Do we maintain both?
• What’s our schema design strategy? Are we doing code-first or schema-first?
• How do we handle authentication and authorization in GraphQL?
• What about rate limiting and API security?
• Do we need to implement DataLoader to avoid the N+1 query problem?
• How will we monitor query performance and complexity?
• What’s our error handling and logging strategy?
• How do we version the schema as it evolves?
• Who’s going to train the team on GraphQL best practices?
• What’s our testing strategy for resolvers?
• How do we handle data validation and input sanitization?
• What’s the migration plan for existing clients?

Suddenly “just” doesn’t seem so simple, does it?

2. It’s an Imposter Syndrome Amplifier

Picture this: You’re a developer who’s been wrestling with a problem all day. You finally gather the courage to ask for help, and a senior engineer casually says, Why don’t you just use X?”

That “just” hits like a ton of bricks. It implies that the solution was obvious – and if it wasn’t obvious to you, well…

In an industry where imposter syndrome is already rampant (studies suggest over 50% of Silicon Valley engineers experience it), we don’t need words that accidentally shame people for not seeing the “simple” solution.

3. It Kills Creative Problem-Solving

When someone presents a solution prefixed with ”just”, they’re unknowingly creating a barrier to further discussion. Who wants to be the person questioning a supposedly “simple” solution? This leads to:

• Reduced brainstorming
• Less questioning of assumptions
• Fewer alternative approaches being considered
• Missing out on potentially better solutions

Breaking the “Just” Habit

Here’s what I’ve learned to do instead:

1. Replace “just” with specific actions Instead of: “Let’s just use GraphQL” Try: “We could implement GraphQL, which would involve…”
2. Acknowledge complexity Instead of: “Just add caching” Try: “We could explore caching solutions, considering factors like…”
3. Invite discussion Instead of: “Just containerize it” Try: “What do you think about containerization as an approach?”

The Impact I’ve Seen

Since actively working to eliminate “just” from my technical vocabulary (and yes, I still catch myself using it), I’ve noticed:

• More engaged technical discussions
• Junior engineers speaking up more often
• Better exploration of edge cases
• More thorough solution designs
• Healthier team dynamics

The Path Forward

Breaking the “just” habit isn’t easy — I still catch myself reaching for it in conversations. But being mindful of its impact has made me a better communicator and, I believe, a better engineer.

Remember: No significant technical solution is ever “just” anything. Embrace the complexity, acknowledge the trade-offs, and create space for real technical discussion.

I came across some fascinating research recently that validates something I’ve observed over 15 years of working with leaders — there’s often an inverse relationship between leadership knowledge and leadership action. Researchers Ahmadi and Vogel call it “the leadership knowing-doing gap,” and their findings challenge everything we think we know about developing leaders.

The Leadership Paradox

Picture this: You’ve read the books. You’ve attended the workshops. Your shelf is lined with leadership certificates. And yet, when the moment comes to have that difficult conversation with your team member, you freeze. Or worse, you intellectualize why now isn’t the “right time” to act.

Sound familiar?

You’re not alone. In a study of 22 managers across various industries, researchers found that this gap between knowing and doing isn’t just common — it’s almost universal. But here’s what’s really interesting: The research suggests that in many cases, more leadership knowledge actually makes the problem worse.

The Three Dimensions of the Gap

The research reveals that the knowing-doing gap operates on three levels:

1. The Awareness Problem

Most leaders don’t even realize when they’re falling into the gap. Like a fish doesn’t know it’s in water, we often don’t recognize our leadership failures in the moment. We only realize it later through:

• Reflection (usually during that quiet drive home)
• Feedback (when someone finally gets brave enough to tell us)

2. The Emotional Reality

This isn’t just a cognitive issue — it’s deeply emotional. The research uncovered a fascinating spectrum of feelings:

• When the gap widens: Frustration, guilt, and anxiety
• When we close the gap: Pride, relief, and satisfaction
• The surprise: Sometimes even closing the gap feels terrible

3. The Response Pattern

Leaders typically react in one of two ways when they recognize the gap:

• Immediate action (rare but powerful)
• Planning for future action (common but often leads to procrastination)

Why We Fail at Doing What We Know

Through my own face-plants and observations, combined with some fascinating research by Ahmadi and Vogel, here’s what’s really going on:

1. The Technical Comfort Zone Trap We default to what we’re good at. Writing code feels productive. Measurable. Safe. Leadership? It’s messy, subjective, and the feedback loops are frustratingly long.
2. The Confidence Paradox Nearly half of managers report low confidence in implementing leadership behaviors. Here’s the kicker: the more you know about good leadership, the more aware you become of how much you could mess up. It’s paralysis by analysis.
3. The “I’ll Get To It Later” Syndrome 55% of managers consistently push leadership tasks to the bottom of their to-do list. We treat leadership like that gym membership we’ll “definitely use next week.”

The Controversial Truth About Leadership Development

Here’s where things get uncomfortable. The research reveals several counterintuitive findings that challenge conventional wisdom:

1. More Knowledge Can Be Dangerous

The more leadership theories you know, the more likely you are to:

• Get trapped in analysis paralysis
• Second-guess your instincts
• Look for perfect solutions instead of taking action
• Use knowledge as a shield against action

2. The Hierarchy Trap

Organizations say they want proactive leaders, but the research shows:

• 60% of managers see hierarchy as a barrier to action
• Most feel safer doing nothing than risking a mistake
• “Empowerment” often comes with invisible strings
• Middle managers feel particularly paralyzed

3. The Motivation Deception

Lack of motivation isn’t always a personal failure. Often, it’s a rational response to:

• Systems that punish leadership initiative
• Cultures that praise leadership but reward compliance
• Organizations that make leadership actions risky

What Really Keeps Us From Leading?

The research identified three critical barriers:

1. Motivation

• Individual: Personal drive and energy
• Organizational: Hierarchical constraints and mixed messages
• Reality: Most organizations unintentionally discourage leadership action

2. Prioritization

• The time trap: “Too busy” often means “too scared”
• The workload excuse: Task completion feels safer than leadership
• The reality: Leaders make time for what they truly value

3. Confidence

• The paradox: Overconfidence can be as dangerous as under-confidence
• The truth: Effective leaders often express more doubt
• The key: Building practical confidence through small wins

Breaking Free: A New Approach to Leadership

Based on the research, here’s how to actually close the knowing-doing gap:

1. Start Small

Instead of trying to transform into Satya Nadella overnight, pick ONE leadership practice to implement this week. Maybe it’s having that difficult conversation you’ve been avoiding, or finally setting up those skip-level 1:1s.

• Choose one leadership action you’ve been avoiding
• Set a 24-hour deadline to do it
• Don’t overthink it — just act

2. Create Accountability

Find another engineering leader at your level. Make a pact to try new leadership approaches and debrief weekly. Having a “spotter” makes trying new things less scary.

• Tell someone else what you’re going to do
• Set up regular check-ins
• Make your intentions public

3. Build Systems

You wouldn’t skip a critical deployment review. Treat leadership tasks the same way. I block 2 hours every morning for leadership work — no exceptions, no excuses. It’s as critical as any technical task.

• Schedule weekly reflection time
• Create feedback loops
• Establish support networks

4. Challenge the System

• Identify organizational barriers
• Build coalitions for change
• Create safe spaces for leadership practice

The Way Forward

The most powerful insight from this research isn’t about knowledge — it’s about action. Your team doesn’t need you to know more about leadership. They need you to:

• Have the difficult conversations
• Make the tough decisions
• Show up when it matters
• Act on what you already know

A Final Thought

Start with this simple exercise: Write down three leadership practices you know you should be doing but aren’t. Pick the smallest, least scary one. Do it tomorrow. Not next week. Not when you feel “ready.” Tomorrow.

Because here’s what I wish someone had told me earlier: The gap between knowing and doing never closes on its own. You have to build the bridge, one small action at a time.

Your team doesn’t need you to be perfect. They need you to show up, try things, learn, and keep going. That’s the real work of leadership – turning knowledge into action, one uncomfortable step at a time.

Your team’s last architecture debate probably wasn’t about architecture at all.

I’ve spent countless hours watching brilliant engineers argue about microservices, coding standards, and delivery timelines. Want to know the real kicker? Most of these “technical” debates aren’t technical at all – they’re human conflicts wearing a technical hat.

Let me share something that transformed how I handle team disagreements: the Thomas-Kilmann model. It’s not another framework to add to your already-overflowing tech stack. Instead, it’s a lens that reveals why your best engineers might be talking past each other (and what to do about it).

The Five Flavors of Conflict

Picture this: Two axes – Assertiveness (how much you push for your own way) and Cooperativeness (how much you work with others). This creates five distinct ways people handle conflict:

1. The Bulldozer (Competing)
   • “My way or the highway”
   • Great for: Production emergencies
   • Terrible for: Team morale, pretty much everything else
2. The Bridge Builder (Collaborating)
   • “Let’s find the best solution together”
   • Great for: Complex architectural decisions
   • Terrible for: When the building’s on fire
3. The Diplomat (Compromising)
   • “Let’s meet in the middle”
   • Great for: Sprint planning disputes
   • Terrible for: Core technical values
4. The Ghost (Avoiding)
   • “What conflict? I don’t see any conflict”
   • Great for: Cooling heated moments
   • Terrible for: Actually solving anything
5. The Pushover (Accommodating)
   • “Whatever you think is best”
   • Great for: Building relationship credit
   • Terrible for: Your long-term sanity

https://www.bitesizelearning.co.uk/resources/thomas-kilmann-conflict-model

Why This Matters

Let me tell you about a recent train wreck I witnessed. Two senior engineers were locked in an endless debate about moving to microservices. One kept pushing hard (Competing), while the other kept backing down (Accommodating).

The real issue? Not architecture at all. The “Competitor” was worried about scaling the team, while the “Accommodator” was concerned about maintenance complexity. Both valid points, totally different conversations.

Three Ways to Use This Tomorrow

1. Know Your Default Mode — Look, I’ll go first – I’m naturally an Avoider. I hate conflict. But knowing this helps me consciously choose when to step up instead of step back.
2. Spot Others’ Patterns — That teammate who always pushes their solution? Classic Competitor. The one who always says, “whatever works for everyone”? Textbook Accommodator. Knowing this helps you adapt your approach.
3. Change the Game — Here’s the magic move: When you spot someone in Competing mode, don’t compete back. Try collaboration instead. It’s like jiu-jitsu for office politics.

The Plot Twist

Here’s what nobody tells you: No mode is “best.” Even Collaboration, which sounds ideal, isn’t always right. Sometimes you need quick decisions (Competing), sometimes you need to preserve relationships (Accommodating), and sometimes you really do need to hit pause (Avoiding).

The Real Win

The goal isn’t to eliminate conflict – that’s impossible and actually undesirable. The goal is to handle it productively.

Next time you’re in a technical debate that seems to be going nowhere:

1. Step back
2. Identify the modes at play
3. Choose your response consciously
4. Focus on outcomes, not winning

Remember: That heated debate about tabs vs. spaces? It might not be about formatting at all. Maybe it’s about feeling respected, heard, or valued.

I’ve written in the past about why we should stop winning arguments.

Pro tip: If you notice the same people always clashing in the same ways, try mapping their conflict modes. It’s like having the cheat codes to team dynamics.

What’s your default conflict mode? Has it served you well in tech leadership?

PS: Yes, I used the Avoiding mode while writing this post. I got up and made tea twice. Self-awareness is a journey, folks.

I have one job: get out of people’s way. Everything else is just details.

That’s what I told my CEO during my first week as CTO, and his face was priceless. But after two decades of building and leading engineering teams, I’ve learned that the best leaders aren’t the ones with all the answers – they’re the ones who help others find them.

When I stumbled into coaching training a good 10 years ago (mostly to shut up our Head of People who wouldn’t stop recommending it), I didn’t expect it to fundamentally rewire my approach to leadership. But here we are. Let me share four counterintuitive lessons that transformed how I lead.

1. Be the Chaos Translator

We’ve all been there – sitting in a meeting that feels like a verbal mosh pit, everyone talking past each other, and you’re wondering if you’re the only one lost. Plot twist: you’re not.

I used to think being a leader meant having all the answers. Now I realize it’s about asking the right questions and – more importantly – being the person who can distill chaos into clarity.

Example: Last month, our backend team was spiraling into a debate about microservices architecture. Instead of jumping in with my opinion, I simply said: “So what I’m hearing is we’re worried about service boundaries impacting development speed. Is that the core issue here?”

The room went quiet. Then someone said, “Actually, no – we’re more concerned about monitoring overhead.” Boom. Real problem identified, solution found in 20 minutes.

2. Turn Arguments into Investigations

Here’s a radical idea: the next time someone storms into your office fuming about a production issue, don’t match their energy. Instead, get curious.

I learned this the hard way after a particularly heated exchange with our DevOps lead about deployment protocols. Mid-argument, I caught myself and asked, “What’s making this change feel urgent to you?”

Turns out he wasn’t just being difficult – he had spotted a security vulnerability that needed immediate attention. My defensive stance nearly buried critical information.

3. Kill Your Inner Micromanager

“But I’m responsible for the outcome!”

That’s what the voice in your head screams when you see a junior dev taking an approach you wouldn’t. Silence that voice. It’s lying to you.

The truth? Every time you swoop in to “fix” something, you’re teaching your team that:

• Their judgment isn’t trusted
• They don’t need to think things through
• You’ll always be there to clean up

Want to scale your team? Start trusting them to be, as coaching taught me, “naturally creative, resourceful, and whole.”

4. Sometimes the Best Move Is No Move

We’re conditioned to act. Ship features. Fix bugs. Optimize performance. But sometimes, the best thing you can do is… nothing.

I recently watched two senior engineers argue about an architectural decision. My old self would have jumped in with a solution. Instead, I waited. They eventually arrived at a better solution than I would have proposed.

The real skill? Knowing when to:

• Let a team struggle through a problem
• Give space for conflicts to resolve naturally
• Allow people to learn from their mistakes

The meta-lesson underneath all of this? Understanding boundaries. Knowing where your responsibilities end and others’ begin isn’t just good leadership – it’s essential for scaling both your team and yourself.

Think of it this way: your job isn’t to be the smartest person in the room. It’s to create an environment where smart people can do their best work.

PS: Want to test if you’re creating that environment? Take a week off. If everything falls apart, you’re not leading – you’re controlling. Trust me, I learned this one the hard way. Twice.

Think about that for a second. Nearly half your engineering team is spinning their wheels multiple times every single week because they can’t access the information they need.

I learned this lesson the hard way a couple of years back. Walking to get coffee with one of my senior engineers, he was excitedly sharing how he’d finally cracked a thorny problem that had blocked him for a week. Right as we reached the coffee machine, a staff engineer from another team casually mentioned he’d solved the exact same issue two months ago.

Talk about a facepalm moment. 🤦‍♂️

The Real Cost of Knowledge Silos

• Engineers feeling frustrated and isolated
• Innovation dying in departmental dead ends
• Your best people solving the same problems over and over

The 2024 StackOverflow Developer Survey backs this up: 45% of developers report that their ideas never make it across organizational boundaries. We’re literally building walls between our best minds.

The Four Horsemen of Knowledge Apocalypse

After years of scaling engineering teams, I’ve identified four core problems that create and reinforce knowledge silos. Let’s break them down:

1. The Vertical Information Trap

Most organizations are built like medieval kingdoms — information flows up and down, but rarely sideways. You end up with these beautiful ivory towers of knowledge that never talk to each other.

What actually works: Engineering Guilds have been my secret weapon here. But not the kind that just become complaint forums. The successful ones I’ve built follow three iron-clad rules:

• Align with company strategic goals (no pet projects)
• Get official leadership buy-in for time allocation
• Let engineers choose projects based on growth goals

2. The Documentation Curse

Ever noticed how documentation is either non-existent or so overwhelming no one reads it? Both are equally useless.

Here’s what I’ve learned works: Minimum Viable Documentation. Focus on capturing two things:

• Core decision reasoning
• Fundamental principles

Pro tip: Architecture Decision Records (ADRs) are your friend here. We embed them right in the codebase, tracking everything from development patterns to third-party package decisions.

3. The Onboarding Gap

Your onboarding process is either creating bridges or digging moats. There’s no middle ground.

The game-changer for us has been the buddy system, but with a twist. It’s not just about code walkthroughs. Our buddies focus on:

• Intensive pair programming sessions
• Cross-team product deep dives
• Social integration (yes, this matters more than you think)

4. The Tribal Mindset

Ever heard an engineer say “that other team doesn’t get it”? That’s tribal thinking, and it’s toxic.

The antidote? Radical transparency. We’ve had massive success with:

• Open architecture review sessions (anyone can join)
• Regular technical meetups (both formal and lightning talks)
• Making knowledge sharing part of our career framework

The Path Forward

Here’s the uncomfortable truth: information hoarding is often incentivized in tech organizations. People hold onto knowledge because they think it makes them indispensable.

Want to break this cycle? Start rewarding the sharing of knowledge more than its possession. Make “multiplier effects” part of your promotion criteria. Celebrate the engineers who make others better.

Remember: your 10x engineers aren’t the ones who know everything. They’re the ones who help everyone else level up.

What knowledge silos are you seeing in your organization? How are you breaking them down? Give it some thought.

“When a measure becomes a target, it ceases to be a good measure.”

Goodhart’s Law gets thrown around constantly in tech, business, policy discussions — anywhere metrics and goals are involved (which is everywhere).

But I’m going to argue that while Goodhart’s Law captures an important truth, it’s often misunderstood and misapplied in ways that limit its usefulness as a practical guide for using metrics effectively.

Here’s why:

1. It’s often interpreted as a blanket condemnation of metrics. But Goodhart’s Law is really about the misuse of metrics, not metrics themselves. All metrics can be gamed, but that doesn’t negate their value when used judiciously. The problem arises when single metrics become sole targets.
2. It assumes bad faith. Not all optimization is harmful gaming. Sometimes people pursue metrics because they believe (rightly or wrongly) that the metric tracks the underlying goal. Goodhart’s Law implicitly dismisses this possibility.
3. It ignores the necessity of metrics in complex systems. In any large organization or system, metrics are essential for coordination, incentive alignment, and performance tracking. Goodhart’s Law offers little guidance on how to use metrics well, only a warning about how they can fail.
4. It’s silent on the alternatives. If using metrics as targets is bad…then what? Never have any quantifiable goals? Rely purely on intuition and vibes? The implication is to avoid metrics, but total rejection of measurement is far more dangerous. Good management requires good measurement.
5. It’s often applied selectively. People are quick to criticize metrics they dislike as Goodhart’s Law violations, while rarely applying the same scrutiny to metrics they favor. The law is used as a rhetorical cudgel rather than a consistent principle.

So what’s the alternative? I believe Goodhart’s Law is a useful cautionary tale, but not a complete philosophy of metrics. A better approach acknowledges that metrics are flawed but indispensable tools for coordination and optimization at scale.

Some key principles:

• Expect metrics to be gamed, and design them with aligned incentives in mind
• Use multiple metrics to balance different goals and limit over-optimization
• Continuously evaluate and evolve metrics to keep pace with changing circumstances
• Combine metrics with qualitative measures and human judgment
• Foster a culture of questioning metrics and rewarding the surfacing of flaws

In short: Goodhart’s Law is a warning, not a prohibition. Metrics are like powerful drugs — dangerous if misused, but also capable of enabling incredible feats of coordination and optimization. The hard work is in developing the wisdom and skill to use them well.

So while Goodhart’s Law is a useful check on naive metric-setting, it’s only the beginning of the conversation around building healthy, high-performing organizations and systems. The real challenge is moving beyond simple maxims to grapple with the irreducible complexity of metrics in practice.

Used wisely, measurement is essential to intelligent action at scale. Goodhart’s Law doesn’t change that — it just raises the bar for how thoughtful and vigilant we must be. Let’s embrace that challenge, learn from our failures, and keep striving to measure what matters.

I’ve sat through more painful, awkward, tense meetings than I care to count. You know the ones — where egos clash, agendas collide, and you can practically feel the frustration radiating off people in waves. Where afterward, you want to down a stiff drink (or three) just to recover from the emotional whiplash.

But over the years, I’ve discovered a secret weapon for defusing those powder keg situations. A simple technique that can instantly reset the entire dynamic of a meeting gone off the rails.

I’m talking about the art of naming what’s happening in the room.

It sounds deceptively simple. But wielded skillfully, it’s like having a conversational superpower. One that can transform you from a helpless bystander into the person who gets things back on track when everything’s falling apart.

Let me break it down for you.

The Anatomy of a Meeting Meltdown

Picture this: You’re in a high-stakes product roadmap meeting. The room is a pressure cooker of competing priorities and barely concealed tension. Engineering wants more time for tech debt. Product is pushing for ambitious new features. Sales is clamoring for that one big enterprise client’s pet request. And leadership keeps bringing up hitting next quarter’s numbers.

What typically happens?

1. The Laundry List of Grievances: Everyone takes turns stating their case. Listing out all the reasons why their priority is The Most Important Thing Ever.
2. Selective Hearing: As others speak, instead of listening, people are mentally rehearsing their counterarguments.
3. Frustration Builds: The more people talk past each other, the more irritated everyone becomes. Body language gets defensive. Tone gets snippy.
4. Assumptions Run Wild: In the absence of clear communication, people start ascribing motives. “Engineering just doesn’t care about growth!” “Product is trying to empire build!”
5. Emotional Amplification: As the perceived stakes get higher, so do the emotional responses. Fear, anger, and anxiety start driving the conversation instead of logic.
6. Unproductive Circular Arguments: The discussion goes in endless loops, with people restating the same points over and over, hoping repetition will somehow change minds.
7. Resolution by Exhaustion: Eventually, people get worn down. A “decision” gets made, but usually it’s just kicking the can down the road or going with whatever the highest-ranking person in the room wanted.

Sound familiar? Yeah, I thought so.

We’ve all been there. Hell, I’ve been guilty of contributing to this toxic cycle more times than I’d like to admit. But there’s a better way.

The Power of Stating the Obvious

Here’s the wild thing: In most of these situations, everyone in the room can sense that things have gone off the rails. We can feel the rising tension. We can see the crossed arms and furrowed brows. We can hear the edge creeping into people’s voices.

But hardly anyone ever says it out loud.

We’re all so caught up in our own perspectives and agendas that we forget to take a step back and acknowledge the collective experience happening in the room.

That’s where the simple act of naming what’s happening comes in. It’s like hitting a giant “pause” button on the spiraling negativity.

Some examples:

• “Hey folks, I’m noticing that we seem to be talking in circles here. Can we take a step back?”
• “I’m sensing a lot of frustration in the room right now. What’s going unsaid that we need to address?”
• “It feels like we’ve shifted from problem-solving mode to defending our positions. How can we realign?”

When done well, these interventions can be transformative. They snap people out of their mental tunnels and create space for a reset.

Why It Works: The Psychology Behind Naming

So why is this so effective? There are a few key psychological principles at play:

1. Pattern Interruption: Our brains love to get stuck in grooves. By explicitly naming what’s happening, you disrupt the negative pattern that’s developed.
2. Shared Reality: Acknowledging the collective experience creates a sense of “we’re all in this together” rather than adversarial positions.
3. Emotional Regulation: Putting words to the tension provides a bit of distance, helping to de-escalate heightened emotions.
4. Increased Self-Awareness: It prompts everyone to take a mental step back and observe their own behavior more objectively.
5. Psychological Safety: By demonstrating it’s okay to address interpersonal dynamics directly, you create a safer space for honest dialogue.
6. Refocusing on Shared Goals: It reminds everyone that you’re theoretically all there to accomplish something together, not just to win individual battles.

The Risks (And How to Mitigate Them)

Now, I’ll be real with you – this technique isn’t without its risks. Used clumsily, it can backfire and make things even worse. Here are some potential pitfalls to watch out for:

1. Projecting Your Own Feelings: Be careful not to assume everyone else is experiencing things the same way you are. Use “I” statements and ask open questions. Bad: “We’re all getting really pissed off here.” Better: “I’m noticing I’m feeling frustrated. How’s everyone else feeling?”
2. Singling People Out: Calling attention to one person’s reaction can make them feel attacked or put on the spot. Bad: “John, you look really angry right now.” Better: “I’m sensing some strong emotions in the room. What’s going on for folks?”
3. Derailing Productive Conversation: Sometimes things get a bit heated because people care deeply. Don’t interrupt flow state if real progress is actually happening.
4. Overuse: If you’re constantly meta-commenting on the conversation, it can become distracting and annoying. Use this technique judiciously.
5. Lack of Follow-Through: Naming what’s happening is only valuable if it leads to constructive next steps. Be prepared to suggest a path forward.

The key to avoiding these pitfalls? A healthy dose of emotional intelligence and reading the room (ironic, I know).

Tactical Tips for Naming What’s Happening

Alright, so you’re sold on the concept. But how do you actually put it into practice? Here are some tactical tips I’ve learned (often the hard way):

1. Keep it Short and Sweet: You don’t need to launch into a lengthy analysis. A brief, neutral observation is often most effective.
2. Use a Calm Tone: Your delivery matters as much as your words. Keep your voice steady and non-confrontational.
3. Mind Your Body Language: Uncross your arms, make open eye contact, lean in slightly. Physically embody the openness you’re trying to create.
4. Ask, Don’t Tell: Instead of declarative statements, try phrasing things as questions. “Are we still aligned on our goals here?” invites reflection better than “We’ve lost sight of our goals.”
5. Focus on Collective Experience: Use “we” language to reinforce the idea that you’re all in this together. “It seems like we’re having trouble finding common ground” vs. “You all aren’t listening to each other.”
6. Acknowledge Uncertainty: It’s okay to admit you might be misreading things. “I might be off base here, but it feels like…”
7. Offer a Way Forward: Don’t just point out the problem – suggest a potential solution or next step. “Should we take a 5-minute breather and then regroup?”
8. Know When to Escalate: Sometimes you need to involve a higher-up or neutral third party. If things are really off the rails, don’t be afraid to loop in additional help.

A Real-World Example

Let me share a personal anecdote that illustrates the power of this approach:

A few years back, I was part of a critical meeting about our company’s expansion strategy. We had leaders from Product, Engineering, Sales, and Ops all in the room (well, on the Zoom – hello, pandemic life).

The stakes were high. We were debating whether to pursue an aggressive growth strategy or take a more conservative approach given market uncertainties. Tensions were running hot.

About 45 minutes in, it was clear we were getting nowhere. The head of Sales was talking over everyone, Engineering was getting increasingly defensive, and our usually level-headed CPO was visibly seething.

That’s when our VP of People spoke up. In a calm voice, she said:

“Hey team, I’d like to pause for a moment. It feels like we’ve shifted from collaborative problem-solving to defending our individual territories. I’m wondering if we can take a step back and remind ourselves of our shared goals here?”

The effect was almost magical. You could see people physically relax a bit. There were a few sheepish looks exchanged. Our CEO, to his credit, jumped in to reframe the conversation around our core company mission.

We didn’t magically solve everything in that meeting. But that small intervention completely shifted the tone. We were able to have a much more productive discussion and eventually reach a compromise everyone could live with.

Beyond Meetings: Applications in 1:1s and Team Dynamics

While this technique is incredibly powerful for large, contentious meetings, don’t sleep on its usefulness in other contexts:

1. 1:1s: Noticing and naming subtle shifts in your direct reports’ demeanor can open up crucial conversations. “I’ve noticed you seem less enthusiastic in our planning sessions lately. What’s going on?”
2. Team Retrospectives: Normalizing the practice of naming dynamics can create a culture of openness and continuous improvement. “It feels like we’re all a bit hesitant to give direct feedback. How can we create more psychological safety?”
3. Cross-Functional Collaboration: When working across teams, explicitly acknowledging different priorities and working styles can prevent a lot of friction. “I realize Engineering and Product often have different timelines in mind. Let’s talk about how we can better align.”
4. Onboarding New Team Members: Helping new folks understand unspoken team dynamics by naming them explicitly can speed up integration. “You might notice our standups tend to run long because we value deep discussion. Let me know if that’s not working for you.”
5. Personal Growth: Practicing this at work will likely spill over into your personal life too. Being able to name dynamics in relationships of all kinds is a valuable life skill.

In Conclusion: Your New Conversational Superpower

Listen, I get it. In the moment, speaking up to name a difficult dynamic feels scary. There’s always the fear that you’ll make things worse or look foolish.

But here’s the thing: 9 times out of 10, everyone else in that room is feeling the same discomfort you are. By finding the courage to name it, you’re not being a troublemaker — you’re being a leader.

It takes practice to get comfortable with this skill. Start small. Try it in lower-stakes situations first. Pay attention to how others react and refine your approach.

Over time, you’ll develop an almost sixth sense for when an intervention is needed. You’ll become that person who can deftly guide conversations back on track when they’re derailing.

The person who can cut through bullshit and get to the heart of issues.

The person who isn’t afraid to say what everyone else is thinking.

In other words? A truly exceptional leader.

So, next time you’re in a meeting that’s going off the rails, take a deep breath and ask yourself: What’s really happening in this room right now?

And then? Say it out loud.

You might just be surprised at the impact those few words can have.

Research and observations across companies like Stripe, Uber, and several high-growth startups reveal that the most effective tech leaders master three distinct styles: conviction, policy, and consensus. Here’s why each matters and how to develop them.

The Leadership Style Trinity

Most leaders naturally gravitate toward one style. Some are the decisive type who love making bold calls (conviction). Others are process people who create scalable systems (policy). And then there are the coalition builders who excel at getting buy-in (consensus).

But here’s the uncomfortable truth: relying on just one style is leadership malpractice.

Let’s examine why.

Style 1: Leading with Conviction

Consider the last truly contentious technical decision a team might face. Perhaps choosing between monolith vs. microservices, adding a new programming language, or completely reorganizing the engineering department.

These situations share three characteristics:

• Extreme ambiguity
• High uncertainty
• Significant organizational inertia

This is where conviction leadership shines. It’s about making personal decisions on critical, contentious problems and seeing them through to execution.

Real Talk: When Conviction Works (And When It Doesn’t)

At Carta, the engineering leadership faced a major inflection point with their quality strategy. The existing processes weren’t scaling, and they had competing visions for the path forward. After deep analysis and stakeholder discussions, the leadership made a conviction call to implement a radical new approach.

Key lesson: The success wasn’t just in making the decision – it was in the follow-through. The team spent weeks communicating the vision, addressing concerns, and pushing through the inevitable friction.

But contrast this with a similar situation at Calm, where a conviction-based approach to quality strategy failed spectacularly. Why? Because the leadership missed crucial context and didn’t test the decision widely enough before pushing forward.

Style 2: Leading with Policy

Some decisions happen so frequently that making each one a special snowflake is organizational suicide. Consider:

• Quarterly planning
• Hiring and promotions
• Headcount allocation

This is where policy leadership becomes crucial. It’s about creating consistent frameworks that scale across the organization.

The Stripe Example

Stripe transformed their candidate review process from a haphazard exercise into a well-oiled machine. The key wasn’t in making better individual decisions – it was in creating a robust policy that:

1. Defined clear evaluation criteria
2. Established consistent decision-making processes
3. Built in feedback loops for continuous improvement

But here’s where it gets interesting: they tried the same policy-driven approach with Agile development practices, and it backfired. Why? Because they treated something that needed situational flexibility as a one-size-fits-all policy.

Style 3: Leading with Consensus

Sometimes decisions arise where:

• Context is scattered across multiple stakeholders
• There’s no clear decision-maker
• The impact is significant but infrequent

This is consensus territory. And make no mistake – it’s often the most challenging style to master.

The Uber Monolith Story

Uber faced the classic monolith decomposition challenge. No single person had complete context across all affected systems. The solution? They formed a decision-making group that:

• Represented all key stakeholders
• Established clear decision criteria
• Created a shared understanding of the problem space

The result was a successful decomposition strategy that had broad buy-in across the organization.

But contrast this with a reduction-in-force (RIF) situation at Calm. The leadership tried to build consensus around the approach, but the reality was that this type of decision needed conviction leadership instead. The lesson? Not every decision should be consensus-driven, even if it feels more comfortable.

Developing Your Leadership Style Portfolio

Here’s the good news: these styles are learnable skills, not innate traits. Here’s a practical approach to developing them:

1. Audit Your Current Style

• Track your next five meaningful decisions
• Note which style you naturally used
• Identify your comfort zone and blind spots

2. Force Style Diversity

• Once a month, intentionally pick a problem to solve using your least comfortable style
• Start with lower-stakes decisions to build confidence
• Gradually tackle more significant challenges

3. Create Learning Loops

• Document outcomes of decisions made with each style
• Analyze what worked and what didn’t
• Adjust your approach based on feedback

The Style Selection Framework

When faced with a decision, ask:

• Is this a highly ambiguous, contentious issue that needs decisive action? → Conviction
• Is this a frequent decision that would benefit from consistent handling? → Policy
• Is this an infrequent decision with distributed context and no clear owner? → Consensus

Moving Forward

The mark of a truly effective tech leader isn’t mastery of any single style – it’s the ability to fluently switch between styles based on the situation at hand.

Start by auditing your leadership style portfolio. Where are the gaps? Which style feels most uncomfortable? That’s probably where the biggest opportunity for growth lies.

Remember: The goal isn’t to become equally comfortable with all styles (that’s probably unrealistic), but to be competent enough in each to deploy them effectively when the situation demands it.

The challenge for every leader: For the next significant decision, pause and consciously choose a leadership style rather than defaulting to comfort zones. The results might be surprising.

The best tech leaders aren’t the ones who make the best decisions – they’re the ones who know how to make decisions in the best way for each situation.

The post was heavily inspired by this post by Will Larson.

Three years into my role as a Principal Engineer at [redacted], I found myself in a crucial architecture review meeting that would determine the technical direction of our entire platform. The room was filled with senior leaders, product managers, and fellow engineers. I had meticulously prepared our technical proposal, backed by weeks of research, benchmarks, and proof-of-concepts.

The proposal got absolutely destroyed. Not because of technical flaws – the engineering was solid. It died because I fundamentally misunderstood how decisions actually get made in large technical organizations.

See, I had made the classic engineer’s mistake: believing that the best technical solution would win on its own merits. I had spent countless hours perfecting our performance metrics and scalability projections, but virtually zero time building coalitions, understanding competing priorities, or managing key stakeholders before the meeting.

That painful experience taught me something crucial: technical excellence is necessary, but not sufficient for driving real change in tech organizations. True technical leadership requires understanding and effectively navigating power dynamics – something most engineers are never taught and often actively resist learning.

After 15+ years building and leading engineering teams across various tech companies, and countless conversations with friends at FAANG giants about their experiences, I’ve learned that power in tech organizations operates by a specific set of rules. Rules that might make many engineers uncomfortable, but that you ignore at your own career’s peril.

Let’s talk about how power actually works in tech companies – not the sanitized version you’ll find in management books, but the real, messy, human dynamics I’ve observed and tested throughout my career.

The Reality Check

Most engineers I know have a deeply uncomfortable relationship with organizational power. There’s this persistent belief in our industry that technical merit alone should drive decisions – as if we’re all living in some pure meritocracy where the best code always wins.

I see this mindset everywhere: in the senior engineer who believes their decade of technical excellence should speak for itself, in the team lead who avoids playing politics on principle. In the architect who thinks detailed technical documents will somehow magically convince the organization to adopt their solution. I was all of these people in the past. It felt noble.

Let me be brutally honest: this mindset is career suicide.

The reality I’ve observed across multiple companies (and heard echoed by friends at every major tech company) is far messier. Technical decisions are rarely made on purely technical grounds. They’re made through a complex web of relationships, timing, organizational priorities, and yes – politics.

Here’s what I mean:

• That architectural decision? It’s just as much about who you convinced before the meeting as it is about your elegant system design.
• That promotion you’re aiming for? It depends as much on who knows your work as it does on the work itself.
• That critical project you want to launch? Its success hinges as much on stakeholder management as it does on clean code.

“But that’s not fair!” I hear you say. “We should focus on building great technology, not playing political games!”

I used to think exactly the same way. Then I watched project after project fail not because of technical problems, but because I and other engineers refused to engage with organizational dynamics. I saw brilliant technical solutions get shelved while objectively inferior approaches won out, simply because their champions understood how to navigate the system.

Here’s the uncomfortable truth: by refusing to engage with organizational power dynamics, you’re not taking some noble stand. You’re just choosing to be powerless. And when competent engineers choose to be powerless, we all lose – because it means important technical decisions end up being made by people who might not understand their full implications.

Think about it this way: Would you deploy code without understanding how it works? Would you integrate with a system without learning its protocols? Of course not. Yet, many of us try to navigate organizations without understanding their fundamental operating principles.

Rule 1: Get Out of Your Own Way

Let’s start with the biggest obstacle to your effectiveness as a technical leader – and I can say this with confidence because it was my biggest obstacle for years.

It’s not your technical skills. It’s not your company’s processes. It’s not even your manager.

It’s the stories you tell yourself about power and influence.

I see these self-limiting narratives play out constantly in engineering teams. They usually sound something like this:

• “I’m just a tech person, I don’t understand office politics”
• “If I focus on anything besides coding, I’m selling out”
• “Leadership should recognize my work without me having to promote it”
• “I’m not ready for that role/project/promotion yet”
• “Seeking influence feels manipulative”

Sound familiar? I cringe remembering how many times I repeated these exact phrases to myself.

Here’s a real example: A couple of years ago, our company needed someone to lead a critical platform migration. I initially held back from volunteering because I didn’t feel “ready” – I thought I needed to understand every technical detail perfectly first. Meanwhile, a peer with less technical expertise but more confidence stepped up. Guess who got to shape the entire technical direction of our platform for the next year?

The engineering mindset that makes us excellent at building systems often sabotages us when it comes to building influence. We’re trained to identify every potential point of failure, to anticipate edge cases, to strive for perfection. These are fantastic traits for writing reliable code. They’re paralyzing when applied to organizational dynamics.

Look, I get it. The idea of actively seeking power or influence can feel uncomfortable, even dirty. But here’s what I’ve learned: power isn’t inherently good or bad – it’s a tool. And like any tool, its impact depends entirely on how you use it.

Think of it this way: Would you rather have technical decisions made by people who deeply understand and care about engineering excellence, or by those who just happened to be better at playing the game?

The first step in getting out of your own way is recognizing these self-limiting beliefs for what they are – bugs in your mental model of how organizations work. They’re not protecting your integrity; they’re limiting your impact.

Ready to break this down into actionable steps?

1. Start noticing your automatic “no”s
   When opportunities arise, pay attention to your instant rejections. Are they based on real limitations, or just comfortable excuses?
2. Challenge your “readiness” assumptions
   You’ll never feel 100% ready. Neither does anyone else. The difference is they act anyway.
3. Reframe “politics” as “organizational dynamics”
   It’s not about manipulation; it’s about understanding how human systems work.
4. Audit your self-talk
   Replace “I’m not a political person” with “I can learn to be more influential while staying true to my values.”

Rule 2: Break the Rules Strategically

Some of the most impactful technical changes I’ve seen weren’t approved – they were apologized for after the fact.

Let me share a story that changed my whole perspective on rule-breaking in tech organizations. At a previous company, we had this painfully slow approval process for new technologies. Every new library or tool needed to go through three different committees. Standard big-company stuff.

One of our senior engineers decided this was killing innovation. Instead of following the process for adding a new caching layer, he quietly built a proof-of-concept during a hack week, demonstrated it solving real production issues, and presented it as a fait accompli. Was management initially annoyed? Absolutely. Did it matter once they saw the 30% performance improvement? Not one bit.

Here’s the key: he broke the rules strategically. He didn’t ask for permission, but he also didn’t recklessly ignore legitimate concerns. He built in monitoring, wrote thorough documentation, and had a rollback plan ready. In other words, he broke the process rules while respecting the engineering principles behind them.

This is what I call “strategic rule-breaking,” and it’s a crucial skill for driving change in tech organizations. But – and this is important – it’s not about being a cowboy coder or ignoring processes for the sake of it.

Here’s my framework for strategic rule-breaking:

1. Identify the “Real” Rules vs. the “Process” Rules

• Real Rules: Security requirements, data privacy, production stability
• Process Rules: Approval chains, documentation formats, meeting requirements

2. Calculate the Risk-to-Impact Ratio

• High Impact, Low Risk: Perfect for strategic rule-breaking
• High Impact, High Risk: Need more preparation and safety nets
• Low Impact: Not worth the political capital

3. Build Safety Nets

• Have a rollback plan
• Document everything
• Monitor obsessively
• Build quiet support before going public

4. Choose Your Battles — I’ve seen too many engineers die on hills that didn’t matter. Save your rule-breaking capital for things that really move the needle.

Here are some examples of strategic rule-breaking that I’ve seen work:

• Bypassing the full approval process by building a prototype “just for testing”
• Using a new technology in a non-critical service to prove its value
• Creating a “shadow” documentation system that people actually use
• Starting informal cross-team collaborations without going through official channels

And here are some that usually backfire:

• Pushing code directly to production to skip code review
• Ignoring security protocols to ship faster
• Surprising executives with major architecture changes
• Breaking team processes without bringing others along

The art of strategic rule-breaking is knowing which rules protect the organization and which ones protect the status quo. The former deserve our respect; the latter deserve our scrutiny.

The goal isn’t to be a rebel. The goal is to drive positive change. Sometimes that means working within the system. Sometimes it means creating a new path. The trick is knowing which approach serves your ultimate objective better.

Rule 3: Master Your Presence

Let me tell you about two architects I’ve worked with. Both were brilliant technically. Both had deep system knowledge. Both regularly presented architecture proposals to senior leadership.

The first one, Alex, would dive deep into technical details, qualifying every statement with “I think” or “maybe.” Their presentations were technically flawless but filled with caveats and nuance.

The second, Sarah, would start with the business impact, speak with conviction, and save the technical details for Q&A. Her proposals weren’t always technically superior to Alex’s, but guess whose architectures got approved more often?

“But that’s just politics!” I used to think. “We should focus on technical merit!”

Here’s the reality I’ve learned: Your presence – how you carry yourself, communicate, and show up in rooms where decisions are made – matters just as much as your technical chops. It’s not about manipulation; it’s about effectively conveying your expertise.

The good news? Presence is a technical skill like any other. You can debug and optimize it.

Here’s my technical spec for commanding presence:

Core Components:

1. Voice Configuration

• Remove hedge words (“just,” “maybe,” “I think”)
• Lower your tone at the end of sentences
• Pause for effect after important points
• Speak 20% slower than you think you should

2. Body Language Settings

• Take up physical space (don’t shrink in your chair)
• Keep your hands visible and use deliberate gestures
• Maintain eye contact 60-70% of the time
• Stand when presenting (even on Zoom, it affects your voice)

3. Communication Protocol

• Start with impact, not implementation
• Use silence strategically (don’t fill every gap)
• Answer the question that should have been asked
• Learn to say “I don’t know” without apologizing

4. Emotional State Management

• Channel nervousness into focused energy
• Practice controlled emotional expression
• Stay calm during confrontation
• Use passion strategically

Implementation Examples:

Instead of: “I think maybe we could try implementing a caching layer which might improve performance…”

Say: “Adding a caching layer will improve response times by 40%. Here’s how…”

Instead of: “Sorry, I don’t know the exact numbers off hand…”

Say: “I’ll get those specific numbers for you. The key point is…”

Instead of: “This might be a stupid question, but…”

Say: “I want to make sure I understand correctly…”

Error Handling:

• If you make a mistake, acknowledge it clearly and move on
• If you lose composure, take a deliberate pause
• If challenged, respond to the intent behind the question
• If you ramble, stop and reset with a clear statement

Advanced Features:

1. Reading The Room

• Notice power dynamics
• Track engagement levels
• Identify allies and skeptics
• Adapt in real-time

2. Energy Management

• Match then lead the room’s energy
• Use intensity variations purposefully
• Create momentum at key points
• Know when to pull back

Presence isn’t about being the loudest or most charismatic person in the room. It’s about ensuring your technical expertise gets the attention and respect it deserves.

I still see too many brilliant engineers whose ideas get overlooked not because they’re wrong, but because they haven’t mastered the art of presence. Don’t let that be you.

Rule 4: Build Your Tech Leadership Brand

Most engineers don’t like the idea of a “personal brand.” It feels fake, corporate, inauthentic – everything we hate about modern workplace culture.

But here’s the reality: You already have a brand. It’s what people say about you when you’re not in the room. The only question is whether you’re actively shaping it or letting it develop by default.

I learned this lesson the hard way. For years, I was known as “the debugging guy” – great for job security, terrible for career growth. Every production issue landed on my desk, while strategic architectural decisions happened without me. I had accidentally branded myself into a corner.

Think of your tech leadership brand as an API. What endpoints are you exposing? What’s your interface contract with the organization? Most importantly, what responses are you known for generating?

Here’s how to architect your tech leadership brand:

Core API Endpoints:

1. Technical Expertise

• Document your knowledge (write those design docs!)
• Share learnings from incidents
• Create reusable solutions
• Mentor other engineers

2. Strategic Thinking

• Connect technical decisions to business impact
• Propose forward-thinking solutions
• Question status quo constructively
• Think in systems, not just features

3. Problem Solving

• Take on complex challenges
• Drive cross-functional solutions
• Build coalitions across teams
• Share your thought process

4. Reliability

• Keep your commitments
• Communicate proactively
• Handle pressure gracefully
• Be consistent in your interactions

Implementation Patterns:

1. Internal Visibility

• Write technical blog posts for your company wiki
• Lead architecture reviews
• Host brown-bag sessions
• Contribute to design docs
• Participate in code reviews meaningfully, not just rubber-stamping

2. External Recognition

• Speak at industry conferences (or even just local meetups)
• Write blog posts about solved problems
• Contribute to open source
• Share learnings on social media (without breaking confidentiality)

3. Relationship Building

• Build allies across departments
• Mentor junior engineers
• Support peer growth
• Connect with leaders in other teams

Anti-Patterns to Avoid:

• Being the “no” person who shoots down ideas without alternatives
• Becoming the “emergency only” engineer
• Getting pigeonholed into one technology or system
• Being known only for pointing out problems
• Developing a reputation for perfectionism that blocks progress

Real Example: A few years ago, I noticed I was being left out of crucial platform decisions. After some feedback, I realized I was known as someone who “makes things too complex.” Fair criticism – I love elegant solutions. So I deliberately started prefacing my suggestions with simplified versions that could be built upon later. Within months, I was being pulled into architectural discussions earlier because people knew I could “break down complex problems.”

Brand Monitoring:

• Pay attention to how you’re introduced in meetings
• Notice which problems get routed to you
• Watch for patterns in feedback
• Monitor what kind of questions you’re asked
• Track which meetings you’re invited to (or not)

Course Corrections: If you find your brand isn’t serving you:

1. Identify the gap between current and desired perception
2. Create opportunities to demonstrate desired traits
3. Find allies who will vouch for your growth
4. Actively seek roles that align with your target brand
5. Gradually shift your contribution patterns

Your technical brand isn’t about self-promotion. It’s about making your value visible so you can have maximum impact.

Rule 5: Network in Engineering Organizations

“I hate networking.”

I’ve heard this from virtually every engineer I’ve ever mentored. And I get it. The word conjures up images of awkward meetups, insincere LinkedIn messages, and that one sales guy who won’t stop talking about synergy.

But here’s the truth: the most successful engineers I know are all exceptional networkers. They just don’t call it networking. They call it “grabbing coffee to discuss that interesting scaling problem,” or “helping debug that weird production issue,” or “whiteboarding that new architecture idea.”

About 10 years ago, our team was fighting for resources to rebuild a critical service. Despite clear technical merit, we couldn’t get traction. Then I discovered another team had already solved 60% of our problems in their domain. Not through official channels – I learned this over lunch with their tech lead, someone I’d met during an overnight production incident. Within weeks, we had a shared roadmap and twice the resources.

That’s real engineering networking. Not exchanging business cards, but building a web of technical relationships that amplify your effectiveness.

Here’s how to network like an engineer:

Technical Alliance Building:

1. Cross-Pollination

• Join architecture review boards
• Participate in post-mortems (even for other teams)
• Contribute to shared libraries
• Review PRs outside your immediate team

2. Knowledge Exchange

• Host technical brown bags
• Start an engineering book club
• Create internal tech newsletters
• Build shared documentation

3. Problem-Solving Networks

• Debug sessions
• System design discussions
• Code reviews
• Incident response

Authentic Connection Building:

1. Follow the Trail of Interesting Problems

• Who’s solving similar challenges?
• Who has expertise you need?
• Who could benefit from your lessons learned?
• Who’s working on tech you want to learn?

2. Create Value First

• Share useful documentation
• Offer code review help
• Provide technical mentorship
• Build tools others can use

3. Maintain Genuine Relationships

• Follow up on technical discussions
• Share relevant articles/papers
• Remember personal details
• Celebrate others’ wins

Anti-Patterns to Avoid:

• Only networking when you need something
• Staying within your technical comfort zone
• Treating every interaction as a transaction

Real Example: One of my best engineers maintains a simple system: Every week, she has lunch with someone from a different engineering team. No agenda, just a random technical discussion. These lunches have:

• Prevented duplicate work across teams
• Surfaced common problems we could solve together
• Created back-channel communication paths that proved crucial during incidents
• Built a network of allies for larger technical initiatives

The ROI of Technical Networking:

1. Faster Problem Solving

• Know who to ask
• Access tribal knowledge
• Get rapid feedback
• Find existing solutions

2. Career Opportunities

• Hear about projects early
• Get recommended for roles
• Find mentors naturally
• Build your reputation

3. Technical Influence

• Build support for initiatives
• Gather early feedback
• Create coalition for change
• Access different perspectives

Effective networking in engineering is about building a distributed system of knowledge and capabilities. Each connection is a potential API you can call when needed.

Rule 6: Actively Use Your Power (for good)

The biggest mistake new engineering leaders make isn’t abusing power – it’s being afraid to use it at all.

I watched a talented staff engineer on my team sit silently through six months of architecture meetings, carefully building consensus for every minor decision. Meanwhile, tech debt accumulated, deadlines slipped, and morale dropped. Their fear of being “too pushy” was actually hurting the team.

Here’s the counterintuitive truth I’ve learned: Thoughtfully exercising power makes you more influential, not less. When used well, power creates momentum, builds trust, and drives results.

Let me break this down:

Types of Power in Engineering Organizations:

1. Technical Authority

• Architecture decisions
• Technology choices
• Quality standards
• Technical direction

2. Resource Control

• Project prioritization
• Team allocation
• Budget influence
• Tool selection

3. Information Access

• System knowledge
• Historical context
• Cross-team insights
• Strategic planning

4. Relationship Capital

• Trust from leadership
• Team loyalty
• Cross-functional allies
• External networks

Using Power Effectively:

1. Decision Making

• Make clear decisions when you have authority
• Own the consequences
• Explain your reasoning
• Stay consistent

2. Setting Standards

• Define what good looks like
• Hold the line on quality
• Push back on unreasonable demands
• Model best practices

3. Protecting Your Team

• Shield from organizational chaos
• Push back on unrealistic deadlines
• Fight for resources
• Create space for focus

4. Driving Change

• Challenge broken processes
• Question assumptions
• Propose solutions
• Lead by example

Real Example: Three jobs back, our team was drowning in technical debt while leadership pushed for new features. Instead of just complaining, I:

• Used my management authority to declare two weeks of cleanup work
• Leveraged my relationships to get buy-in from product
• Applied my resource control to prioritize critical fixes
• Drew on my information access to demonstrate the long-term cost of inaction

The result? Short-term pushback but long-term respect. The team’s velocity improved 40% over the following months.

Common Power Mistakes:

1. The Consensus Trap

• Trying to get everyone to agree
• Avoiding necessary conflict
• Diluting decisions
• Paralysis by discussion

2. The Perfectionist Block

• Waiting for complete information
• Over-engineering solutions
• Analysis paralysis
• Endless refinement

3. The Authority Dodge

• Deferring to hierarchy unnecessarily
• Hiding behind process
• Avoiding responsibility
• Playing it safe

4. The Power Vacuum

• Not setting clear direction
• Allowing drift
• Ignoring problems
• Avoiding tough conversations

Power Use Framework:

1. Evaluate the Situation

• What authority do you have?
• What’s at stake?
• Who’s impacted?
• What’s the timeline?

2. Consider Options

• Direct action
• Influence approach
• Coalition building
• Gradual change

3. Execute Decisively

• Clear communication
• Defined timeline
• Success metrics
• Follow-through

4. Own the Outcome

• Monitor impact
• Adjust as needed
• Learn from results
• Share learnings

Power isn’t about control – it’s about impact. Used thoughtfully, it’s how we turn technical expertise into organizational change.

Rule 7: Deliver Results and Control the Narrative

The most painful lesson I’ve learned in tech leadership? Great results don’t speak for themselves. In fact, they barely whisper.

Let me share a story that still makes me cringe: My team once completed a massive infrastructure migration – on time, under budget, zero downtime. A genuine technical triumph. But six months later, in my performance review, my CTO mainly remembered the two small outages during the project. Why? Because I let others control the narrative about our work.

Meanwhile, a peer team’s partial migration of a less critical system was celebrated as a massive win. The difference? They treated communication as a core part of delivery, not an afterthought.

Here’s how to make sure your results actually land:

The Results-Narrative Framework:

1. Before You Start

• Set clear success metrics
• Document current pain points
• Identify key stakeholders
• Establish baseline measurements

2. During Execution

• Regular status updates
• Early wins communication
• Proactive issue management
• Stakeholder engagement

3. After Completion

• Impact quantification
• Success story crafting
• Lessons learned sharing
• Credit distribution

Narrative Control Patterns:

1. Frame the Context

• Why this matters
• What’s at stake
• Who benefits
• How it fits strategic goals

2. Shape the Story

• Clear before/after
• Concrete improvements
• Relatable examples
• Memorable metrics

3. Control the Flow

• Regular updates
• Consistent messaging
• Strategic timing
• Multiple channels

Real Examples of Effective vs. Weak Narratives:

Weak: “We improved database performance.”

Strong: “We cut customer wait times by 40% by optimizing our database, directly improving our most common user workflow and saving 1,000 engineering hours per quarter.”

Weak: “The migration is complete.”

Strong: “We’ve eliminated our biggest source of production incidents by migrating to the new platform, reducing on-call burden by 60% and enabling three new strategic initiatives.”

Common Narrative Mistakes:

• Focusing purely on implementation

• Drowning in details

• Missing business impact

• Ignoring non-technical stakeholders

• Downplaying achievements

• Avoiding self-promotion

• Hiding team wins

• Assuming visibility

• No success metrics

• Poor progress tracking

• Unclear impact

• Lost context

• Not recognizing contributors

• Hoarding visibility

• Failing to build allies

• Missing team celebrations

Building Your Narrative System:

1. Documentation

• Keep an “achievements” document
• Track metrics religiously
• Document key decisions
• Save positive feedback

2. Communication Channels

• Regular status emails
• Team demos
• Executive updates
• Cross-team sharing

3. Stakeholder Management

• Regular check-ins
• Progress previews
• Early feedback loops
• Success sharing

4. Team Amplification

• Highlight individual contributions
• Create visibility opportunities
• Share credit broadly
• Build advocacy networks

Your results create value, but your narrative multiplies it. The best technical solution only matters if people understand and remember its impact.

A Summary – tl;dr

Seven rules. Thousands of lines of code. Countless meetings. And one fundamental truth: technical excellence alone won’t get you where you want to go.

I started this post by sharing my own painful architecture review failure. Since then, we’ve explored how power actually works in tech organizations, and how to use it effectively while staying true to our engineering values.

Let’s recap what we’ve covered:

The Seven Rules of Power in Tech:

1. Get Out of Your Own Way — Your limiting beliefs are your biggest bottleneck
2. Break the Rules Strategically — Know when process serves progress and when it serves politics
3. Master Your Presence — Command attention like you command your code
4. Build Your Brand — Shape how your value is perceived
5. Network in Engineering Organizations — Build your distributed system of influence
6. Actively Use Your Power — Impact requires action, not just position
7. Deliver Results and Control the Narrative — Great work invisible is still invisible

But here’s what keeps me up at night: Too many brilliant engineers opt out of this game entirely. They see the complexity of organizational dynamics and decide it’s not worth engaging with. They retreat into their technical comfort zones, letting others make the decisions that shape our industry’s future.

We can’t afford that anymore.

The stakes are too high. The technical decisions being made today will shape how we build software for years to come. We need strong technical voices in those conversations. We need engineers who can navigate both technical complexity and organizational dynamics. We need you to step up.

Yes, it’s messy. Yes, it’s uncomfortable. Yes, it requires skills they didn’t teach you in CS classes. But so did distributed systems, and you figured those out.

Think of organizational dynamics as just another system to debug. It has its protocols, its failure modes, its optimization opportunities. The rules I’ve shared aren’t about playing politics – they’re about understanding and effectively operating within human systems.

The question isn’t whether you’ll engage with power dynamics. You already are. The question is whether you’ll do it intentionally and effectively.

Where to start? Pick one rule that resonates with you. The one that made you most uncomfortable might be the best candidate. Start small. Run experiments. Debug your approach. Iterate.

Remember: Your technical expertise is valuable. But your ability to drive change through an organization – to turn that expertise into impact – that’s invaluable.

The future of tech is too important to leave to chance. Or to leave to those who might not understand the full implications of their technical decisions.

It’s time for engineers to step up. To learn these skills. To engage with these dynamics. To drive change.

Your code deserves to be deployed. Your ideas deserve to be heard. Your expertise deserves to shape the future.

But first, you need to understand how power works.

What’s your next commit(ment) going to be?

In the fast-paced world of tech, where lines of code and system architectures often take center stage, it’s easy to overlook the most critical component of any successful team: the human element.

As a tech leader, you’re not just managing projects or overseeing sprints – you’re guiding a group of brilliant, complex individuals. And let’s face it, sometimes understanding people (including yourself) can be harder than debugging a gnarly piece of legacy code.

Enter the Johari Window – a psychological tool that’s about to become your new favorite framework. No, it’s not named after some obscure programming language or a new JavaScript library. It’s a powerful model for improving self-awareness and team dynamics that’s been hiding in plain sight since the 1950s.

Why Does This Matter for Tech Leadership?

In an industry where technical skills often take center stage, it’s easy to overlook the human element. But the most successful tech companies aren’t just those with the most advanced tech stacks or the most elegant algorithms. They’re the ones with leaders who can build cohesive, high-performing teams. They’re the ones who recognize that emotional intelligence and self-awareness are just as crucial as technical expertise.

The Johari Window gives you a framework to develop these critical soft skills. It’s like a debugging tool for your leadership style, helping you identify blind spots, uncover hidden potential, and create an environment where your team can thrive.

In the following sections, we’ll dive deep into the four quadrants of the Johari Window, explore how to apply it in a tech leadership context, and provide practical exercises you can start using with your team today. We’ll also look at common pitfalls to avoid and the tangible ROI of investing in self-awareness.

Are you ready to level up your leadership game? Let’s open up the Johari Window and see what we discover.

The Four Quadrants of the Johari Window

Before we dive into how this applies to tech leadership, let’s break down the basics. The Johari Window isn’t about actual windows (sorry, frontend devs). It’s a 2×2 grid with four quadrants that represent different aspects of self-awareness and interpersonal dynamics. Think of it as a SWOT analysis for your personality.

1. Open Area (Arena)

This is the “public” you. The skills, knowledge, and behaviors that both you and others know about. It’s like your LinkedIn profile, but honest. In a tech context, this might include your coding languages, your knack for debugging, or your ability to explain complex concepts in simple terms.

For example, everyone on your team might know that you’re a whiz at optimizing database queries and that you always bring donuts to Friday standups. The larger this area, the more transparent and effective your communication tends to be.

2. Blind Spot

Here’s where it gets interesting. These are things others know about you, but you don’t realize about yourself. Maybe you have a habit of interrupting during standups, or perhaps you’re actually a CSS genius but don’t recognize it.

In tech leadership, your blind spots could be seriously impacting your team’s performance. For instance, you might think you’re great at delegating, but your team feels micromanaged. Or you might not realize that your “constructive criticism” comes across as harsh and demotivating.

3. Hidden Area (Façade)

This is what you know about yourself but keep hidden from others. It could be your secret talent for interpretive dance, or your crippling impostor syndrome. In a professional context, it might be your uncertainty about a new technology stack, or your struggle with work-life balance.

While it’s natural and sometimes necessary to keep some things private, an overly large hidden area can hinder trust and authentic communication within your team.

4. Unknown Area

This is the realm of untapped potential. Things neither you nor others know about you. Maybe you’d be an amazing public speaker, or perhaps you have a knack for quantum computing that you haven’t discovered yet.

In tech, where the landscape is constantly evolving, this quadrant is particularly exciting. It represents the skills you might develop, the leadership potential you haven’t tapped, and the innovative ideas you haven’t even dreamed up yet.

The goal of using the Johari Window is to expand that Open Area. The larger it is, the more effectively you can lead, communicate, and collaborate. It’s like increasing your codebase’s test coverage, but for your personality.

In the next sections, we’ll explore how to apply this model specifically to tech leadership, with practical strategies for expanding your Open Area and leveraging the insights from each quadrant to become a more effective leader.

Johari Window Team Workshop Playbook

Objective: To help team members understand themselves and each other better, improving communication and collaboration.

Duration: 2-3 hours

Materials Needed:

• Large whiteboard or virtual whiteboard (e.g., Miro)
• Sticky notes (physical or virtual)
• Pens
• Timer

1. Introduction (15 minutes)
   • Explain the Johari Window concept and its four quadrants
   • Emphasize the importance of honesty and psychological safety
   • Set ground rules for respectful communication
2. Individual Reflection (20 minutes)
   • Have each team member write down:
     • 5 professional qualities they believe they possess (Open Area)
     • 3 skills they’d like to improve (Hidden Area)
     • 2 areas where they’d like feedback (potential Blind Spot)
     • 1 wild career aspiration (Unknown Area)
3. Open Area Expansion (30 minutes)
   • Each person shares their 5 qualities with the group
   • Team members add sticky notes with additional positive qualities they’ve observed
   • Discuss any surprising additions
4. Blind Spot Exploration (40 minutes)
   • Form pairs or small groups
   • Each person shares the areas where they want feedback
   • Partners provide constructive feedback
   • Return to the larger group and share key insights
5. Hidden Area Reveal (30 minutes)
   • Voluntary sharing of skills team members want to improve
   • Brainstorm ways the team can support each other’s growth
   • Identify any common areas for team-wide improvement
6. Unknown Area Speculation (20 minutes)
   • Share wild career aspirations
   • Team members suggest potential hidden talents or opportunities for each other
   • Discuss how to create space for exploration and growth within the team
7. Team Johari Window (30 minutes)
   • Create a large Johari Window for the entire team
   • Collaboratively fill in each quadrant based on the day’s discussions
   • Identify team-wide strengths, blind spots, hidden challenges, and growth opportunities
8. Action Planning (15 minutes)
   • Individual: Each person writes down one action to expand their Open Area
   • Team: Decide on 2-3 team-wide initiatives based on the workshop insights
9. Closing Reflection (10 minutes)
   • Go around the room, with each person sharing one key takeaway
   • Discuss how to keep the Johari Window conversation ongoing