Forem: Jono Herrington

The Promotion Happened. The Job Did Not.

Jono Herrington — Mon, 18 May 2026 15:36:49 +0000

Orgs often mistake meeting voice for delivery leverage ... confidence without multiplication. This piece is the mirror. What happens when someone earns the title and the system does not update around them? The promotion happened. The job did not. That gap is where resentment grows quietly.

On the other side, I have also lived the better version of this story.

When an engineer asked what it would take to reach the next level, the honest answer was not want it more. It was partnership on a real map ... behaviors, scope, evidence. We built clarity with HR, wrote what each level meant, and tracked progress like adults. Within a year he moved to senior. Within two and a half years he replaced me. That is what promotion support is supposed to feel like when the system works.

So I am not cynical about growth. I am cynical about growth theater.

Here is what the job did not usually means in practice.

Same scope, new title. More pressure, no new authority, no new tools, no real sponsorship.

Ambiguous expectations. Leadership says senior now, but the team still treats them like yesterday's version.

No air cover. They get pulled into every emergency because they are now one of the strong ones, which is not a job description. It is extraction.

None of that requires a villain. It is what happens when calendars are full and nobody owns the transition.

If you promote someone and do not change what they are allowed to own, you did HR paperwork, not leadership work.

The org side receipt I keep returning to

The org side receipt is the same headline as the top of this page ... interview voice without leverage.

I have watched a contractor shaped lead show up with strong language, strong opinions, and lead shaped signals, then fail where leverage matters ... delegation, sequencing, delivery through others. A basic navigation effort can stretch for months not because the problem is impossible, but because the seat was wrong and the system rewarded the wrong signals.

That is not a personal attack on contractors as a category. It is a warning about what we optimize for when we confuse confidence for competence.

The healthy counterweight is the map we built when someone asked what next level actually meant ... behaviors, scope, evidence, not vibes.

The first ninety days after leveling

If you are the manager, treat the first ninety days like a small product launch.

Rewrite scope in writing. What decisions can they make without you? What decisions still require you? Where are the edges?

Assign one real ownership domain. Not busywork. Something with consequences and visibility.

Pair them with a sponsor outside your chain when the role needs cross functional credibility, not only your private praise.

If you are the newly leveled engineer, push for the same clarity with respect and persistence. A title without a contract is a costume.

Why quiet quitting starts in the promotion gap

People do not always leave because they are unhappy.

Sometimes they leave because they finally admit the growth story was mostly theater.

The promotion was real on paper. The job was not real in practice. The cognitive dissonance is exhausting because it forces a smart person to choose between two bad stories ... either leadership is incompetent, or they are not actually valued. Humans tend to pick the story that protects the ego longest and hurts the career fastest.

If you want the bus factor adjacent warning here, it is simple. Hero dependent systems punish everyone when the hero needs air. Promotions that add title without distributing ownership create a different kind of heroism ... the kind where the newly titled person becomes a sponge for risk.

The HR update is not the ceremony

Here is where promotions go quietly wrong even when HR does everything right on paper.

The system updates. The title changes. Slack congratulations roll in. Then Monday shows up and the work looks identical.

If you are the manager, that is not a win. That is a trust leak.

A promotion without a scope delta is like shipping a major version bump with no breaking changes listed. It might be true occasionally. Usually it means you are not being honest about what changed.

The growth story that is not mine, but belongs in the same file

I once told a front end developer the harder truth ... his growth had stalled relative to where the market was moving. Not because he was bad. Because he was good at the wrong narrow thing for too long. He did the work, learned new depth, and it helped him land his next role with confidence.

That story is not the same as a title without a job. It is the mirror image.

One is a system failing to define reality. The other is a person choosing reality after someone finally named it.

Your job as a manager is to name reality early enough that people do not have to discover it through pain.

Sponsorship is not a compliment

If you want a promotion to come with a job, you need sponsorship that shows up in rooms the engineer cannot access yet.

Not cheerleading. Air cover. Conflict navigation. Budget defense. Cross functional credibility that cannot be earned only by shipping tickets faster.

If your promotion plan stops at "you are doing great," you are not building leaders. You are collecting talent like trading cards.

Internal mobility is still promotion work

Sometimes the best promotion is not a new title at all. It is a move that gives a strong engineer a new hill to climb before they flatline.

I have said yes fast when a critical engineer asked to move, even when my first reaction was an oof in my gut. The team survived because context was distributed and two engineers stepped into the space instead of pretending the gap was invisible. She stayed years longer because someone treated growth as real, not as a retention threat.

That is promotion quality too. It is just wider than HR paperwork.

The first twelve weeks are not decoration

If you want a practical shape for the post promotion window, think in weeks, not vibes.

Early weeks are where you renegotiate scope in writing without making the person feel punished for being promoted. Middle weeks are where you intentionally create a visible win that belongs to them, not to you, so the org updates its mental model. Later weeks are where you tighten feedback because the title changed the power dynamic even if nobody admits it.

If you cannot describe what should be harder and what should be easier after twelve weeks, you did not promote someone into a new job. You promoted them into a new stress profile.

The confession

I have promoted optimism before I promoted clarity.

Not on purpose. Not with bad intent. Because optimism feels kind in the moment and clarity feels like you are picking a fight with someone's dream.

Clarity is the kind part long term.

The identity threat

If you are a manager who thinks a promotion conversation ends when HR updates the system, you are not developing people.

You are updating a database.

Titles are cheap. Scope is expensive. Pay the bill on purpose.

This week

If you recently promoted someone, send them a one page note ... new ownership boundaries, first deliverable, and how you will measure success in thirty days.

If you were recently promoted, ask for that same page.

If the room goes fuzzy, you learned something valuable about whether the promotion came with a job.

If you do not like what you learned, do not update your resume first.

Update the contract.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Boring Is the Feature When Money Is Moving

Jono Herrington — Sun, 17 May 2026 13:24:50 +0000

I have spent more than a decade in commerce shaped engineering. The industry loves a shiny launch narrative. The job that actually keeps companies alive is quieter ... boring reliability when money is moving, promotions behaving, inventory telling the truth, checkout finishing under stress.

This is the same argument I make about boring platforms in general, just with the volume turned up.

When traffic spikes, nobody cares how clever your roadmap slide was in March. They care whether the system holds. Peak is not a branding exercise. It is a truth serum for how you built.

The latest new front door season is still the same plumbing lecture with sharper teeth ... stale feeds, inventory truth, checkout paths that assumed a human. Glamour points at the protocol slide. Customers point at the receipt.

The trap is seductive.

Teams want novelty because novelty feels like progress. Leadership wants headlines because headlines feel like momentum.

Meanwhile the foundation is doing the real work ... idempotent jobs, sane timeouts, honest cache behavior, operational playbooks people actually run, and change management that does not treat production like a lab.

That work is not intellectually empty. It is socially unrewarded until the day it saves you.

If your system only looks healthy at average load, you do not have a healthy system. You have a good demo.

What I optimize for before peak

I am not going to pretend there is one checklist for every stack. Commerce is too heterogeneous for that. Salesforce shaped commerce is not the same animal as a greenfield headless experiment, and pretending otherwise is how teams ship the wrong kind of clever.

I will name the categories I refuse to be cute about.

Truth under load. Inventory, pricing, entitlement logic has to mean the same thing at one x and ten x. If your truth is eventually consistent, be honest about what eventually means in dollars.

Operational memory. What happens after the page quiets down matters more than how polished the wiki looks. If critical context still lives in one person's head, peak will eventually introduce that person to a vacation day and introduce you to regret.

Change discipline. The week before peak is not the week to slip in a clever refactor because inspiration struck on a whiteboard.

The month where "just an API layer" becomes eighteen months

If you want a commerce shaped external pattern that matches peak pressure, it is the same story I keep telling about agent readiness ... product sees headlines, engineering discovers stale feeds, inventory latency, checkout paths that assumed a human, promotions engines that throw on non human sessions. The protocol slide looks clean. The plumbing argues back.

That is not pessimism. It is the commerce backend meeting machine speed honesty version of the same boring truth ... money moving does not care about your roadmap narrative.

It also sits next to the simpler truth I write about elsewhere ... tech debt did not start with AI. AI just made the interest rate visible.

The boring technology argument is not nostalgia

People hear boring and think old.

I hear boring and think load bearing.

Boring is what lets you sleep when the graph spikes. Boring is what keeps customer service from drowning in self inflicted fires. Boring is what keeps engineering from doing heroics on two hours of sleep as a lifestyle.

That is not a lack of ambition. It is ambition aimed at the customer instead of the ego.

The internal mobility proof point

I have seen strong teams survive movement because context was distributed before the move, not after it.

When a critical engineer moved teams in one chapter of my work life, there was no panic because runbooks existed, ownership was real, and two engineers who shared context stepped up into the space instead of pretending the gap was invisible. That is not a fairy tale about documentation. It is what happens when operational memory is treated like a behavior contract, not a wiki hobby.

That story is people first and systems first at the same time. If you romanticize only the people part, you will keep building hero dependent teams. If you romanticize only the systems part, you will build process museums nobody runs.

The platform story nobody wants until they want it

There is another boring lesson hiding inside platform work at big consumer scale.

The platform you dismiss as legacy is often the thing holding the money hose steady while you chase novelty elsewhere. I have watched the industry tell itself tidy stories about replatforming as if risk is a spreadsheet cell you can delete. Then peak arrives and the org discovers, again, that enterprise customers do not buy vibes ... they buy receipts.

I am not writing that to dunk on any vendor. I am writing it because the emotional mistake is the same every time ... confusing the front door with the foundation.

Peak economics in one sentence

Peak does not reward the team with the hottest architecture diagram.

Peak rewards the team that treated boring like revenue.

Peak is rude. It charges admission in outages.

The quiet after the sprint lie

There is a cultural story that says speed is always virtue.

Sometimes speed is just panic wearing a OKR.

I have lived the quarter where velocity looked strong and the system felt wrong underneath ... shortcuts, tests skipped, reviews turning into approvals because everyone was tired of being the blocker. That is not a single villain story. It is what happens when leadership rewards the number without rewarding the constraints that keep the number honest.

If you want the longer version of why stabilization matters, read the quiet after velocity when the sprint stops being a flex and starts being a signal.

Peak does not care about your narrative arc. Peak cares whether you built load bearing truth.

The customer service echo chamber

Here is a boring detail that separates commerce shaped engineering from slide engineering.

When the site misbehaves under load, customer service becomes the human sensor network for your failures. They hear the tone customers use when money is involved. They hear the repeat complaints that engineering dashboards smooth into averages.

If your engineering org treats customer service like a nuisance department instead of an early warning system, you are not serious about reliability. You are serious about looking serious.

Boring reliability is the work that reduces those calls ... not because you hate customer service, but because you respect them enough not to fund the same fire drill every peak.

The intersection of traffic and identity

Commerce engineering at serious scale teaches you something about identity that slide decks skip.

Your brand is not your marketing site. Your brand is what happens when a million people do the same boring action at once ... search, filter, cart, checkout, account, loyalty, returns. Under load, customers do not experience your architecture diagram. They experience latency, wrong price, wrong inventory, broken promo, a spinner that lies.

That is identity under pressure. It is also the true definition of quality.

So when I say boring is the feature, I mean it as a customer statement, not as an engineering aesthetic. Boring is the feature because trust is the product, and trust is built from predictable outcomes when money is moving.

Black Friday is not a mood

People love the war story version of peak ... lights low, monitors glowing, energy drinks, hero saves.

That version sells.

The version that keeps companies alive is quieter ... the load test that found the embarrassing serialization bug in September, the cache policy that did not lie under pressure, the feature flag plan that lets you turn off the risky slice without turning off revenue, the rollback drill your team actually practiced instead of only documented.

If your peak plan depends on adrenaline, your peak plan depends on luck.

Luck is not a strategy. It is a confession you are not ready to say out loud.

This week

Pick your highest revenue window in the next ninety days. Name the top three failure modes that would embarrass you in front of the CFO.

Then ask one question ... which of those failure modes got cheaper in the last sprint because of a boring change?

If the answer is none, you are still funding theater.

Theater is fun until the money moves.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

The Model Fills the Envelope. You Have to Shrink It.

Jono Herrington — Fri, 15 May 2026 14:11:16 +0000

The diff lands in the queue at 1,200 lines. The reviewer opens it, scrolls to the bottom, leaves a comment about a variable name, and clicks approve. Nobody reads it all the way through. Nobody has time. The PR merges. Two sprints later something breaks and nobody can trace it back to where it came from. This is not a story about one team. This is the pattern I keep seeing everywhere AI code generation has been handed to engineers without anyone defining what a reviewable pull request looks like.

The model fills the envelope until leadership shrinks the envelope. And the reason most teams haven't shrunk it is that nobody has written down what "one pull request" is actually supposed to carry.

When the Standard Is Implicit, the Standard Is Whatever Is Convenient

Most engineering teams have a vague sense that PRs should be reasonably sized. Reviewers know when a diff is too big. Engineers know when they're shipping too much at once. But knowing something and writing it down are different things. What isn't written down becomes whatever is convenient under delivery pressure.

I say pattern because I've watched it from the outside and I've lived it from the inside. Before we built our merge policy, my own team had the same implicit standard everyone has ... PRs should be reasonably sized. Nobody had written down what reasonably sized meant. AI assisted output volume climbed and we kept reviewing the way we always had, which meant we weren't really reviewing at all. We were clearing the queue.

I've watched the same thing happen across teams at different scales. AI code generation shows up. Output volume triples. PR sizes climb. Review times get longer. And somewhere in that climb, the cultural norm shifts without anyone deciding it should. The rubber stamp becomes the default not because reviewers stopped caring but because they're rational actors inside a system that never told them what a reviewable PR actually is.

If you have ten engineers generating AI assisted code and each of them is merging three times what they used to, your review queue has become something nobody designed for. And if you haven't updated your definition of "good" to match the new volume, you're running a 2022 process on a 2026 codebase.

Your review queue has become something nobody designed for.

Shallow and Vertical

On my team, we fixed this with what we call shallow vertical pull request standards.

Shallow means not too many lines. A PR that can be read, understood, and reviewed in a single sitting. Not a tour of the entire codebase. Not a week's worth of changes packaged together because breaking them apart felt like extra work. Shallow means the reviewer can hold the whole thing in their head at once.

Vertical means one concern, all the way through. Not horizontal across three features and two services. Not "I was in this area anyway so I also fixed this other thing." One behavior, one slice, from top to bottom. The PR does one thing and does it completely.

Together those two constraints eliminate most of the PRs that become rubber stamps. A shallow vertical PR is reviewable by definition. It has a clear scope, a readable size, and a single purpose the reviewer can actually evaluate. If a PR fails either test, it's not ready for review yet. It's not a PR yet. It's a work in progress that needs to be broken up.

We set our line limit based on DORA metrics data. Not a gut feel. Not what sounded right in a meeting. We looked at our lead time for changes at different PR sizes and found the inflection point where review quality and cycle time both degraded. The data made the conversation easy. It wasn't me telling engineers their PRs were too big. It was the data showing what PR size correlated with slower delivery and more rework. That number became the ceiling. Any PR above it gets closed automatically.

Not flagged. Not sent back with a polite comment. Closed.

The Automation Is the Policy

That last part is what most teams skip. They write the standard in a wiki page, hold a team meeting about it, and move on. The standard lives there for three months until delivery pressure builds and the first exception gets made and then the exception becomes the new standard, which is just the old implicit standard with a document attached to it.

We automated enforcement because we knew ourselves. The uncomfortable conversation about a PR being too big is one most engineers don't want to have and most reviewers will avoid if they can find a reason to. Automation removes the conversation. The system closes the PR. The engineer breaks it up. The culture doesn't depend on someone's willingness to hold the line in the moment.

The culture doesn't depend on someone's willingness to hold the line in the moment.

This is the part that actually changed the behavior. Not the document. The automation made the policy real. A standard that only exists when someone is brave enough to enforce it is not a standard. It's a suggestion with a header.

What "Good" Means on the Page

Writing down shallow vertical standards is step one. Anchoring the line limit to DORA data is step two. Automating enforcement is step three. But there's a fourth piece that doesn't get enough attention.

The standard also has to define what the reviewer is responsible for. Not just the size of the PR but the quality of the review. What does "approved" mean? Did you read it? Did you understand the scope? Did you check that it does one thing and doesn't break anything adjacent to that one thing?

Most teams have never written this down. The reviewer's job is implicit, and what's implicit becomes a checkbox. Scroll to the end. Leave a comment. Click approve.

When we defined the review standard alongside the PR standard, something shifted. Reviewers knew exactly what they were being asked to do. Engineers knew what they were asking reviewers to evaluate. The implicit negotiation about what "approved" actually means got replaced by a written one, and the written one didn't leave much room for the rubber stamp. The standard created accountability in both directions. The engineer is accountable for the size and scope of what they submit. The reviewer is accountable for what their approval actually means.

We held ourselves to it. Not perfectly. Not without friction. But the friction was the point. The friction meant the standard was real.

Three Things Before the End of the Week

This isn't a platform problem. It doesn't require a new tool or a two-week sprint to implement. It requires a decision and then follow-through.

Write down shallow vertical PR standards in one paragraph. What is a PR allowed to carry? One behavior. One slice. What is the line ceiling? Anchor it to your DORA data if you have it ... lead time for changes will show you where PR sizes are costing you cycle time. If you don't have DORA data yet, start with five hundred lines as a ceiling and adjust from what the data shows you.

Then automate enforcement. Most CI systems can close a PR that exceeds a line count. This is not a complex implementation. It's a policy decision dressed up as a configuration file. The automation makes the policy real in a way a wiki page never will.

Then define what reviewer approval means. One paragraph. What did you actually check? What are you signing off on? When your engineers know what "approved" requires, the approval means something again.

The standard won't be perfect on the first version. Write it anyway. The act of writing it forces the conversation your team hasn't had yet.

The act of writing it forces the conversation your team hasn't had yet.

The Model Will Fill Whatever Space You Give It

AI code generation is not slowing down. The output volume is not going back to what it was three years ago. The teams that figure out how to review AI assisted code well are going to move faster than the teams still treating it like it's a one engineer, one feature world.

The teams that don't figure it out will keep merging rubber stamped diffs and wondering why the codebase is getting harder to work in. Why incidents trace back to changes nobody really reviewed. Why the senior engineers are spending more time firefighting than building.

Leadership's job here isn't to review every PR. It's to define what a reviewable PR looks like. Until you write that down, the model fills the envelope. And your team stamps whatever lands in the queue.

That's a leadership problem. Not an engineering one.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

I Stayed in the Sprint Too Long. Here Is the Fix.

Jono Herrington — Thu, 14 May 2026 14:13:20 +0000

Early in leadership, I treated being in the biggest project like proof I was still credible. I wanted the craft. I wanted the team to trust I was not a tourist. Then a senior director of product said something that sounded flattering and was actually a diagnosis ... when I was involved, projects went well. When I was not, they did not.

I took it as a compliment at first. That was ego dressed up as humility.

The real read was simpler. I had become load-bearing in a way that felt like leadership and functioned like risk. If my presence was the difference between success and drift, I had not built enough leverage through other people. I had built dependency with a nicer label on it.

Call it whatever you want in a blog tag, the shape is the same. Decisions run through you. The wins cluster on the work you touch. You read that as proof you add value. It is actually proof the system is fragile, and you are the single point of failure wearing a title.

So I did the harder work. I got out of the sprint as the default owner. I appointed real leads per squad. I operated through them instead of around them. That correction mattered. It also did not mean I stopped being a practitioner.

Writing code was never the hard part for me. Leaving space for other people to carry the hard part ... that was the hard part. I said the rest from the floorboards, not the slide deck.

I keep arguing this in public, and I am not going to soften it for people who want the hard part left off the page.

Leaders should keep a pulse on the craft. Not because every director should ship production code every week like a staff engineer, but because scale without taste turns into mandates you cannot defend. You end up approving work you do not understand. Teams smell that faster than any skip-level survey will ever print out.

The opposite failure mode is what I lived. I stayed so deep in the critical path that I became the safety blanket and the ceiling at the same time. Your engineers feel supported in the moment and underdeveloped across quarters. You feel useful in the moment and exhausted across quarters. That is not Radical Candor cosplay. That is a systems mistake.

Kim Scott helped me because Radical Candor names a trap I actually lived ... being so invested in the relationship that I postponed the hard challenge because I did not want the room to get sharp. It felt kind at the time. It also let problems stay fuzzy longer than they should have. The growth I needed was not switching into jerk mode. It was learning to say the uncomfortable thing precisely enough that someone could act on it the same day ... which turns out to be a different muscle than being good in a crisis thread.

If your involvement is the difference between order and chaos, you are not leading yet. You are still carrying the org on your back.

Where hands-on helps, and where it turns into substitution

I still want leaders touching the real work, with boundaries that protect multiplication.

Hands-on helps when you are going first into something genuinely new ... new tech, new failure modes, new constraints ... and someone has to map the landmines before you ask the team to march. It helps when you are calibrating, not substituting ... checking that estimates, designs, and tradeoffs match reality instead of rewriting other adults' work for sport. It helps when you are modeling standards in review, architecture, and operational discipline so "good" is not a vibe floating in the air.

Hands-on stops helping when it becomes substitution. You turn into the default solver because it is faster today and more expensive every week after. Substitution feels like leadership because it reduces immediate pain. It also teaches the team that escalation is the plan, and that plan collapses fast when more than one lane needs you at once and the clock is not negotiable. You stop looking like a leader and start looking like a router, and your calendar becomes the real system diagram.

That was my loudest mistake for a long time. It is not the only mistake.

When I have drifted too far out

I have also screwed this up the other way. Not as a dramatic resignation story. More like silent drift ... the slow kind where your calendar fills with "important" meetings and your Git history goes quiet and you start nodding along in technical conversations where you used to ask uncomfortable questions.

I track a few signals now because I do not trust my own feelings to warn me early enough. When my 1:1s become status rituals and never reach growth, I am drifting. When I go too long without being surprised by something in the codebase, I am drifting. When I catch myself approving architecture because the room sounds confident instead of because the tradeoffs land in my gut, I am drifting. None of that means I need to become the lead engineer again. It means I am too far out ... and my judgment is about to start running on memory instead of reality.

Guardrails I use on both sides

These are not universal laws. They are what I needed after I paid tuition on both sides of the line ... staying in the sprint too long, and floating above it long enough to lose smell.

When I am too far in, the guardrail is about ownership, not heroics. If I am in execution mode for more than a sprint-shaped window, something is wrong with staffing, ownership, or my own inability to let go. Status and sequencing should not require me in the room. If it does, I fix the lead channel, not the tickets myself. If the team cannot name who owns a domain without me, I have not finished the leadership job.

When I am too far out, the guardrail is about contact, not takeover. I do not sprint myself back into the critical path to prove a point. I do force bounded re-entry ... read pull requests, sit with a lead through one real tradeoff, ask one uncomfortable question in a review I would have skipped. That habit is not nostalgia. It is how I plug judgment back into reality while I am still accountable for outcomes I cannot personally ship.

Those rules sound small. They are the difference between building leaders and building fans.

The payoff nobody warns you about

When I stopped being the human router, projects did not get worse. They got more honest.

Breakage showed up earlier because it was not hidden behind my personal heroics. People grew faster because decisions had to land in the team, not in my head. Politics went down because the shortest path stopped being "get Jono in the thread."

The career side of this shows up when you stop being the person everything routes through. Decisions used to run through me in a way that felt like value and functioned like dependency I had to untrain.

When you build a career map like a contract instead of a pep talk, leveling stops being a surprise. When you ignore how brittle the roadmap is when one person steps away, titles do not save you. And when your strongest IC is quietly carrying the whole failure budget, staying embedded in every thread is how you reward extraction without meaning to.

What I tell managers who are scared to let go

The fear is real. If I step back, quality drops. If I step back, timelines slip. If I step back, people will discover I was never as essential as I told myself. I have heard every version of that fear, mostly from good people.

Here is what I answer now, without pretending fear is irrational.

If quality drops when you step back, you have learned something true about ownership and standards. That is information you can fix with coaching, clearer definitions of done, and review culture that teaches instead of performs. What you cannot fix is a team that only knows how to win with your hands on the keyboard. That is not a team. That is a temporary staffing hack with health insurance.

Timelines slip for two different reasons. Sometimes the schedule was fantasy and your involvement was the compression algorithm hiding reality. Sometimes the team is genuinely learning a new muscle and short-term slip buys long-term capacity. Your job is to know which movie you are in, and not to confuse the two because panic feels like leadership.

And if people discover you were never as essential as you thought ... good. That is called building an organization. Your job was never to be the hero. Your job was to be the multiplier.

The uncomfortable mirror

If you are a director or VP who has not shipped anything meaningful in a quarter but still calls yourself technical because you used to, this paragraph is for you.

Technical is not a tattoo. It is a practice. You do not have to commit every week. You do have to commit often enough that your judgment stays connected to reality, not to memory.

Leadership is not being the strongest engineer in the room. It is building a room where the system survives without you playing every instrument.

What I would do differently if I could mail a letter backward

I would tell younger me that the compliment about involvement was not free. It had a price tag attached in other people's growth and in my own sustainability.

I would still choose the craft. I would just choose it with boundaries earlier, because boundaries are how you love the work without accidentally teaching your team that heroics are the strategy.

If you are in the middle of this now, start smaller than a manifesto. One squad. One real lead. One week where you refuse to be the first resolver. See what breaks. Fix that. Repeat.

The through line is the same ... replacing yourself is not a one-time humility line. It is how the org scales without turning you into the bottleneck that feels good until it does not.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Runbook Is Written. Nobody Runs It.

Jono Herrington — Wed, 13 May 2026 19:48:45 +0000

The runbook was pinned. Owners in the footer. Audit passed. Then a routine change hits, the on-call opens the page, step four does not match what production actually is, and the sane move is to close the tab and do what the last hero did ... because nobody has treated "bring the doc back to truth" as release-critical work. That is not a missing wiki problem. That is a trust problem wearing a Confluence costume. The link is green. The organization is lying to itself in polite font.

The obvious failure is nobody writes it down after the firefight. Embarrassing. Loud. You can fix it with shame.

The dangerous failure is somebody did write it down, the template looks healthy, leadership pastes a URL like they just saved the company ... and the team learns the real rule anyway. The real rule is the DM thread. The real rule is whoever was on call last time. The real rule is whatever gets the release out before the executive thread wakes up again. Paper compliance feels adult. It is still a lie, and you have sat in a review where everyone nods while knowing it.

I used to think reliability was mostly capture. Turns out capture is the easy half. The hard half is enforcement when nobody is clapping.

Midnight in the incident channel ... everyone is a saint. Tuesday at 2 PM is where your religion gets tested. The sprint is tight. A PM is asking for a small exception. The runbook update is fifteen minutes nobody thinks they have. Nobody is confused about what gets rewarded in that moment. Skip the doc. Ship the thing. Be the hero who unblocks.

The incident thread gets executive attention. The runbook ticket floats. Everyone agrees it matters in principle. Nobody loses their job when it slips in practice. So the system does what systems always do when behavior is not backed by consequence. It stores risk in humans again. Then one person goes on PTO and the whole room learns what "distributed" never meant.

A runbook nobody runs is a liability dressed up as maturity.

Half a bridge

Documentation answers a shallow question ... can we describe how this works? A behavior contract answers the harder one ... will we behave the same way next week when nobody is watching?

If your reliability strategy stops at documentation, you built half a bridge. The other half is what leadership treats as non-negotiable during normal work, not only during incident theater. That is why I care whether decision records ever leave the doc and why I separate real debt from strong opinions dressed up as risk. Words that do not change behavior are expensive storytelling. Words linked to gates, owners, and verification change behavior.

Behavior contracts show up in boring places. A release checklist that cannot be marked done without a link to the updated runbook section. A named owner who verifies steps in staging (not only in a postmortem doc). A leadership review that asks for the diff in the runbook the same way it asks for the diff in code. If those are missing, your runbook is not operational memory. It is a comfort object you hug when auditors show up. I say that with love. I have hugged a few.

Same tax, slower burn

If you want the human shape of this pattern, it is the same Brent-shaped week where one person on PTO can stall three lanes before lunch. Heroics hide missing operational memory. Runbooks nobody runs are the slower version of the same tax. You do not feel it until the strong engineer is out and the org discovers it has been mistaking access to a URL for distributed capability.

Here is the social dynamic that quietly murders you. The firefight earns status because it is visible and it is fast and it makes everybody feel like something important happened. Prevention earns patience, and patience is always the first thing that gets cut when the roadmap shows up with a quarter-shaped deadline.

So you get this weird split. The outage gets the war room energy. The runbook follow-up gets a ticket that sits there while people "get back to real work." Leadership can praise mitigation in a standup because mitigation is a clean story. Recurrence work is messier, so it never wins a real slot on anyone's schedule, and after a while the org starts saying "we learned a lot" like that phrase is magic. If nothing in the system changed, you did not learn. You narrated. And the next release is not obligated to applaud your narrative.

The confession I owe

Earlier in my career, I fed this beast without meaning to.

Incident response felt like leadership because it felt alive. I showed up in channels. I asked good questions. I also rewarded velocity in planning forums in ways that made the acceptable answer obvious. The team optimized for what I treated as urgent. Prevention work is rarely urgent until it is catastrophic, so it kept getting deferred, and deferred work always looks rational until the bill arrives.

The ugly truth is I confused presence with leadership. I confused motion with maturity.

The fix is not guilt. The fix is changing what gets treated as incomplete.

What actually moved the needle

The shift that moved behavior for us was embarrassingly small on paper and expensive in discipline. We stopped treating incident closure as a single state. Mitigated meant customer impact was controlled. Closed meant prevention was verified and shipped. Most teams collapse those into one checkbox, and that is where follow-through dies. The ticket closes when the pager quiets down, the harder prevention work becomes a "later" task, and later rarely survives the next priority wave.

Splitting those states forced the conversation nobody wants in the moment and everybody wants in retrospect. No one could claim completion without prevention evidence. Release leads could see open risk in plain language. Leadership reviews stopped rewarding fast mitigation alone.

If you want every step on the habit side, start with mitigated versus actually closed. Reliability is not a documentation problem. It is a courage problem about what you enforce when the room is tired ... and who gets embarrassed when you say "we are not done."

Twenty minutes before you ship

If you want something practical that does not require a new platform, run a twenty-minute reliability follow-through review before release. Ask what failed last time in a way that could repeat, what changed in the runbook and in ownership, which action is still open, and whether this release should be gated until that is done.

If you never ask the gating question, you are doing ceremony. If you ask it and never hold the line, you are doing theater. Theater is expensive. It buys calm meetings and expensive weekends.

Speed without recurrence control is fake speed. You are borrowing from future stability, and the interest rate is ugly.

If you only visit reliability in a deck

If you are a director or VP who has not personally verified that your teams run their operational docs under normal load, not only during audits, you do not get to claim "we are mature about reliability." Maturity is what happens when the boring step survives contact with a busy Tuesday.

This is the same posture as staying close enough to the system that your judgment is not theoretical. I still read pull requests to understand how teams think across regions. I still care what happens after incidents because that is where culture becomes real. If your only relationship to reliability is a dashboard and a quarterly review, you are not managing reliability. You are managing narrative. Narrative does not reboot production.

If the same failure can happen twice, treat the second time like a leadership signal, not bad luck dressed up as engineering mystery.

What I measure when I do not trust vibes

Pick thirty days and track three numbers without drama. Repeat incidents by service area, percent of incidents with runbook updates completed before the next release, and percent of follow-through actions closed by due date. If repeat rate is flat and closure rate is low, your incident program is still response-heavy. If repeat rate drops while closure rate rises, your leadership habits are improving, and reliability is finally compounding. Numbers do not replace judgment. They stop leadership from lying to itself with heroic language.

Fix the foundation before you polish the toy

If your team is debating another model wrapper while the foundation squeaks, fix the system before you polish the prompt. AI will happily help you ship more change into a brittle operational surface. It will not volunteer to be the adult in the room when your runbook is ornamental. The problems have not changed, only the marketing around them ... and "more intelligence" does not substitute for "we agreed how we behave when nobody is watching."

When the humans align first

My team learned a version of this the hard way during the AI tooling wave, before we deserved to talk about agents like adults. We rolled tooling out, pull requests got bigger, review time did not magically grow to match, and the codebase started collecting inconsistent patterns like a junk drawer with a CI/CD pipeline. That is not a metaphor I use for cuteness. It is what it feels like when output accelerates faster than shared taste.

The fix was not a lecture. It was boring alignment work ... patterns, logging expectations, error handling defaults, architecture notes in markdown, the kind of stuff nobody wants to present at a town hall. Once humans agreed what "good" meant in our repo, the tools had something to amplify besides chaos. Guardrails stopped being a vibe and became something you could actually review. If you skip that step, your runbook is not the only ornamental artifact in the building. Your whole engineering culture is.

This week

Link the runbook to the release gate, or stop pretending it is operational memory. Borrow the habit that mattered when we split mitigated from actually closed. If critical context still lives in one person's head, your runbook is probably theater no matter how pretty the wiki is.

You do not need more templates. You need fewer stories you tell yourself while the next on-call discovers the sanctioned path and the real path are not the same thing.

So pick the fight you have been avoiding. The boring one. The one that does not look good on LinkedIn. That is the one that keeps you out of the ditch.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Diagnosis Didn't Change My Leadership. Ownership Did.

Jono Herrington — Sun, 10 May 2026 13:23:03 +0000

I left a role in part because one cross-functional relationship kept overstimulating me and I did not have a framework to understand my own reaction pattern. My ADHD diagnosis did not magically fix leadership, but it gave me language for what was happening and a path to own it before it kept damaging relationships.

Before diagnosis, I would get intensely irritated in certain cross-functional dynamics, not with my direct team as much as in partner relationships where interaction style and pacing repeatedly overloaded me.

I remember one relationship clearly. She moved from one topic to the next to the next to the next like Red Bull was her default operating system. I am not saying she was wrong. I am saying my nervous system was getting lit up every time we interacted, and that overstimulation created friction I did not manage well. Eventually it contributed to me leaving that role. That part is uncomfortable to admit, but it is true.

It matters because leadership stories usually hide this part. We talk about frameworks after we figure things out. We skip the cost of not understanding ourselves early enough.

Then comes the lie everyone repeats ... "The grass is greener on the other side." No ... the grass is not greener. There is just more sh*t.

I changed roles and found new versions of the same trigger pattern. Different person. Different team. Same internal reaction. That was the turning point. The question stopped being "why are they like this?" and became "how do I lead well when this is how I react?" That shift matters more than any title change.

Leadership got better the moment I stopped outsourcing my reaction to other people's personalities.

Diagnosis as a Framework You Still Own

Diagnosis gave me a framework for response patterns.

what overstimulation feels like in real time
what kind of interactions spike reactivity
where I lose signal and start operating from friction

Framework is useful. Excuse is useless. Owning it meant designing operating habits that protect relational quality under pressure, not because I wanted to be "nicer," but because cross-functional leadership breaks fast when your reactions run the meeting. I needed to stop treating overload as a personality conflict and start treating it as an operating condition I had to manage.

What Changed in Practice

I started treating self-regulation like any other leadership system ... pre-work before high-friction conversations, clear agenda boundaries, decision framing in writing, breathing room between context-heavy meetings, and intentional pauses before replying when I felt escalation energy rise. Nothing glamorous. Very effective.

The core move was simple. Separate stimulus from response. When I could feel overload, I stopped trying to win the moment and started trying to preserve the relationship plus the outcome. That single shift reduced avoidable cross-team conflict more than any communication framework deck I have ever seen.

One practical example ... I stopped trying to resolve high-friction ambiguity live in fast back-and-forth meetings. I moved key decisions into clearer written framing first, then used meetings to resolve deltas. That reduced context switching and lowered reactive conflict loops.

Another one ... when I could feel overload rising, I stopped arguing content and started clarifying sequence.

Turns out "winning the point" and "leading the room" are not the same sport.

what decision are we making right now
what belongs later
who owns the next step

That small sequencing habit preserved more relationships than trying to "win" in the moment ever did.

Why This Is a Team Topic, Not a Personal Diary

If this only changed my mood, it would be personal wellness. It changed how I lead across multiple teams and personalities, and that is operational.

Leadership at scale is not just strategy quality. It is nervous-system quality under stress. If your reactions are unmanaged, your team eventually pays for it in slower decisions, avoidant communication, and trust erosion. When leaders regulate well, teams handle ambiguity better because the emotional temperature stays workable even when constraints are ugly. The inverse is also true. When leaders are dysregulated, ambiguity feels personal, collaboration gets sharp, and people start optimizing for self-protection instead of joint problem-solving.

Cognitive Variance Is an Advantage When Designed For

There is a second-order effect here. Once you stop pretending everyone processes information the same way, team design gets better for everyone.

clearer written context
cleaner meeting handoffs
better decision logs
fewer assumptions hidden in verbal backchannels

People without ADHD benefit from those systems too. Inclusive design is not charity. It is better engineering management.

This is why I treat cognitive variance like any other design constraint ... not a side conversation, not a soft topic, and definitely not something you solve by hoping people "communicate better."

The Operating Boundaries That Helped Most

The biggest improvements came from boundaries that looked small.

fewer context-switch meetings stacked back-to-back
explicit decision owners in cross-functional threads
written pre-reads for high-stakes discussions
explicit "not now" parking lot for tangents

Those boundaries reduced overstimulation load for me and reduced confusion load for everyone else. That is the hidden upside. What started as self-regulation work became team clarity infrastructure. Once those patterns were in place, they made it easier for other people with different cognitive profiles to do better work too.

Triggers still show up. Leadership is what you do in the room after they do.

The Leadership Protocol I Use Now

When I feel overstimulation rising in a cross-functional thread, I run a short protocol.

Name the decision we are actually making.
Split urgent from important.
Move the rest into written follow-up.
Confirm ownership before exiting the conversation.

That protocol sounds almost too simple, and that is why it works. It protects signal when your brain wants speed. It protects relationships when your body wants escape. It protects execution when the room wants noise.

What Ownership Looks Like on a Bad Day

The real test of this work is not when I am regulated and rested.

The real test is a bad day ... poor sleep, stacked meetings, and a thread that starts moving too fast.

On those days, old patterns still try to run:

interrupt to regain control
escalate tone to force clarity
rush to closure just to end the overload

Ownership means noticing those instincts early and choosing a better move before they become team damage.

For me, that usually looks like saying one sentence out loud ... "I am losing signal. Let me slow this down so we make the right call." That line has saved more relationships than any clever framing. It does not make me weaker as a leader. It makes the room safer for honest decision-making.

It also gives other people permission to do the same. Once one leader models regulation out loud, teams stop pretending cognitive strain does not exist. Meetings get better because people can name overload without collapsing into drama.

Funny how fast a meeting improves when everyone stops role-playing as a perfectly calm robot.

That is the part I did not understand early enough. Self-regulation is not only personal discipline. It is cultural design. People mirror what leadership normalizes:

if you normalize reactivity, teams normalize defensiveness
if you normalize pause and clarity, teams normalize better judgment

No one gets this perfect. I still miss it sometimes. The difference now is recovery speed. I can name it faster, repair faster, and reduce collateral damage faster. That is what ownership gives you. Not perfection. Better reliability in how you show up when conditions are not ideal.

One final piece that helped was making repair explicit when I missed. A quick follow-up ... "I was reactive in that conversation, and I want to reset how we finish this decision." That sentence used to feel risky. In practice, it increased trust. People do not need leaders who never misfire. They need leaders who can own impact without defensiveness and get the room back on track fast.

If you want one hard indicator that this is working, watch cycle time on cross-functional decisions. When reactivity drops, decision loops shorten because people stop bracing for emotional whiplash and start collaborating on the actual trade-offs.

You feel this in meetings immediately ... less posturing, faster clarity, and fewer unresolved threads leaking into the next week.

This Week

Run one self-regulation retrofit in your leadership workflow.

Identify one interaction pattern that repeatedly derails your signal.
Add one structural guardrail before that interaction.
Debrief afterward in writing ... what triggered, what worked, what to keep.

Do it for 2 weeks and watch how much friction was never about "difficult people" in the first place.

If you lead multiple teams, this becomes even more critical. You are crossing personalities, work styles, and pressure profiles every day. People mirror your emotional operating system faster than they mirror your strategy decks. If your default pattern is reactivity under overload, teams learn reactivity. If your default pattern is pause-clarify-decide, teams learn stability.

If this lands, read Your Team Doesn't Need a Buddy. It Needs a Coach. for the coaching side of relational leadership under pressure.

You do not become a better leader by finding cleaner environments. You become a better leader by building better responses inside the real ones. That is the work, and it is daily work, not a one-time insight. And yes, some days I still miss it. Owning it does not mean perfect regulation. It means faster recovery and less collateral damage when you miss. That difference is everything in leadership. Teams do not need flawless leaders. They need leaders who can notice patterns, own impact, and adjust behavior fast enough to keep trust intact.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Team Doesn't Need a Buddy. It Needs a Coach.

Jono Herrington — Sat, 09 May 2026 13:22:14 +0000

I have sat in too many 1:1s where everyone felt better walking out and nothing changed two weeks later. No clear gap named. No behavior contract. No follow-through. That is why I believe most managers fail people in one of two ways. They run 1:1s like status meetings, or they run them like friendship maintenance.

Both feel safer than coaching, and neither grows people. I am a huge believer in Radical Candor by Kim Scott. It is one of the foundational books in my leadership toolkit because it names something most leaders quietly avoid ... people prefer clarity, even hard clarity, over relational fog. Not cruelty. Clarity. There is a difference.

I have gotten this wrong before too. I have leaned too relational in moments where direct coaching was needed, and all I really did was postpone growth conversations that would have helped sooner.

When managers avoid mentoring, 1:1s become project check-ins. Tickets, blockers, updates, next steps. Useful operationally. Empty developmentally. When managers avoid confrontation, they become buddies. High empathy, low challenge. Good vibes, slow growth. Both are forms of comfort for the manager, not growth for the person.

You can feel this pattern fast. The manager feels supportive. The engineer feels encouraged. Then two sprints pass and the same behaviors are still there because nothing concrete got challenged or contracted.

A 1:1 that never creates productive tension is usually a status ritual with a human face.

Coaching Is a Performance System

Championship teams do not happen because players are talented. They happen because talent is paired with coaching that raises standards consistently. People remember Brady and Belichick, Jordan and Jackson, Jeter and Torre for a reason. Strong players need strong coaching pressure, or talent gets misallocated into whatever feels easiest that week.

Engineering teams are no different. If your highest performers are never challenged, they plateau. If your struggling performers are never confronted, they linger. If everyone gets the same soft feedback language, nobody knows where they actually stand. When people do not know where they stand, they start guessing what leadership wants. Guessing creates politics. Clarity creates growth.

The Manager vs Leader Split

Managers often optimize for role stability. Leaders optimize for person growth. That sounds small. It changes everything.

When you develop people only for current role convenience, you create a short-term staffing win and a long-term attrition plan. People feel it fast. They may stay physically for a while, but mentally they exit early. When you develop people toward who they want to become, you may lose some to bigger opportunities. You also build a reputation where stronger people want to work with you because they know growth is real, not performative. The irony is this usually improves retention, not hurts it. People do not leave only because work is hard. They leave when growth is fake.

This is where manager-vs-leader stops being philosophy and becomes retention math. If strong people keep saying some version of "I am not growing," start with coaching quality before you blame compensation or market conditions.

And this is where many teams get stuck. They think mentorship quality is a "soft" variable while attrition is a "hard" metric. In practice, they are directly connected. Poor coaching quality delays growth, delayed growth weakens trust, weak trust accelerates exits.

A Better 1:1 Structure

If you want to stop buddy-mode and status-mode, run 1:1s with 3 sections.

Reality. Where are you truly strong right now, and where are you not?
Stretch. What behavior at the next level are you not yet demonstrating consistently?
Contract. What is one concrete action you own before next 1:1, and what support do I owe you?

That structure keeps empathy and standards in the same room. You are not choosing between being kind and being direct. You are choosing whether to be useful.

Everyone loves "supportive leadership" until supportive leadership starts asking for evidence.

Use feedback language people can execute.

Weak ... "You need to be more strategic."

Better ... "At next level, you need to delegate this class of work and spend that time framing trade-offs for the team. This week, delegate one workstream with clear ownership boundaries."

Weak ... "You're doing great, keep going."

Better ... "You execute well, but your risk callouts are late. By next check-in, I want one proactive risk flag before it escalates."

Specific feedback is actionable. Vague encouragement is emotional sugar.

The Confrontation Most Managers Avoid

Many managers say they do not want to be "the a*sshole." Fair. But there is another failure mode nobody likes to name ... being so relational that people cannot tell if you believe in their growth enough to challenge them.

Silence is not kindness when the person is drifting. Vague praise is not support when the person needs direction. Delayed feedback is not empathy when the consequences get bigger every sprint. You do not need to be harsh. You do need to be honest.

The practical bar is simple.

state the gap clearly
tie the gap to their own goal
define the next behavior
commit support and follow-up

That is coaching. Anything else is often avoidance with nicer wording.

One practical way to reduce confrontation avoidance is to separate intention from behavior in your language.

"I know your intent is strong."
"The behavior I need to see at next level is X."
"Here is the first place we will test it."

That keeps the person respected while keeping the standard non-negotiable.

If your feedback style protects your comfort more than their growth, you are managing your own anxiety first ... and calling it mentorship second.

A Simple Coaching Scorecard

If you want this to be operational, track 1:1 quality with three weekly checks.

Was one growth gap named clearly?
Was one next-level behavior contracted?
Was follow-up evidence reviewed?

If two or more are "no," it was a check-in, not coaching. This scorecard is intentionally simple so it actually gets used. Either you named a gap, contracted a behavior, and followed up, or you did not. If you cannot answer those three with evidence, your team is not being coached ... it is being managed for updates.

The Hard Part Is Not Giving Feedback ... It Is Holding the Line

Most managers can have one hard conversation.

Fewer managers can hold the same standard for six weeks when deadlines get loud, people get emotional, and every excuse starts sounding reasonable.

That is where coaching systems usually break.

You name a behavior gap on Monday. By the following sprint, pressure rises, roadmaps wobble, and everyone silently agrees to deprioritize development language because delivery feels more urgent. Then you wonder why the same growth gap is still there at quarter close.

The gap is not awareness. The gap is consistency under stress.

One framing that helped me was this ... every unchallenged repeated behavior is a standard you just approved. You may not have intended to approve it. Your team still reads your silence as approval.

That is why follow-up is not administrative overhead. Follow-up is the core leadership act:

"We agreed this would change. What changed?"
"Where did it break under pressure?"
"What support is still missing from me?"

Those questions keep dignity in the room while keeping the bar in the room.

And yes, sometimes the answer is that your expectation was unrealistic for the current context. Great. Adjust it in public. Real coaching is not rigidity. It is honest calibration. But do not call it calibration when what actually happened was avoidance.

If you want to know whether you are drifting into buddy mode, watch what happens after discomfort. Coaches stay present after discomfort. Buddies relieve discomfort and move on. That one difference determines whether your people feel briefly encouraged or permanently developed.

If you want one practical stress test, run this at the end of each week with your direct reports ... "Which feedback from me changed how you worked this week?" If they cannot answer, you are likely giving advice that sounds supportive but is not landing as behavior change. That does not make you a bad manager. It means your coaching loop needs one more turn. Better question, tighter contract, clearer follow-up. Small changes there compound hard over a quarter.

Coaching quality is not measured by how clear you felt while giving feedback. It is measured by whether behavior changed when the week got hard.

This Week

Pick one 1:1 and run one coaching moment you have been postponing.

state the gap clearly
define the next-level behavior
agree on one measurable action by next check-in

Then follow up. No follow-up equals performative candor.

Said differently ... if every hard conversation dies in your notes app, you are not coaching. You are journaling.

If you want one forcing function, end the 1:1 with this question ... "What will be true in two weeks if this conversation actually worked?" Write the answer down and review it together next time. That one move will tell you whether your 1:1s are changing behavior or just reducing tension for an hour. If the same gap appears three 1:1s in a row with no new action, stop calling it development. It is now avoidance debt, and leadership owns it.

If this resonates, pair it with Most 1:1s Are Career Drift Meetings for the growth-roadmap side of the same system.

Your team does not need another manager who is easy to work for. They need a leader who is clear enough to grow under. At work, real care often looks less like comfort and more like a standard you can actually hit.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Repeat Incidents Are a Leadership Smell

Jono Herrington — Fri, 08 May 2026 13:54:02 +0000

We shipped a release, something broke, customer service called, and we fixed it ... then the same issue hit the next release and we applied the same fix again. That is the moment this became clear for me. Pager rotation answers who gets alerted, and reliability answers why this happened again.

A release went out, something broke, customer service called, and the team responded. We fixed it. Good response, bad reliability. The same issue happened on the next release with the same customer-service escalation, and we applied the same fix again. Paging did what it was supposed to do. Follow-through did not. The missing step was simple and expensive. We did not update the runbook with the failure mode and the fix after the first incident. That omission looks small when everyone is tired and the incident is closed. It looks huge when customer service calls again with the exact same failure.

When people say "reliability," most teams jump straight to mechanics.

who is on call
escalation trees
alert routing
shift coverage

All of that matters. None of that prevents recurrence by itself.

You can have perfect pager coverage and still rerun the same incident loop every release if leadership habits are weak.

A pager distributes pain. Leadership habits remove repeated pain.

The Habit Gap

The gap between response and reliability usually lives in four places.

Runbook discipline. Fixes do not become operational memory.
Decision traceability. Context stays in people, not artifacts.
Ownership clarity. Everyone responds, nobody owns prevention.
Follow-through cadence. Post-incident actions are discussed, not shipped.

In our case, runbook discipline and follow-through were the miss. We responded fast, but we failed to convert a solved incident into system behavior. So the system did what systems do when nothing changes. It repeated, and repetition is what separates random failure from leadership failure.

Why Teams Keep Repeating Incidents

Because response feels productive and follow-through feels like overhead. In the moment, fixing production is urgent. Updating documentation, assigning preventative ownership, and verifying change before the next release feels secondary. Secondary work is exactly where reliability is built.

This is why teams often brag about incident response quality while quietly carrying recurrence debt.

Fast response can coexist with high repeat rate, and that should scare you more than a slow response once. A single slow response can be bad luck. A repeated incident is a system telling you exactly where your leadership discipline is weak.

The hard part is that repeat incidents often look different at surface level. Different trigger, different file, different person on call. Leaders convince themselves it is "new." Underneath, the behavioral miss is usually identical ... knowledge did not move into system memory, so the team keeps paying rediscovery tax.

The Leadership Job Between Releases

If you want fewer repeat incidents, leadership has to install non-negotiable habits between releases.

every material incident updates the runbook before close-out
every fix includes "how we prevent this exact class again"
every action has an owner and due date
every next release checks whether those actions were completed

No owner means no action. No due date means no urgency. No pre-release check means the same bug gets a second chance.

Teams call this "unlucky timing." The incident log usually calls it "same root cause, different Tuesday."

Many teams think the missing ingredient here is more process. It usually is not. It is enforcement.

You do not need a 17-step incident framework. You need leadership that treats recurrence-prevention actions like release-critical work, not optional cleanup.

That means changing what gets socialized in leadership forums. Most updates include incident happened, customer impact duration, and mitigation complete. Add these two every time ... recurrence-prevention owner, and recurrence-prevention verification date. If those fields are missing, the update is incomplete.

The Reliability Review That Actually Works

Keep it small and brutal. Run a 20-minute reliability follow-through review before each release.

What failed last release?
What did we change in runbook and ownership?
Which action is still open?
Should this release be gated until that is done?

If you never ask Question 4, you are doing ceremony, not reliability. If you ask Question 4 but never hold the line, you are doing theater.

A lot of teams get stuck here because they confuse speed with discipline. "We have to move fast" becomes the reason gates get waived. Then the same incident comes back with higher cost and lower trust.

Speed without recurrence control is fake speed. You are borrowing from future stability.

The Common Lie

The common lie in operations is "we learned a lot." Learning without behavior change is just narrative.

We "learned a lot" after the first incident too. Then the same issue happened next release. That line should be permanently disallowed in leadership meetings unless someone can point to shipped prevention changes.

If "we learned a lot" keeps showing up every week, congratulations ... you built a book club, not a reliability program.

A better standard is simple. Ask "What did we change in the system that makes this failure less likely next release?" No change means no learning, just memory, and memory expires the moment pressure returns.

If you want a leadership red flag, watch for this sentence after incidents ... "Let's make sure we remember this next time." That sentence usually means nobody owns codifying it. Memory is not a control. Ownership is a control.

The Runbook Standard That Prevents Repeat Pain

A runbook should not be a generic troubleshooting wiki. For repeat-failure prevention, every incident update should include all of these.

Failure signature ... how to recognize the issue quickly
Immediate mitigation ... what stabilizes customer impact now
Root cause summary ... what actually failed
Permanent prevention step ... what changes before next release
Owner and due date ... who is accountable for completion

If any one of these is missing, the runbook is incomplete for reliability purposes, and incomplete runbooks create confident responders with inconsistent outcomes.

One more practical standard. Write runbook language so a person who was not in the incident can execute it. If your update requires tribal context from the original responders, it is not ready.

If the same incident happens twice, treat recurrence like a leadership signal ... not bad luck dressed up as engineering mystery.

Pager rotations are necessary, but they are not the strategy. Reliability is the strategy, and runbooks plus follow-through are where that strategy becomes real.

What to Measure for 30 Days

If you want proof that leadership habits are changing reliability, track these 3 numbers for one month:

Repeat incidents by service area
Percent of incidents with runbook updates completed before next release
Percent of follow-through actions closed by due date

Do not overcomplicate this. If repeat rate is flat and closure rate is low, your incident program is still response-heavy. If repeat rate drops while closure rate rises, your leadership habits are improving, and reliability is finally compounding.

The Cost You Do Not See on the Incident Report

Repeat incidents do not just cost engineering hours. They quietly tax every team touching the customer journey. Customer service loses trust because they keep escalating a "new issue" that feels suspiciously familiar. Product pads plans with defensive timeline buffers. Engineering credibility drops because "resolved" starts to sound like "temporarily quiet."

That is why recurrence has to be treated like a leadership signal, not only a technical metric. A repeated incident is proof that your organization can respond under pressure but cannot consistently learn under pressure. Those are two different capabilities.

One practical move that changed this for us was splitting incident closure into two states:

mitigated ... customer impact is controlled
closed ... prevention actions are verified and shipped

Most teams collapse those into one state, and that is where follow-through dies. The ticket gets closed when the pager quiets down. The harder prevention work becomes a "later" task and later rarely survives the next priority wave.

Separating those states forced better behavior fast:

no one could claim completion without prevention evidence
release leads could see open risk in plain language
leadership reviews stopped rewarding fast mitigation alone

If this feels strict, good. Reliability is supposed to be strict around recurrence. Speed is still valuable, but speed without memory is just expensive repetition. Teams do not burn out only from big incidents. They burn out from the demoralizing feeling of solving the same incident twice and calling both wins.

Another forcing function that works is to make recurrence visible at the same level as availability. Most dashboards celebrate uptime and MTTR. Add a recurrence trend by service and review it in the same leadership forum. When recurrence is invisible, leaders can tell themselves the system is healthy because incident volume looks manageable. When recurrence is visible, the conversation shifts from "we handled it fast" to "why are we still paying this tax?" That shift is where reliability behavior starts compounding.

If you only add one line to your weekly ops review, make it this ... "Which recurrence risk did we reduce this week?" You cannot fake that answer for long, and that is exactly why it works.

This Week

Pick your last incident and run this test. Is the runbook updated with failure mode + fix? Is there an owner for recurrence prevention? Is the action complete before next release? If any answer is no, you are still operating in response mode, not reliability mode.

Add one more check before your next release. Is the runbook update linked in the release checklist? If it is not linked, it is probably not done. Then add this gate ... "Has recurrence prevention been verified in staging or pre-release validation?" Documentation without verification is optimism. Optimism alone is weak cover in production.

If this resonates, pair it with Your Team Is One PTO Away from Missing the Quarter for the dependency side of the same operational risk.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

You're Promoting Confidence, Not Leadership

Jono Herrington — Thu, 07 May 2026 14:14:34 +0000

A contractor lead walked into our org with strong language, strong opinions, and all the right lead-shaped signals ... then a basic desktop and mobile navigation effort took about 6 months. That gap is why I say if your system rewards how someone sounds in the room more than what their team can consistently ship, you are buying charisma at a leadership price tag.

I am not talking about someone we were considering promoting. I am talking about someone who came in already positioned as a lead from prior roles, and in our system he should never have been in that seat.

He was vocal, opinionated, and communicative. On the surface, he looked lead-like. Under real delivery pressure, the signal changed. He could not reliably deliver, he could not delegate and deliver through others, and he took everything on himself until he became the bottleneck. Strong talk. Weak follow-through. One basic desktop and mobile navigation effort took roughly 6 months. That was the receipt, and it was not because the problem was unsolvable. Lead-level leverage was missing. When someone in a lead seat cannot break work down, delegate with clarity, and keep momentum through the team, the org pays twice ... once in delay and once in trust.

This is where promotion conversations get uncomfortable. Most leaders agree that communication matters. It does. You cannot lead if nobody understands you. Communication is a multiplier sitting on top of delivery leverage. Strip the leverage out from under it and you get an illusion amplifier. You can make a weak operating system look healthy for a while. Then deadlines slip, teams stall, and trust drops quietly.

In our case, we exited that contractor lead and transitioned to another front-end lead. The replacement was quieter, still communicative, and far more effective where it mattered. He delivered when he said he would deliver, helped the team, earned trust, and showed up when needed. That is lead material, and that contrast is the entire point. Personality style was a red herring. The scoreboard was the story.

A lead is not measured by how convincingly they speak about execution. A lead is measured by whether execution compounds through the team.

The Promotion Mistake Hiding in Plain Sight

Teams often say they value leadership and execution. Their criteria usually reveal what they really reward.

If your signals are mostly presentation-heavy, you will drift toward promotable appearance.

strong meeting energy
polished updates
confident framing
visible ownership language

Those can all be useful, and none of them prove leverage on their own.

A polished status update is still just a polished status update.

Leverage is harder to fake.

work lands when promised
complexity gets delegated, not hoarded
teammates become more effective, not more dependent
delivery quality holds under pressure

If your system does not explicitly score those, you will accidentally reward charisma over compounding. Most organizations think they do not do this until you ask one practical question in calibration ... "Show me the evidence this person delivers through other people under pressure." If the room answers with presentation examples, communication polish, or "strong executive presence," you already have your answer ... you are scoring narrative, not leverage.

What to Evaluate Instead

If you want better lead calibration, evaluate for these 4 behaviors.

Delivery reliability. Do they ship what they commit to at lead scope?
Delegation quality. Can they distribute work without dropping quality or context?
Team multiplication. Are people around them becoming stronger and faster?
Pressure behavior. When things get messy, do they create clarity or chaos?

Notice what is missing from this list ... volume, presence, meeting dominance.

A person can be brilliant in a room and still be a drag on team throughput. A person can be quiet and still run a championship-level operation.

One nuance that matters ... communication remains essential. I am not anti-communication here. A lead who cannot communicate is also a risk. Communication is table stakes, not differentiation. Differentiation at lead level is execution multiplication. Can this person make the team better at delivering together, not just themselves better at talking about delivery? That is the question.

Why This Is an Org Risk Before It Is a Personality Debate

Introverts versus extroverts misses the point. Your promotion system is only as healthy as the signals it trusts. If your signals are noisy, you get noisy leaders, and noisy leaders create unstable systems. Unstable systems produce the exact problems everyone blames on "execution culture," and then companies run another leadership workshop and call it transformation while the bar does not move because the scoreboard did not change.

Once this pattern sets in, it cascades. Strong doers stop trusting upward decisions. Emerging leaders copy performative behaviors because those look rewarded. Promotion debates become political instead of operational. Eventually you get a leadership layer that is great at recapping execution and weak at driving it, and then companies blame "talent market issues" for the culture they just incentivized.

The Calibration Check I Use

If you want a practical filter, use this during promotion conversations.

What meaningful outcome did they own at this level?
What part of that outcome happened through team leverage, not individual heroics?
What evidence shows they improved other people’s execution quality?
What happened when constraints got ugly?

If answers are fuzzy, narrative-heavy, or overly dependent on intent language, wait.

The Interview Trap That Creates This

This promotion pattern usually starts upstream in hiring. Someone interviews well, presents strongly, has good language for strategy, and checks all the boxes in a panel environment built around articulation. Then real work begins, and real work asks different questions.

can they break ambiguous scope into deliverable chunks
can they delegate without dropping context
can they recover when assumptions fail
can they keep team momentum when pressure spikes

If your hiring and promotion systems over-index on narrative skill, you will repeatedly import the same risk into lead roles. Keep communication sacred ... and bolt it to delivery leverage in your criteria so polish cannot travel alone.

What This Costs the Team

When the wrong lead signal wins, the cost is not just one missed project. It spreads into trust, execution quality, and retention.

The Quiet Tax on Real Operators

The most expensive part of bad promotion signals is not visible in a single quarter.

It is the quiet tax you place on your actual operators.

When people who multiply teams keep getting ranked below people who multiply impressions, your strongest builders start making a different calculation. They stop asking "How do I grow here?" and start asking "What does this place actually reward?"

That question changes behavior fast:

some adapt by performing the rewarded theater
some disengage and do only what is required
some leave and take leverage with them

Leadership teams usually experience this as "retention noise" or "market churn." It is often signal design debt.

One practical check that helps surface this early is to review promotions backward from outcomes six months later:

Did this person increase team throughput predictably?
Did they reduce decision latency under pressure?
Did they make other people stronger in measurable ways?
Did delivery quality improve around them?

If two or more answers are unclear, your promotion criteria were probably over-indexed on in-room performance.

If that makes people uncomfortable in calibration, good. Discomfort is cheaper than six more months of narrated under-delivery.

One extra safeguard worth adding is a six-month proof review at promotion time. Ask one blunt question ... "Did this person create stronger decisions and better delivery through others, or did they mostly create better updates about the same delivery?" That distinction keeps your system honest when charisma and certainty are competing with operating leverage.

I like this review because it strips away interview glow and calibration politics. The scoreboard gets a vote. People can still grow into a role, absolutely. But when growth into role becomes a default justification for weak leverage evidence, you are running optimism as policy.

And optimism as policy usually creates one predictable outcome ... the team with the highest standards starts feeling gaslit by the team with the loudest updates.

Another way to protect against this drift is to require one "through-others" proof in every lead promotion packet. Not a personal hero story. A concrete example where they set direction, delegated execution, and improved the outcome through the team. This requirement sounds small, but it instantly separates individual excellence from lead-level leverage. If the packet cannot produce that proof, the timing is wrong even if the person is talented.

When talk gets promoted above leverage, teams do not get led. They get narrated.

This Week

Take your lead-level criteria and run one simple test. For each criterion, ask whether it predicts delivery leverage or presentation quality. If it mostly predicts presentation, rewrite it. Then calibrate one recent lead decision against the rewritten criteria and see what changes.

If you want a sharper test, do this in your next calibration.

remove names
remove personality language
review only delivery leverage evidence

Then compare outcomes with the version where names and presence context are included. If the ranking changes dramatically, your system is more biased toward presentation than performance. You do not need a villain to explain that drift. You need clearer criteria.

If this resonates, read Your Team Is One PTO Away from Missing the Quarter for what low-leverage leadership looks like at system level.

Promotion systems are culture systems. Who you elevate is what you multiply. If you multiply confidence without leverage, you get louder problems, and louder problems always show up as execution problems later.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Most 1:1s Are Career Drift Meetings

Jono Herrington — Wed, 06 May 2026 14:18:51 +0000

He looked me in the eye in a 1:1 and asked, "What do I need to do to get to the next level?" He was hungry, driven, and teachable ... and had no clear road to run on. That is when I was reminded that most 1:1s fail because they pretend to be development conversations while operating like status meetings.

A strong engineer came to me and asked a direct question. "What do I need to do to get to the next level?" He had drive. He was faithful, approachable, and teachable. He was not missing hunger. He was missing a road, and that detail matters more than most managers want to admit. The lazy leadership answer is "stop waiting for a roadmap and build one." It sounds empowering, and it is also nonsense when someone is trying to get to a place they have never seen clearly defined. If you do not know what the destination looks like, you can run hard and still run wrong.

I have watched this happen more than once. High-agency people do exactly what you ask them to do, then get frustrated when "doing everything right" does not translate into growth. They are not usually missing effort. They are missing signal quality.

The pivotal line in that 1:1 was simple. "I have your back, and I will help create the road" ... not "I will carry you," not "you are on your own." Support first, clarity first, then ownership.

We partnered with HR and built a role matrix across engineer, senior engineer, tech lead, and manager. We defined what each level looked like in behavior, scope, and delivery expectations. Then we mapped where he stood, where he needed to grow, and what evidence would count as real progress.

Within a year, he moved into a senior role. Within 2.5 years, he replaced me. That is one of the proudest moments I have had as a leader ... replacing yourself on purpose.

You are not mentoring when you say "figure it out" without defining what "it" looks like.

The Manager Mistake

Most managers do one of two things in 1:1s. They do status updates, or they do emotional reassurance. Neither one builds growth by itself.

Status-only 1:1s train people to report, not to level up. Reassurance-only 1:1s train people to feel seen, but not necessarily challenged. You need both care and clarity. Without clarity, care turns vague. Without care, clarity turns cold.

The reason this gets missed is predictable. Status updates are measurable and immediate. Career development is slower and messier. It is easier to ask, "Any blockers?" than to ask, "What behavior is holding you back from next level right now, and what are we both doing about it?" One question protects the sprint. The other question changes a career.

This is why your 1:1 should function like a career contract.

Here is where you are.
Here is where you want to go.
Here is the definition of that level.
Here is the evidence that will prove growth.
Here is what I own as your leader.
Here is what you own as the engineer.

If any of those are missing, the contract is ambiguous, and ambiguous contracts create frustrated engineers.

And frustrated engineers do what adults do when the system is vague ... they start running experiments in political survival.

Ambiguity also creates politics. When growth criteria are unclear, people optimize for whatever gets attention. They present harder. They perform confidence. They play proximity games. None of that builds the capability you actually need as an organization.

Build the Road, Then Hand Over the Keys

There is a sequence that works.

Define the destination in concrete terms.
Create short-cycle growth checkpoints.
Pair feedback with evidence, not vibe.
Move ownership to the engineer once the map is clear.

That sequence is the difference between mentorship theater and real development. Leaders who skip Step 1 usually blame motivation. It is rarely motivation. It is missing architecture.

You would not ask an engineer to ship a complex system with no requirements and then call them weak when they miss. Yet that is exactly how many leaders run career growth.

If your instinct is "they should just figure it out," ask yourself a harder question ... would you use that same standard for a production migration with real customer impact? If the answer is no, do not use it for someone's growth path either.

The same leadership logic applies.

define the target state
define acceptance criteria
define review cadence
define ownership

Career development is architecture work with human consequences.

Why This Matters More Right Now

In fast teams, especially AI-assisted teams, output can hide growth gaps for longer than it used to. Someone can look productive while stalling in judgment, influence, or leverage. If your 1:1 is only about updates, you will miss that drift until it gets expensive. Career clarity is leadership infrastructure, even when HR paperwork makes it look like a side process.

When people know the road, they can self-correct faster, ask better questions, and build confidence that comes from progress, not posturing.

When people do not know the road, they optimize for visibility because visibility is the only signal left. That is how you accidentally build a culture of performative growth. People learn to narrate progress instead of creating it, managers start rewarding confidence instead of capability, and then everyone wonders why the same succession gaps keep showing up.

This is also why your 1:1 quality predicts retention more than most leaders think. People can tolerate hard problems. They do not tolerate feeling stuck with no credible path forward.

The Leadership Contract Most People Skip

There is one uncomfortable part here that leaders love to avoid. Your side of the contract. Most growth plans fail because they are written as employee commitments with manager encouragement. That reads like cheerleading. It is delegation, not something both sides can inspect.

Your side should be explicit.

what feedback cadence you will hold
what opportunities you will create for stretch work
what sponsorship you will provide in calibration conversations
what standards you will enforce even when delivery pressure gets loud

If you do not write your side down, people stop trusting the process because it looks like another "work on these things and we will see" loop. Trust grows when progress is inspectable for both sides.

What This Looks Like Over 90 Days

If you want this to work, run it in 30-day loops.

Month 1 is definition.

role target is explicit
behavior criteria are explicit
growth evidence is explicit

Month 2 is execution.

one stretch behavior is practiced in real work
feedback is tied to observed behavior, not impression
misses are corrected in-week, not at quarter close

Month 3 is calibration.

what changed
what stalled
what needs support shift
what proves readiness now versus later

This cadence sounds basic, and that is the point. Leadership systems should be boring enough to run consistently and sharp enough to change outcomes. If this feels too formal, good ... informal growth systems are usually where ambiguity and bias hide, and formality is not bureaucracy when it creates fairness and clarity.

The 1:1 Failure Pattern You Can Spot in One Question

If you want to know whether your 1:1 system is real, ask one question at the end of the conversation ... "What changed in your growth plan from this meeting?"

If the answer is vague, your 1:1 was probably morale support plus project updates.

Useful for feelings. Useless for promotions.

If the answer is specific and behavioral, your 1:1 was leadership work.

I started using this question because I got tired of walking out of meetings that felt productive and then watching nothing actually change. We had good conversations. We had trust. We had positive sentiment. We did not have movement. That is a brutal thing to admit as a manager, because it means your intent can be strong while your system is weak.

When this question is built into your cadence, it exposes the exact gap:

no clear behavior target
no evidence criteria
no owner for next check
no timeline for reassessment

And when those are missing, your team usually fills the gap with performance language. You get cleaner updates, better optics, and stronger meeting energy ... but no durable growth.

One practical upgrade that helped me was adding a 3-line closeout doc after each 1:1:

behavior we are targeting
evidence we expect by next check-in
support I owe as leader before then

That tiny artifact made the contract inspectable. People stopped guessing what mattered. If you cannot point to a changed behavior contract after a 1:1, you did not run a growth meeting. You ran a conversation.

This Week

Take one high-drive engineer and run one contract-style 1:1.

Define their next-level target in writing.
Agree on 3 observable behaviors that prove readiness.
Set one 30-day growth commitment on each side.

Then hold yourself accountable to your side first.

A 1:1 is where you either build a growth system or build attrition.

If this post lands, pair it with Your Team Doesn't Need a Buddy. It Needs a Coach. for the feedback side of the same problem.

The people on your team are not waiting for another update meeting. They are waiting for a leader who can define the road and walk it with them until they can run it alone. That is the real 1:1 job. Everything else is admin.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Team Is One PTO Away from Missing the Quarter

Jono Herrington — Tue, 05 May 2026 14:30:51 +0000

Monday morning, one engineer was out on PTO and three separate workstreams were already blocked before lunch. Slack filled with "quick question" pings nobody else could answer, and standup turned into a scavenger hunt for missing context. By Wednesday, it was obvious we did not have a throughput problem ... we had built a system that stored critical knowledge in one person.

Most leadership teams do not call this out when they see it. They call it excellence: "She is our strongest engineer," "He just knows the platform better than everyone else," and "If anything goes sideways, bring them in." I have said every one of those lines in my career, and I have paid for each one later.

What stalled us was not coding skill. It was missing map data ... why certain decisions existed, where hidden dependencies lived, and which changes looked safe but would actually blow up downstream. The team was talented. The system was fragile.

If you have read The Phoenix Project, you already know this pattern as the Brent Effect. One indispensable person gets attached to every critical path, leadership mistakes heroic saves for system health, and everything looks fine until that person is unavailable.

Different decade, same movie, better dashboards.

The thing that matters is this ... the Brent Effect is not a personality problem. It is an operating model choice. You design for local efficiency, then wake up with global fragility.

The dangerous part is how normal it feels while it is forming. Nothing looks broken at first. Tickets still move. Releases still go out. Leadership still sees green dashboards. The only early signal is behavioral ... everyone knows exactly who to tag when risk shows up, and nobody asks why that pattern keeps repeating.

The Metric Most Leaders Skip

Most teams track cycle time, deployment frequency, and incident counts. Good. Track those. But if you are not tracking skill and context distribution, you are missing the risk that can invalidate all three. I use a simple score now for critical domains, not because scores are sexy, but because hand-wavy "we should cross-train more" conversations never survive quarter-end pressure.

The Skill Distribution Score

Pick one critical service or workflow and score it 0 to 2 across five dimensions. The goal is not perfection. The goal is to expose where your roadmap depends on one nervous system.

1) Coverage

How many engineers can safely modify this area without the usual owner?

0 = one person
1 = two people with supervision
2 = three or more people independently

2) Recovery

Can on-call recover core flows without escalating to the same person?

0 = frequent single-person escalation
1 = partial runbook support
2 = rotation can recover consistently

3) Decision Traceability

Can engineers find why decisions were made?

0 = tribal memory
1 = partial PR context, scattered docs
2 = strong PR context + ADRs

4) Onboarding Transfer Speed

Can a new engineer ship meaningful change in 30 days?

0 = blocked by verbal dependency
1 = progress with heavy handholding
2 = can execute from docs and standards

5) Ownership Rotation Health

Has ownership rotated in the last 2 quarters?

0 = one long-term owner
1 = limited shadowing
2 = deliberate rotation with accountability

Total score out of 10.

0 to 3 = immediate structural risk
4 to 6 = hidden fragility with decent optics
7 to 8 = healthy core, risk at the edges
9 to 10 = resilient system behavior

One important note ... score by domain, not by team. Teams can look healthy in aggregate while one payment flow, one integration surface, or one deployment path is still hanging by a thread. The goal is not to get a pretty average. The goal is to find the load-bearing edges before they fail in public.

If your score is low, the fix is not "find another hero." The fix is "stop architecting hero dependency."

Why Teams Avoid This Work

Because it feels slower in the short term. Pulling your fastest engineer into documentation, decision capture, pairing, and ownership transfer can look like a throughput hit on this sprint's board. It is also one of the few moves that protects next quarter's board from fiction.

This is the leadership tax nobody wants to pay when times are good. Then someone leaves, gets sick, burns out, or just takes a real vacation for the first time in a year, and the tax bill arrives with interest.

I used to think we were being efficient by routing everything through our strongest people. What we were actually doing was borrowing stability from one human and calling it process. I called it leverage in leadership meetings. It was dependency with better branding.

How Leaders Accidentally Build Hero Dependency

Nobody sets out to build this on purpose. It happens through reasonable decisions that compound in the wrong direction.

A high-pressure quarter shows up, and your most experienced engineer handles the hardest path because you need certainty. Next sprint, they do it again because they are already warm in the domain. By month three, they are the default owner for anything risky, and by month six the rest of the team has learned a quiet rule ... if it matters, route it to that person first.

Then leadership reinforces it without noticing.

You praise speed over transfer.

You reward clean incident recovery without asking why the same name keeps showing up.

You celebrate "ownership" while tolerating single-threaded knowledge.

You call this accountability. Your system experiences it as concentration risk.

This is why I treat bus-factor risk like infrastructure risk now. Nobody argues about whether production needs redundancy. But teams will still debate whether people context needs redundancy, even though both failures produce the same operational result ... things stop moving when one node disappears.

What This Looks Like in Practice

What this usually looks like in real teams is less dramatic than people expect. You do not find one big failure and fix it with one big project. You find recurring friction patterns that keep pointing to the same dependency shape.

On-call keeps escalating to the same name. New engineers can ship, but only after multiple verbal handoffs. Major decisions can be explained by people, but not by artifacts. The dashboard says delivery is healthy while the team quietly optimizes around one person's availability.

That is why the score matters. It turns "we should probably cross-train" into a concrete diagnosis you can act on.

And the action sequence is simple. Pick the lowest sub-score, make one transfer move this sprint, and rerun the score next month. Do that repeatedly and the system gets less brittle without pretending you can redesign everything in one quarter.

That is what this work looks like when it is real ... less theater, more compounding.

The Monthly Cadence That Keeps It Alive

Most teams fail here by turning this into a one-time cleanup project.

Do not do that.

Run a 30-minute monthly review with your EM and tech lead on one critical domain:

Re-score the 5 dimensions.
Identify the lowest sub-score.
Pick one transfer action for the next sprint.
Assign a clear owner and due date.

That is it.

No giant transformation deck. No offsite. No "cross-functional task force" that dies quietly in 3 weeks. If your resilience plan starts with a steering committee, you built calendar theater, not redundancy.

The score is not useful because it is clever. It is useful because it forces a small leadership behavior most teams avoid ... replacing verbal dependency with system memory on purpose.

The Global Team Reality Check

The moment your team spans time zones, this problem gets louder.

Time zones turn knowledge concentration into a latency multiplier. A blocked engineer in Europe can lose half a day waiting for North America context. A hotfix in North America can miss handoff quality for Asia if the only person who understands the dependency graph is asleep. What looks like "normal async friction" is often hidden bus-factor cost.

This is where your scorecard becomes operational, not theoretical.

If recovery is low, your follow-the-sun model is performative.

If decision traceability is low, your handoffs are storytelling instead of systems.

If onboarding transfer is low, your global hiring strategy is paying for capacity your operating model cannot absorb.

The fix is not more meetings. The fix is better artifacts and clearer ownership transfer points that survive time zones.

What to Change This Sprint

You do not need a reorg to start fixing this. Run these 4 moves on one critical domain this sprint:

Require "why" context in PRs, not just "what changed."
Treat stale runbooks as production risk, not documentation debt.
Rotate one ownership responsibility this sprint, even if it is slower.
Review one high-impact decision and backfill the missing ADR.

If you want to pressure test whether the moves are working, pick one simple check ... when something breaks this month, does your incident channel still default to tagging one name first? If yes, keep going. Your process changed, but your dependency graph did not yet.

Your best engineer should be an accelerator, not a life-support machine.

If this feels familiar, read The Leadership Bench Test. It is the same problem through the leadership lens. This post gives you the measurement model.

The Real Leadership Test

Any team can look strong when the same people are always available. Real system quality shows up when they are not.

If one PTO request can put your roadmap at risk, your org does not need a motivational speech. It needs redesign ... and less wishful thinking in leadership meetings.

You do not scale by finding better heroes. You scale by making heroics unnecessary.

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.

Your Codebase Was Always This Bad

Jono Herrington — Sat, 02 May 2026 13:17:02 +0000

A team turned on agent mode a month ago. First week, ecstatic. Shipping faster than they had in years. Second week, incidents started showing up. Third week, they were ready to blame the tool.

Then their senior pulled up the logs. Found the bug. Traced it back. The function had been broken since 2019. The AI just called it correctly for the first time in years.

The room went quiet.

They had shipped around that broken function for six and a half years. Workarounds in three services. Documented in runbooks. Never fixed because it never broke loud enough to matter. The fragility was always there. They had learned to dance around it so well they stopped seeing it.

The AI didn't create the problem. It walked into a house of cards and accidentally leaned on a wall.

The Pattern Keeps Showing Up

I was on a call last month with a team that's all in on AI. Slack full of celebration emojis. Pull requests flying. Shipping faster than ever. And their most senior engineers were terrified.

Monorepo with submodules. No specs, no Docker, no clean local setup. New developers take weeks to get running. The codebase is an atrocity that everyone had silently agreed to live with.

QA told me the engineers are throwing code over the wall now. Ship fast, fix later. Except later never comes. The defect queue keeps growing. A piece of work originally estimated at two weeks is still open six months later.

They don't blame the AI for breaking things. They blame themselves for what the AI revealed.

The whole org is chanting "ship faster, ship faster, ship faster." Celebrating motion while the foundation erodes. Activity dressed up as progress.

I Was the Genie User

I got this wrong myself when I first started.

I was building an app to bridge design and development. Take a Figma payload, convert it to production-ready code, eliminate the handoff. The promise was huge. Ship faster. Close the gap between design intent and working software.

I fell into vibe coding. I'd ping the model with what I wanted, then wait for magic. No structure. No guardrails. Just me wishing code into existence and the AI trying to comply.

The output looked right at first glance. But the design models were wrong. The code was verbose, layered with assumptions it couldn't have known to question. It wasn't solid. It was code built on foundations I had never explained, doing things I hadn't specified, making choices I hadn't authorized.

I was asking a junior engineer to read my mind and getting annoyed when they couldn't.

The breakthrough came when I stopped treating AI like a completion engine and started treating it like a new team member who needed context. Guardrails. Documentation that explained why the system worked the way it did. Clear boundaries around what the AI could assume and what it couldn't.

Once I did that work, the output changed. Not because the model got better. Because I had stopped wishing.

The Light Got Brighter

Race conditions that existed for years. Null references that always threw but never mattered. Configuration drift that a dozen services had quietly learned to tolerate.

The code didn't get worse when AI showed up. The light got brighter.

The teams winning right now aren't just shipping faster. They're going back and fixing foundations first. Adding specs. Documenting invariants. Creating boundaries the AI can understand and respect. They're doing the work that makes the AI useful instead of asking it to do magic on top of ruins.

AI accelerates whatever direction you're already heading. Solid foundation, you compound. Cracked foundation, you find the cracks sooner.

The codebase was always this bad. The AI just made it visible.

What assumption in your codebase has survived because nobody ever tested it?

One email a week from The Builder's Leader. The frameworks, the blind spots, and the conversations most leaders avoid. Subscribe for free.