Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

If You’re Skimming

• A green velocity dashboard usually measures closure, not durability. It can look healthy while last sprint’s work quietly comes back.

• This is the QBR Mirage: the visible numbers are real, but they get mistaken for the whole landscape.

• The hidden follow-on work is the Rework Shadow. Closure is a status. Completion is a result. A story can be closed and incomplete at the same time.

• Run the Five-Story Field Test at the bottom to see how much of your own “done” did not stay done.

• The point is route repair, not blame. Velocity is a useful local signal. It just needs witnesses.

The QBR Mirage

The meeting looked clean. Talia, the product lead, walked the room through a polished quarterly deck. Velocity was up, stories were closed, the sprint trend was green, and the dashboard had that calming corporate glow that makes everyone exhale at once. Leadership saw the chart and heard the story they wanted to hear: the team is moving, the work is flowing, the plan is safe. Nothing in the room suggested danger, which is usually how the most expensive problems prefer to enter.

In the room with Talia was Dev, the delivery lead, who had read the same green dashboard all quarter and reported it upward as a health signal. Three weeks later, Marcus, the engineering manager, ran a quiet analysis on the last two sprints. A defect had come back from something marked done, followed by a clarification ticket, a cleanup task, a support issue, and a dependency fix that technically belonged to last sprint but showed up in this one. No single item looked dramatic enough to challenge the dashboard. Together, they raised the question the dashboard had never been built to answer: did the work stay done?

Talia, Dev, and Marcus are composites, not a disguised client or one remembered meeting. I use them because the pattern is real even when no single incident should carry the whole argument. The names change, the tools change, the industry changes. The move does not. The numbers look healthy, the room relaxes, and nobody checks whether the work survived.

Here is my confession. I have sat in that QBR. I have felt the room exhale at the green dashboard, nodded along with “keep this momentum,” and then planned the next quarter against numbers I should have questioned. I have stood inside that moment in Azure DevOps, scrolling back through completed work and feeling the floor drop when the follow-on tickets started tracing back to stories the dashboard had already counted. I was not careless. I was doing the thing competent people do under a clean chart: I trusted closure as if it were completion.

The dashboard did not lie. A lie would be too simple and too comforting, because then we could blame the report and move on. The harder truth is that the dashboard told only the part of the truth it was designed to see. It saw closure, counted points, and surfaced activity. What it did not show was whether that closure survived contact with users, dependencies, support, production, and the next sprint.

This is the same failure this series keeps following, one layer deeper. In Episode 1, a warning died in a busy channel because receiving is not routing. In Episode 2, a handoff became a gap because a closed ticket is not a completed handoff. In Episode 3, a gate lived on the diagram but stopped operating in the work. Episode 4 follows the pattern into the dashboard, where closure quietly stands in for completion and the metric reports progress the system has not actually kept.

That hidden follow-on work is the Rework Shadow. The Rework Shadow is not always scandalous or even obvious in the moment. Sometimes it appears as defects, clarifications, cleanup, support tickets, dependency fixes, reopened items, and small pieces of “just one more thing” that return after the original work was counted. No single follow-on ticket proves the system is broken. Patterns prove something. When enough “done” work keeps coming back, the team may be borrowing capacity from the future while reporting progress in the present.

What Does a Green Velocity Dashboard Fail to Show?

A green dashboard shows movement, and movement matters. Teams need to know whether work is flowing, leaders need signals, and product planning cannot run on vibes or the sacred spreadsheet someone updates at midnight. The problem is not that dashboards exist. The problem is that a dashboard can show visible progress while hiding invisible drag.

A velocity dashboard can tell you stories closed, points counted, sprint trend improved, and status green. Those signals are not worthless. They become dangerous only when we treat them as complete. What the dashboard may not tell you is whether the same work came back wearing a different ticket number, landing in a different queue, or quietly consuming a different team’s capacity.

This is the QBR Mirage. From above, the surface looks calm. Velocity is up, stories are closed, and the status is on track. Underneath, work may still be accumulating as defects, cleanup, clarifications, support, and reopened items. The mirage is not that the visible numbers are fake. The mirage is that the visible numbers get mistaken for the whole landscape.

It helps to notice who builds this route, because no one builds it on purpose. The same practical lens from earlier episodes applies here, and it is a lens, not a validated taxonomy. The Designers are the product leads and managers, like Talia, who choose the metrics and build the dashboard, because they need something visible to show progress. The Inspectors are the delivery leads and PMO functions, like Dev, who read that dashboard as a health signal and report it upward. The Enforcers are the finance and leadership stakeholders who turn last quarter’s velocity into next quarter’s commitment.

Each role is doing its job. None is positioned to see the full cost when rework lands in support, operations, or the next sprint, which is the cost Marcus eventually found by hand. Changing any one actor does not fix the script. The route needs a better companion signal.

Why Is Velocity Useful, but Incomplete?

Velocity deserves a more honest defense than its loudest critics usually give it. Used locally, velocity can help a team forecast, support sprint planning, and notice whether its own delivery rhythm is changing. It can prompt useful conversations about capacity, scope, and sequencing. That is the useful part, and serious teams should not throw it away because someone online discovered a hot take and dressed it up as a principle.

The incomplete part begins when velocity leaves the team context and starts pretending to be a productivity score. Story points are relative, and velocity is team-specific. A team’s velocity is shaped by estimation habits, story slicing, domain complexity, dependencies, tooling, interrupt load, and Definition of Done. That makes velocity useful for local planning and risky for cross-team comparison. Treating velocity as a performance target, an individual score, or a cross-team comparison conflicts with the way story points are defined, which is as relative, team-specific estimates, and it invites gaming the number instead of improving the work.

That last risk has a name. Goodhart’s Law does not need a villain. It just needs a useful measure that becomes the target. When a team is rewarded for the velocity number itself, the rational moves are quiet ones: split stories into smaller points, defer the edge-case testing, lean on optimistic definitions of done. The chart climbs while the durable work slips. I am borrowing Goodhart’s Law as a lens here, not offering it as proof that velocity is doomed. It simply describes what happens to any honest signal once we point planning pressure at it.

So the key sentence is simple. Velocity helps a team plan, but velocity cannot, by itself, prove the work stayed done. That is the nuance too many metric debates lose. The argument is not that velocity is bad. The argument is that velocity is incomplete. Velocity needs witnesses. Quality, stability, flow, rework, and the people living inside the system all need to testify, because one metric should not be forced to impersonate the entire truth.

What Is the Difference Between Closure and Completion?

This is the distinction that makes the rest of the article work. Closure is administrative. Completion is operational. Closure means the ticket moved, the card crossed the board, the field changed to done, the points counted, and the report updated. Completion means the work survived real use. The feature held up, the fix did not reopen the problem, the dependency did not create a second wave, support did not inherit confusion, and the next sprint did not quietly pay the bill.

Closure is a status. Completion is a result. A story can be administratively done and operationally unresolved. This sounds simple until a team starts planning against closure while paying for incomplete work somewhere else. When that happens, the organization can sincerely believe it is moving faster while the team experiences the work as slower, heavier, and more tangled than the dashboard implies.

A story can be closed and incomplete at the same time. The moment it moves to done, the system records closure. The open question is whether that closure survives contact with production, customers, downstream teams, support, and the next planning cycle.

That does not mean every follow-on ticket is a failure. Some follow-on work is healthy, and iteration is how good product development actually happens. We should not punish learning or treat every change as evidence that someone messed up. The point is pattern recognition. If the same kinds of follow-on work keep appearing after the same kinds of closed stories, the route is telling us something. Maybe the Definition of Done is too weak, dependencies are discovered too late, stories are sliced around effort instead of user value, QA is under-powered, or product and engineering are closing different versions of “done.”

My hard-won opinion is that the closure-completion gap usually starts with bad slicing, not bad effort. Teams cut work into pieces that are easy to assign, estimate, and close, then ask the Definition of Done to prove value after the story has already been shaped around task completion. By then, the route is already bent.

How Much Capacity Does Rework Quietly Consume?

Rework is politically dangerous because it hides inside normal work. No one schedules a calendar event called “paying for work we already celebrated.” No dashboard adds a cheerful slide titled “capacity we thought we had but already spent.” Instead, rework disguises itself as routine. A defect here, a clarification there, a cleanup ticket too small to argue about, and a dependency fix everyone agrees is “just part of the work” can look manageable in isolation and still consume the capacity leadership counted as available.

Three local cost categories tend to surface when you trace a Rework Shadow backward. Bystander Burn is the coordination time several people spend seeing, monitoring, and half-investigating work that came back. Investigation Tax is the duplicated effort spent reconstructing why something marked done reopened. Compounding Rework is the cleanup that accumulates when today’s fixes are built on a foundation that was never confirmed, so they quietly generate tomorrow’s follow-on work. None of these show up as one giant visible failure. The team experiences them as friction, context switching, and a sprint plan that somehow always runs optimistic.

Share

The evidence here matters, and so do the caveats. Documented examples show that defect correction and maintenance can take a substantial share of software effort and cost. One IEEE Software analysis found defect correction accounting for at least 40% of total project cost in its context. Classic work by Glass summarized maintenance as often consuming 40% to 80% of lifecycle cost, with around 60% cited as a common average in those historical studies. Those figures come from specific contexts and eras. They are best treated as a reason to look, not as a benchmark to import.

The wrong use of those numbers is to march into a QBR and announce that research says 60% of our work is maintenance, therefore we are losing some exact dollar figure. That is not analysis. That is spreadsheet cosplay with a blazer. The right use is more disciplined: this category of work can be large enough to matter, our green dashboard may not capture it, and our local version deserves measurement. The local question is not what the industry average says. The local question is how much of our recently closed work generated follow-on work, and how much capacity that follow-on work consumed.

Here is the trace I wish I had run sooner, kept simple so the shape is visible. A team closes 40 points in a sprint, and I sign off on the number with real confidence. The next sprint, that same team spends 10 points on defects from those stories, 6 on clarifications, and 4 on dependency cleanup. That is 20 of 40 points, half the apparent capacity, quietly going to work I had already counted as done. I have planned the following quarter against the 40 and felt the 20 as nothing more than a vague sense that the team was slower than the chart promised. The exact numbers will be different for your team, and this is an illustration rather than a benchmark. Use points, hours, or team-days, whichever your team already trusts, as long as you keep the unit consistent inside the local sample. The point is that the math becomes local, specific, and hard to ignore the moment someone traces it instead of trusting the total.

Here is the part the evidence cannot teach you: the first time you surface rework in a room that has been reporting green, everyone hears an accusation unless you frame the conversation with extreme care. I have personally discovered, through the glamorous leadership method known as saying it wrong first, that “we are wasting capacity” makes people defend their reputations, while “our planning signal is missing part of the route” gives them a system to inspect. Same evidence. Completely different room.

What Do DORA and SPACE Actually Tell Us About Productivity?

DORA and SPACE help here because they resist the temptation to turn one number into a religion. DORA (DevOps Research and Assessment) reminds us that delivery performance needs balance. Throughput matters, but so does stability, which is why Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore belong in the conversation together, with Reliability as an important added dimension. One point needs to be explicit, because it is easy to get wrong. DORA does not define an official rework metric. Any rework signal in this article is a local planning measure inspired by DORA’s stability focus, not a DORA metric.

SPACE (Satisfaction Performance Activity Communication Efficiency and flow) makes a related point from another angle. Developer productivity is multidimensional, so activity alone cannot carry the full truth. The dimension that matters most for us is the tension between Activity, which is where velocity and story points live, and Efficiency and Flow, where rework and friction show up. Satisfaction belongs in the picture too, because constant firefighting is how good teams burn out while the activity numbers still look fine.

This matters because a tired metrics culture often tries to fix one over-promoted number by inventing another over-promoted number. That is not maturity. That is metric whack-a-mole with better fonts. My read is that teams keep reaching for one over-promoted number because uncertainty is socially expensive. A single metric gives everyone something to point at, defend, and repeat in a meeting, even when everyone quietly knows the work is more complicated than the number can carry. The goal is not to replace velocity with a rework rate as the new single truth. A local rework signal earns its place because it adds a missing dimension. It should sit beside velocity, quality, stability, and flow, and it should tell us whether apparent progress carried a hidden durability cost. No serious productivity framework lets one metric tell the whole story, whether that metric is velocity, rework, deployment frequency, or anything else we decide to worship during a quarterly ritual. The goal is not a bigger scoreboard. The goal is better judgment.

How Can a Team Check Whether “Done” Stayed Done?

The good news is that seeing the Rework Shadow does not require a transformation program. A team does not need perfect tracker hygiene, a new governance office, or a vendor platform that looks like mission control for a moon landing. A team can begin with a lightweight check. I call it the Five-Story Field Test.

Pick five recently closed stories. Set a local analysis window. Look for follow-on work. Link what came back. Estimate the capacity impact. Bring the pattern into planning. That is enough to start learning, and learning is the point. The goal is not courtroom precision. The goal is planning honesty.

The phrase “local analysis window” carries weight. Thirty days can be a useful starting point, but so can the next sprint or the next release window. The right window depends on the team’s cadence, release rhythm, support pattern, and product context. Thirty days is not magic, not an industry standard, and not a moral law. It is a practical lens, and you should tune it to the way your team actually ships.

Then ask the plain questions. Which stories were marked done? Which generated follow-on work? What kind of follow-on work appeared? Was it linked back to the original story? How much capacity did it consume? A rough local signal can still improve the conversation. If five recently closed stories produced three follow-on items that ate meaningful time, the team does not need a philosophical debate about whether velocity is good or bad. The team needs to ask what the route is missing.

What Is the Better Route From Velocity to Real Progress?

The broken route is familiar because many organizations have normalized it. Story closed, points counted, velocity rises, dashboard turns green, leadership plans against the green dashboard, and rework appears somewhere else. The route feels efficient because the signal moves quickly upward. The problem is that the signal is under-instrumented. It carries closure but not durability, activity but not the cost of work returning through another door.

The better route adds a few checks before confidence hardens. Story closed, follow-on window checked, rework linked, local rework rate estimated, capacity adjusted, and planning confidence corrected. That route takes slightly longer, which is the point, not a weakness. Speed without correction just produces prettier mistakes.

Subscribe now

The better route does not abandon velocity. It gives velocity witnesses. Velocity can stay in the room. It just cannot testify alone.

This is where the Rework Cost Calculator comes in. Subscribers received the Rework Cost Calculator in Monday’s Leader’s Dispatch. It turns your team’s local rework observations into a rough-order estimate of capacity and cost impact you can bring to the next QBR, so you are not planning against capacity the Rework Shadow already spent.

Rework Cost Calculator

39.7KB ∙ XLSX file

Download

The Rework Cost Calculator helps you turn hidden follow-on work into a local planning signal you can bring into your next sprint review, retrospective, or QBR. Instead of treating velocity as proof that work stayed done, the calculator shows how much capacity may be quietly consumed by defects, clarifications, cleanup, reopened items, support issues, and dependency fixes after work was already counted as complete. This is not a benchmark, scorecard, or blame tool. It is a rough-order decision aid for seeing the capacity your green dashboard may have missed.

Download

The phrase “rough-order” matters, and so do the guardrails. The calculator uses your own local inputs, with no baked-in industry benchmarks. It is not an accounting statement, an ROI guarantee, or an official DORA metric. It is explicitly not a tool for ranking individuals or teams. If you turn it into a leaderboard, you will recreate the exact metric theater this episode exists to avoid. It is a planning tool. It helps leaders ask better questions: how much recently closed work came back, how much capacity follow-on work consumed, how planning assumptions should change, and where the route needs repair.

That is the work. Not blaming people, not worshiping metrics, and not pretending every green dashboard is a lie. The work is to build a route where progress can survive scrutiny. A healthier route does not only ask how much work closed. It asks what stayed closed. Velocity tells you whether work moved, rework tells you whether some of that movement came back, quality tells you whether the work held, and capacity tells you what the team can honestly promise next. Planning confidence improves when those signals travel together. A green dashboard is not the problem. A green dashboard without witnesses is.

This is one reason I keep writing Collaborate Better: because the closure-completion gap is not just a metrics problem. It is a collaboration problem where people keep inheriting the cost of work that the system has already congratulated itself for finishing. Better collaboration is not softer language or more cheerful meetings. It is the discipline of making work, ownership, decisions, and durability visible enough for people to act on them together. You can learn more at CollaborateBetter.us.

Next in Route Rebuilder: Part 5, The Route That Outsourced Judgment to the Tool, where an AI recommendation becomes a decision without anyone deciding.

P.S. Pull the last five closed stories from your board. Ask how many stayed done thirty days later, and what the rework actually cost. Reply and tell me what you found. I read every one.

Regards,

Mark 👋

Evidence note

The cost figures in this article are illustrative and context-specific, not benchmarks. The 40% figure comes from a single IEEE Software analysis of defect correction in its own project context. The 40% to 80% maintenance range, averaging around 60%, comes from Glass’s historical synthesis of earlier studies and should be read as a reason to measure locally, not as a current standard. DORA defines four core metrics (Deployment Frequency, Lead Time for Changes, Change Failure Rate, and Mean Time to Restore) plus Reliability, and does not define an official rework metric; any rework signal here is a local planning measure. SPACE is used only to support the multidimensional argument, not to endorse any specific metric or tool. Goodhart’s Law is used as a descriptive lens, not as proof. All rework rates and costs are local; compute your own.

Citations and Research Binder

3.71MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Route Rebuilder Episode 004: What Happens When Velocity Looks Healthy but the Work Does Not Stay Done?, along with the article’s eight infographics, Rework Cost Calculator, Five-Story Field Test, local rework-rate language, and core distinction between administrative closure and operational completion. It ties the article’s key claims to admissible evidence, separates practitioner diagnostics from formal research, and defines the limits of the Rework Shadow argument. The binder’s core claim is simple: velocity is not the villain, but velocity alone cannot prove that work stayed done. A green dashboard can accurately report closure while still missing the follow-on work that returns through defects, clarifications, cleanup, reopened items, support issues, dependency fixes, and operational drag. Closure is a status. Completion is a result. Without a local durability signal beside velocity, teams can create the illusion of delivery health while the next sprint quietly inherits work the previous sprint already counted. The research layer supports the article’s careful use of story points, sprint velocity, Goodhart’s Law, throughput metrics, DORA, SPACE, defect correction, software maintenance, rework, delivery stability, productivity measurement, and local planning heuristics. It grounds the article’s central warning that activity metrics become dangerous when they are treated as complete evidence of productivity, quality, or durability. It also supports the article’s stance that serious productivity assessment requires companion signals, not a single overpromoted number. The cost layer supports local modeling through Bystander Burn, Investigation Tax, and Compounding Rework. These are practitioner cost categories, not universal financial benchmarks. They help teams name the coordination time, duplicated investigation, cleanup load, and future capacity loss that appear when work marked done returns through another route. The binder supports cost modeling only as a rough-order local planning exercise, not as audited finance, ROI proof, or a universal claim about software teams. The tool layer supports the Rework Cost Calculator as a lightweight planning aid that turns local follow-on work observations into rough-order capacity and cost estimates before a QBR, sprint review, retrospective, or planning conversation. It also supports the Five-Story Field Test as a practical way to inspect recently closed work and identify whether a team has a defect pattern, clarification pattern, dependency pattern, reopened-work pattern, support pattern, or acceptance-criteria pattern. The calculator’s purpose is not to score teams. Its purpose is to help leaders see the capacity their green dashboard may have missed. The binder also defines the guardrails for Episode 004. The Rework Cost Calculator is not an accounting statement, ROI model, DORA metric, industry benchmark, employee ranking tool, team comparison tool, or substitute for engineering judgment. Thirty days is treated as a useful local analysis window, not an industry standard. Rework rate is treated as a local planning signal, not a formal productivity measure. Follow-on work is not automatically failure, and velocity is not automatically misleading. Fast movement is not bad, green dashboards are not lies, and defects, clarifications, cleanup, support issues, and dependency fixes must be interpreted in context. The result is a decision-grade evidence pack for engineering leaders, product leaders, delivery leads, Agile coaches, PMO partners, platform teams, and cross-functional teams that need to distinguish movement from durable progress, protect velocity from becoming metric theater, and rebuild the route between closed work, completed work, and honest planning confidence.

Download

Previous:

More Content to Discover:

👋 Welcome to my paid subscriber-only edition of Empathy Engine (🔒 Leader’s Dispatch). Each week I build evidence-informed tools for product professionals, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

Mara shipped the dashboard on Tuesday. Not a prototype, not a mock-up, not one of those “mostly working” demos that only behaves while the founder sits beside it, whispering encouragement like a stage parent at a middle school talent show. The real customer dashboard went live. The workflow ran. The data moved. The metrics turned green.

Cursor scaffolded the logic. v0 shaped the interface. Make.com kept the workflow moving. Claude handled copy, summaries, and customer-facing drafts. Work that once needed a small team and several weeks moved through Mara’s solo stack in two focused days. That deserves respect before anyone starts shouting “scale.”

Previously:

The solo window is real in a specific way. AI has expanded what one capable founder can ship alone, especially in knowledge work, where drafting, prototyping, research, workflow design, and customer communication now move faster than the old playbooks expected. Solo is not a failure state. Staying solo can protect speed, margin, clarity, and autonomy.

Then Wednesday arrived. Three customer emails were waiting before the coffee was finished. One was from Dani Park, Mara’s best customer, asking for a pricing exception that sounded reasonable and could quietly set a precedent. Another described an edge case that technically worked but felt wrong inside the customer’s real workflow. The third asked for a small feature tweak that looked harmless until Mara pictured the roadmap bending around it.

Claude summarized each thread and drafted three polite replies. The replies were logical, professional, and almost right, which made them more dangerous than if they had simply been bad. Mara rewrote all three, because the words were never the problem. The problem was that every customer-facing consequence still routed through her judgment.

I have had my own versions of Mara’s Wednesday. In my Empathy Engine workflow, the stack can organize a draft, shape the argument, help generate visuals, and prepare promotional copy before I have finished my coffee. That does not mean the final call has left my desk. I still have to decide whether the claim is fair, whether the tone respects the reader, whether a collaborator is being represented accurately, and whether the piece says something I am willing to have my name carry.

That pattern is not new to AI for me. Years of coaching, facilitation, and improv taught me the same thing in rooms full of humans: the agenda can be clean, the exercise can be smart, and the plan can look correct, while the real judgment is still reading what the room needs next. Almost-right output can move the work forward. Context decides whether the work should carry your name.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

That is the uncomfortable center of this episode. The tools did not fail Mara. The stack did exactly what she built it to do. The dashboard shipped, the drafts appeared, the workflow moved, the queue thinned, and the options surfaced. The final judgment still belonged to one person.

AI can draft around the question, summarize the tradeoff, and generate plausible answers all day. What it does not do is carry the consequence of what the company promises next. That is not a knock on the tools. It is a description of where accountability lives. The work is moving, and the meaning of the work is still concentrated in one human nervous system.

Once the stack works, overload does not disappear. It hides, and it hides in more than one place. In Episode 2 I sorted the friction into three loads: execution, correction, and decision. Post-solo, those three are still here under plainer names, and two more appear the moment another human enters the picture:

Task load: the manual work AI did not remove. System load: the hand-off cost of being the one who moves context between tools. Review load: the cost of verifying almost-right output, which in Episode 2 I called the supervision tax, a specific form of the Judgment Tax. Judgment load: the consequential calls that still route to one person. Role ambiguity: a label arrives before the decision rights it implies. Control tension: another person’s input feels like both leverage and loss.

You will recognize each of these as the article goes on. Naming them now is the point, because the next move depends entirely on which load is actually heavy.

Why does the bottleneck move from execution to judgment?

In the older version of solo work, execution was the visible constraint. The founder needed more hours, more hands, more capacity, because the work piled up faster than one person could build, draft, research, support, sell, and ship. If the business felt stuck, the explanation was usually simple: too much doing, not enough time.

AI changes that equation, though not universally and not with the clean magic promised by people who use “autonomous agents” the way previous generations used “synergy,” which is to say, as a spell rather than a plan. In many founder workflows, AI does reduce task time and expand what one person can analyze, prototype, write, test, and prepare. Execution capacity gets dramatically larger.

That does not make the business lighter. Execution speeds up while judgment concentrates. The founder is no longer waiting on a draft, a mock-up, a summary, or a workflow. The founder now has to decide which draft is safe, which mock-up fits the promise, which summary changes the next move, and which workflow can actually be trusted.

Before AI leverage, the bottleneck sat inside the work. After the stack works, AI builds, drafts, triages, summarizes, and surfaces options, but the meaningful arrows still converge at one place: final judgment. That convergence is where the old advice gets sloppy.

The standard next move after solo strain is treated as obvious. Hire someone, delegate more, add a VA, find a co-founder, buy another tool. Any of those can be right in the right context. They become expensive mistakes when they are used before the founder understands which load has actually become unbearable. The better question is not whether the founder needs help in some motivational-poster sense. The better question is which decisions still require the founder every single time.

Why can AI make a solo founder feel more overloaded, not less?

The hard part is not always the big strategy call. Often the real load is smaller, quieter, and more irritating. A customer asks for an exception that seems harmless. A support reply needs a tone adjustment. A feature request looks tiny until the founder sees where it points the roadmap.

None of these feels large enough to stop the day. That is the trap. AI can generate the draft, summarize the thread, list the options, and suggest the next move. The founder is no longer staring at a blank page. The founder is staring at several plausible paths, each with a different consequence attached.

That is how speed turns into judgment load. The system hands Mara more to weigh, not because the system is broken, but because plausible options still require discernment. The work shifts from making something exist to deciding which possible thing should carry the company’s name.

Some founders solve this by improving their solo operating system. They batch decisions, set review windows, keep a decision log, write better prompts, and define a few principles before the next exception lands. Trust over speed. Roadmap integrity over custom requests. Clarity over cleverness. Those moves matter, because the answer is often not another person.

The real risk is misdiagnosis. If every form of strain gets called a hiring problem, the founder adds people before understanding the load. If every form of strain gets called a tooling problem, the founder keeps buying software to avoid naming the judgment at the center of the business. Neither move is brave, and both get expensive.

Why is almost-right AI output still work?

The dangerous output is almost right. It looks professional, sounds polite, and reads as competent. It hands the founder relief, because momentum has appeared, and it hides its real cost, because the founder still has to verify whether the draft fits the situation, the customer, the product, and the promise.

Mara’s draft to Dani was polished. The tone was right, the wording was clean, the summary was accurate. The draft still missed the relationship, because Dani was not just another customer in a queue. She had become a kind of product conscience for FlowPilot, the customer whose feedback mattered because she saw the product from inside a real operating environment. Granting her pricing exception might protect trust. Granting it casually might create a precedent Mara would regret. The draft could help with language. It could not know which promise mattered most.

This is review load, and it is not new. In Episode 1 I named the broad cost of carrying every high-consequence decision the Judgment Tax. In Episode 2 I named one specific form of it the supervision tax: the time and energy spent checking, correcting, routing, and approving work before it is safe to use. Almost-right output is the supervision tax at its most expensive, because the founder is not editing words. The founder is verifying meaning.

The promotional layer is where I feel this most. An AI draft can produce a clean Substack Note, a strong title, or a Pinterest description that looks ready to go. Sometimes the hook is even good, which is rude because now I have to be responsible. The problem is that a good hook can still bend the promise. It can make the article sound more absolute, more dramatic, or more certain than the piece actually earns.

That review is not cosmetic. I have had a supposedly finished promo take half an hour or more because I had to ask whether the language would bring the right reader into the right expectation. The draft understood attention. My job was to protect trust. That is the piece AI can assist, but not own.

On a calm day, that can feel powerful. On a hard week, it feels like conducting an orchestra where every instrument is technically talented and none of them knows the song. The founder becomes editor, strategist, trust steward, and final signer, which is impressive right up until it stops being sustainable.

Name the judgment before you name the relationship.

The inbox is the visible version of this problem. Mara had already met the invisible version a few months earlier, and it had cost her more. The same fatigue that made Wednesday’s replies feel heavy had, months before, made a different shortcut feel reasonable.

FlowPilot had just crossed a small but real milestone. Revenue was up, customers were renewing, and the product finally felt less like an experiment and more like a business. That should have been a good week, but success has a way of making loneliness feel operational. Mara’s college friend Jess had been following the company from the sidelines. Jess was smart, warm, and interested. Over coffee, the conversation drifted from encouragement to involvement, and Mara, tired of carrying every important call alone, offered Jess a thirty percent co-founder stake. The offer felt generous, because Mara was trying to turn trust into structure.

The offer skipped the most important question: which judgments would Jess actually help carry? Within three weeks, the mismatch surfaced. Jess expected a strategic voice. Mara expected execution help. Jess thought partner meant real authority. Mara still expected to make the product calls. Neither person was malicious, and neither was foolish. Both had filled an undefined space with different assumptions.

Share

That is how vague labels create expensive confusion. Co-founder, contractor, friend, advisor, operator, right hand: each can create emotional relief before it creates operational clarity. They make the founder feel less alone, make the other person feel valued, and make the future feel more settled than it is. A label is not a strategy.

I have made smaller versions of Mara’s mistake in creative work, and I have watched larger versions happen inside organizations. The pattern is always more ordinary than the damage it creates. Someone gets called a partner, champion, lead, or right hand before anyone names the judgments attached to that word. One side hears trust. The other hears authority. Everyone thinks the relationship has become clearer because the label got warmer. Then the first hard decision arrives and the gap introduces itself.

The first post-solo mistake is not always waiting too long to add someone. Often the first mistake is naming the relationship before naming the judgment. Customer exceptions, roadmap tradeoffs, pricing precedent, product direction, sales promises, dissent rights, and decision authority are the real objects on the table. The relationship label should come after that map, not before it.

This is also where the boundary has to stay plain. Nothing here is legal, tax, employment, compensation, equity, or securities advice. A founder making structural decisions needs qualified professionals. The point is not to tell anyone what to offer another person. The point is to stop using a familiar label as a substitute for clarity. Jess did not teach Mara that needing help was wrong. Jess taught her that vague help can be worse than no help.

What is the difference between more hands and shared judgment?

After a mistake like that, the natural swing is the opposite direction: no partners, no collaborators, no more let-us-see-where-this-goes conversations over coffee. That reaction is understandable. It is also a different misdiagnosis.

The lesson is not to never involve another human. The lesson is to understand which kind of help the business actually needs. Some founders need more hands. They need someone to schedule, clear the inbox, move tasks, run repeatable processes, organize files, and take friction out of the day. That is real work, and no serious person should sneer at it.

Some founders need shared judgment. They need someone who can challenge the roadmap, pressure-test customer promises, spot precedent risk, hold product context, and push back when it matters. Those are not the same need, and confusing them is how founders end up disappointed with perfectly capable people they hired for the wrong job.

Read more

Maya starts counting in her head. Eleven services shipped last quarter. She can remember two review meetings, maybe three. She looks around the room and realizes everyone else is doing the same math. The silence that follows is not guilty. It is something worse. It is the sound of competent people calculating, and coming up empty.

A review gate is not a control because it exists. A review gate becomes a control when teams actually use it, trust it, and leave evidence that real scrutiny happened. The box was on the diagram. The arrow pointed through it.

The work had stopped visiting.

If You’re Skimming

• A gate that exists on the diagram is not the same as a gate that operates in the work.

• Teams rarely rebel against a review gate. They adapt to its friction, and the route teaches the workaround.

• Approval is not scrutiny. A thumbs-up can move a change forward without anyone owning the risk.

• Use the Five-Change Field Test to find whether your gate is operating, not merely documented.

👋 Welcome to this week’s edition of Empathy Engine. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

In Episode 1, a warning died in a busy incident channel because receiving is not routing. In Episode 2, a handoff became a gap because a closed ticket is not a completed handoff. Episode 3 follows the same failure one boundary deeper: a checkpoint that everyone can point to and almost nobody passes through. The signal had a channel. The handoff had a ticket. The gate has a diagram. This episode is about what the diagram quietly trains people to do.

What Happens When the Gate Still Lives on the Diagram?

Maya, her review board, and that quiet room are composites, not a disguised client or a single remembered meeting. I use them because the pattern is real even when no one incident should carry the whole argument. The tools change, the industry changes, and the diagram changes.

I have sat in that room. I have watched a clean process diagram describe a route everyone knew the work no longer followed. The strange part is how quiet the room gets when the slide still looks right and the people in it know it is wrong.

On paper, the route looked disciplined. A request came in, requirements were gathered, the design was prepared, and the review happened before implementation. After that came testing, release, and whatever quiet satisfaction comes from a process chart that looks like it was designed by someone with a ruler, a framework, and three uninterrupted afternoons.

The real work had been moving through chat-thread approvals, code-review sign-offs, escalations, shadow workarounds, and late rework. The gate still lived in the documented process. The work had found other doors. Some gates work well, and plenty of organizations run reviews worth the time they take. This episode is about the ones that quietly stop working while the diagram keeps vouching for them.

This is the failure in one frame. The diagram shows intent. The route shows reality. When the real route flows around the gate, the box on the chart stops being proof of control and starts manufacturing false confidence, and false confidence is what makes leaders stop looking for the gap.

Existence Is Not Operation

Many organizations can readily prove they designed a gate. Far fewer can show that people actually use it. Fewer still can show that the gate changes decisions, catches risks, or leaves a record of meaningful scrutiny.

A documented control tells you what should happen. An operating control tells you what does happen. An effective control tells you that what happens actually reduces risk. Many teams stop at the first level because the first level is the easiest one to show in a slide, an audit packet, or an onboarding deck.

That is why “Do we have a gate?” is the wrong first question. The better question is “Can we show the gate operated the last time eligible work reached it?” Answering it requires evidence from real work: which changes were eligible, which ones entered, how long review took, and what happened afterward. Existence is the start of the question, not the answer.

What Does a Slow Gate Teach a Team Under Deadline?

The review queue shows four days. The change would take thirty seconds to deploy. The engineer looks at the sprint board, looks at the queue, and quietly scopes the work so it does not technically require the review. Nobody announces anything. Nothing in the process document changes.

People do not usually begin by rebelling against a gate. They adapt to friction, and a slow gate under deadline pressure becomes a lesson: the official route is not the route that gets work done. The system teaches the behavior through repetition, especially when bypassing gets rewarded with delivery and using the gate gets punished with delay.

This is how the loop forms. The gate slows the work, deadline pressure rises, someone finds a workaround, and delivery happens anyway. Leadership sees movement, the gate remains unchanged, and the workaround gets repeated until it stops feeling like a workaround at all.

That does not make the bypass noble. Do not praise the bypass; diagnose the route. Some bypasses are reckless, unsafe, or politically convenient, and repeated bypasses are still worth studying for one reason: they show where the documented route and the real work have drifted apart. When teams keep routing around a gate, the sharper question is not “Who broke the process?” It is “What did the process teach people to do under pressure?”

I wish I could say I have only observed this from a safe distance. I haven’t. I have made the practical choice, moved the smaller version of the work, and let the heavier review path become someone else’s future problem. That is not a confession because I think I was uniquely careless. It is a confession because I was being rational, the way most people in that seat would have been, inside a route that rewarded the wrong move.

The Architects of the Paper Gate

Go back to Maya’s room and look at who built this route. Somewhere upstream is the security architect who drew that diagram three years ago and meant every box of it. She is the Designer, and she built the gate in good faith to catch real risk. The compliance partner at the front of the room is the Inspector. His checklist has a field for whether the gate exists. It has no field for whether the work still visits. The Enforcer is not in the room yet. The incident reviewer who will eventually meet this gate arrives last, after the override has become a pattern, when the cost has a date and a name.

Each role is doing its job. The Designer can prove intent, the Inspector can prove documentation, and the Enforcer can prove damage. Nobody in the chain is positioned to prove operation, which is the only thing that was ever going to keep the gate real. As in the first two episodes, this is just a practical lens for inspecting the system, not a validated taxonomy. Changing any one actor would not fix the script.

Why Does a Thumbs-Up Count as a Review?

A three-second “LGTM” moves the change forward. A thumbs-up closes the thread. A green dashboard reassures a manager who has eleven other things to check before lunch. The workflow advanced, the record exists, and none of it proves that meaningful scrutiny happened.

Episode 1 called this the Ack Trap: acknowledgment creating the appearance of control. At a review gate, the trap scales up, because approval leaves an artifact. False proof can look more convincing than no proof at all.

Share

Real proof looks different. Real proof has a named owner, review evidence, and a follow-up action. It tells you not only that the gate was touched, but that something happened inside it. The rubber stamp is not a personality flaw; it is a routing failure that appears when the approval mechanism is easier to satisfy than the underlying risk.

I have clicked approve when “approve” really meant “I trust you,” not “I checked this.” In hindsight, I wish I hadn’t let the time crunch rush what should have been a more intentional look. That distinction is small enough to disappear inside a workflow. It is also large enough to matter when the gate is supposed to protect the decision, and the fallout dwarfs whatever time the shortcut saved.

Machine-Speed Output, Human-Speed Gate

The diff looks clean. Formatted, tested, documented, and confident. The reviewer scans it, feels the small pause where a question could go, and clicks approve, because questioning polished work feels like the slower path.

Part of that is mechanical, not moral. Reviewers lean on surface signals, and messiness is the cue that usually invites a closer look. Polished output removes the cue without removing the risk.

AI did not invent weak gates. It did not invent shallow review, performative approval, or the habit of treating a workflow as proof that judgment occurred. What AI changes is throughput. When generation gets faster, verification gets heavier, and the gate that barely worked at human speed starts absorbing machine-speed volume.

This does not mean AI killed code review. That claim is too broad, too dramatic, and too easy to misuse. The safer truth is more useful: AI-assisted work can increase the importance of verification, especially where the review route was already fragile. The danger is not that AI makes human review obsolete. The danger is that AI makes weak human review look productive for longer, moving more artifacts through the gate while less actual thinking happens per artifact.

What Does a Bypassed Gate Actually Cost?

The cost language here is local and illustrative. No borrowed industry number will match your team, but three familiar categories tend to surface when you trace a bypassed gate backward. Bystander Burn is the time several people spend half-monitoring a change nobody examined. Investigation Tax is the duplicated effort when the incident review has to reconstruct the scrutiny that should have happened at the gate. Compounding Rework is the cleanup when downstream work was built on a change that was approved but never inspected.

I have done the after-the-fact accounting in Azure DevOps. A change that looked small when it slipped through review came back later as clarification threads, duplicate investigation, and a blocked handoff between people who thought someone else had checked the risk. The original review might have taken thirty minutes from two people. The cleanup took parts of three calendars across two days we could not afford to lose, which is how a “faster” route quietly became the slower one.

The same gap bills different calendars. For the engineer, it shows up as a four-day queue wrapped around a thirty-second change. For the security lead, it shows up as a surprise escalation for something the diagram says was reviewed. For the manager, it shows up as a schedule slip explained by “waiting on review” for work that quietly never waited at all. Multiply the hours by your own loaded rates and the math becomes local, specific, and hard to ignore.

How Can You Tell Whether a Gate Is Real?

At some point, leadership has to move from confidence in the chart to evidence from the route. If the gate is real, the route leaves traces, and six signals will show them: adoption, cycle time, bypass reasons, ownership clarity, scrutiny depth, and update cadence. The audit below turns each one into a question you can ask in a thirty-minute review.

None of these are perfect on their own. A fast review is not automatically shallow, a long review is not automatically thoughtful, and review should take enough time to indicate actual attention given the complexity and risk of the change. Episode 1 readers will recognize the family resemblance: just as MTTO asks how long a signal stayed visible before someone owned it, these signals ask how long a gate has been visible without evidence that it operates. Both are local learning lenses, not scorecards for individuals.

Good Gates Match Risk to Scrutiny

A weak gate does not prove that governance is bad. It proves that governance needs to fit the work, so the answer is not fewer gates by default and not heavier gates everywhere. The answer is better-routed gates that match scrutiny to risk.

Low-risk changes should not wait behind the same gate as high-impact architectural decisions; automation, static checks, and safe-to-proceed criteria can carry that load. Medium-risk changes may need peer review and clearer decision checkpoints. High-risk changes deserve the deliberate version: named reviewers, impact assessment, human judgment, and an evidence trail. A gate that takes four seconds may be superficial, depending on the risk involved. A gate that takes four days may train avoidance if that delay does not come with visible value.

This is where the politics deserve care. Security is not the villain here, and neither are engineers, compliance, or managers, although managers (and, if we are honest, the rest of us) do have a remarkable talent for discovering “just one more quick thing” at the least helpful possible moment. In this story, the villain is mismatched routing: a gate too heavy for routine work, too weak for risky work, too slow for real delivery pressure, or too disconnected from any evidence that it operates.

How Do You Run the Gate Integrity Audit?

Pick one gate. Do not audit every gate in the organization at once unless your secret ambition is to create a governance swamp and then slowly sink into it with a clipboard. Choose one that matters, tied to security, architecture, change approval, or code review, and turn the six signals into six questions.

What percentage of eligible work actually used this gate? If the answer is vague, that is the first finding. How long does the gate take from entry to decision? Why do teams route around it? The reasons might be urgency, confusion, unclear ownership, hidden cost, or the quiet belief that the gate adds no value.

Then the second three. Who owns the result after approval, not who clicked approve, but who owns the decision and its consequences? What evidence shows real review happened: comments, test results, risk notes, follow-up actions? And when was the gate last changed based on what the organization learned? A gate that never changes is not automatically stable. It may simply be unattended.

The audit card started with one question I learned to stop softening: “How much eligible work actually goes through this gate?” If the answer is “probably,” “usually,” or “we think so,” the gate may still exist. The evidence does not.

Subscribe now

The Gate Integrity Audit works best when you run it against recent, real changes with telemetry in hand, not as an annual slide in a compliance deck. The answers will not fix the system by themselves, but they will show you exactly where the documented route and the real route have drifted apart. From there you can make a responsible decision: automate routine checks, move scrutiny earlier, add ownership, shorten cycle time, or escalate high-risk work while lightening the rest. We will meet this diagnostic again later in the season, when we look at what a route that survives pressure has in common.

The Five-Change Field Test

You do not fix this with a transformation program. You fix it five changes at a time. This week, pick the last five changes that should have passed through the gate, and for each one, check four things.

• Did it actually enter the gate?

• Did it leave evidence of real review, not just an approval artifact?

• Did the approval have a named owner with authority over the result?

• If it had bypassed the gate entirely, would anyone have known?

Circle the change with no evidence behind it. That is your first route repair, and it will tell you whether your team has an adoption problem, a scrutiny problem, an ownership problem, or a detection problem. Those are different diagnoses, and they do not need the same fix.

The Gate Still Lives on the Diagram. Does It Still Live in the Work?

Modern work keeps widening the gap between documented process and actual flow. Work moves through chat threads, trackers, code platforms, meetings, dashboards, and AI assistants, and the real route is rarely as neat as the official one. The leader’s job is not to worship the gate. The leader’s job is to know whether the gate still works, and that takes operational evidence, not process nostalgia.

The process chart is not useless; it is a map of intent. But a map is not the road, and the road is where teams learn what actually gets rewarded. If the route rewards bypassing, the bypass becomes normal. If it rewards rubber-stamping, shallow approval becomes normal. If it rewards evidence, ownership, and calibrated scrutiny, the gate can become real again.

Now rerun Maya’s review, ninety days later, in the version where someone ran the audit. The same diagram goes up. The same question gets asked, and this time someone can answer it. Most eligible services went through the gate last quarter, the bypasses have reasons attached, and every approval names an owner. The room is not finished, but it is no longer guessing. The diagram has started catching up to the road.

The gate lives in the work now, not just on the slide. The only question left is whether yours does.

Subscribers received the Gate Integrity Audit Card below. This is a six-question diagnostic for testing whether a gate operates in reality, not just in documentation, with prompts for adoption, cycle time, bypass reasons, ownership, scrutiny depth, and update cadence, plus a worked example and the Five-Change Field Test tracker. If you want to test your own gates instead of guessing, the card is here:

Gate Integrity Audit Card

441KB ∙ PDF file

Download

The Gate Integrity Audit Card helps you test whether a review gate actually operates in real work, not just in a process diagram. In thirty minutes, you can inspect the last five eligible changes, identify whether the problem is adoption, scrutiny, ownership, detection, or update cadence, and choose one practical route repair for the next sprint. It also includes paste-ready team, ticket, and leadership blocks so the finding does not die in the meeting and can travel with the work.

Download

This is also one of the practical arguments behind my upcoming book, Collaborate Better: collaboration improves when teams build clearer routes for trust, ownership, decisions, and action. A review gate is just a route with a checkpoint in it. You can learn more at CollaborateBetter.us.

Next in Route Rebuilder: Part 4, The Route That Confused Speed With Progress, where a velocity metric became the thing that hid rework.

Next:

P.S. Pull up your team’s process diagram. Pick one gate. Ask out loud when work last actually passed through it. Reply and tell me what you found. I read every one.

Evidence note

The evidence binder for this episode separates documented control guidance, delivery-performance research, and local illustrative examples. All bypass rates, review times, and costs in this article are illustrative and local; compute your own.

Regards,

Mark 👋

The Route Rebuilder · Episode 003 · Mark S. Carroll · Substack.Mark-Carroll.com

Citations and Research Binder

3.71MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Route Rebuilder Episode 003: The Gate Still Lives on the Diagram, along with the article’s eight infographics, Gate Integrity Audit Card, Five-Change Field Test, local gate-integrity language, and core distinction between a documented review gate and an operating control. It ties the article’s key claims to admissible evidence, separates practitioner diagnostics from formal research, and defines the limits of the gate-integrity argument. The binder’s core claim is simple: a review gate is not a control because it appears on a process diagram. A gate becomes a control only when eligible work actually uses it, meaningful scrutiny happens inside it, evidence remains afterward, and someone owns the result. Without those elements, teams can create the illusion of governance while the actual route quietly moves around the checkpoint. The research layer supports the article’s careful use of control existence, control operation, control effectiveness, delivery flow, review latency, bypass behavior, lightweight governance, peer review, evidence-based oversight, and AI-era verification pressure. The cost layer supports local modeling through Bystander Burn, Investigation Tax, and Compounding Rework. These are practitioner cost categories, not universal financial benchmarks. The tool layer supports the Gate Integrity Audit Card as a lightweight diagnostic pattern that helps teams inspect adoption, cycle time, bypass reasons, ownership, scrutiny depth, and update cadence before treating a review gate as reliable. It also supports the Five-Change Field Test as a practical way to inspect recent work and identify whether the team has an adoption problem, scrutiny problem, ownership problem, detection problem, or update-cadence problem. The binder also defines the guardrails for Episode 003. The Gate Integrity Audit Card is not a replacement for formal compliance review, security architecture judgment, incident command, regulatory analysis, risk acceptance, release governance, or mature engineering leadership. Gate integrity is treated as a local learning lens, not an established industry standard, universal maturity score, or personal scorecard. Fast reviews are not automatically shallow, slow reviews are not automatically thoughtful, and bypasses are not automatically noble. The cost examples are illustrative local modeling, not claims that every bypassed gate produces the same impact. The result is a decision-grade evidence pack for engineering leaders, product leaders, platform teams, security architects, delivery leads, Agile coaches, compliance partners, and cross-functional teams that need to distinguish process documentation from operational reality, protect governance from becoming theater, and rebuild the route between review intent and working control.

Download

Previous:

More Content to Discover:

👋 Welcome to my paid subscriber-only edition of Empathy Engine (🔒 Leader’s Dispatch). Each week I build evidence-informed tools for product professionals, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

Mara shipped the dashboard redesign on Tuesday.

Not a prototype. Not a mockup. Not a private demo she could quietly bury if the thing embarrassed itself in public. The real workflow was live, customer data was moving through it, and the product looked better than she expected.

Her old team would have needed three weeks. The designer would have asked for another pass, the engineer would have warned about dependencies, and the project manager would have turned it into a multi-week plan. This time, Mara used her AI stack and shipped in two days.

Previously:

Three customer emails were waiting for her before the coffee had fully committed to being coffee. One customer wanted a pricing exception. Another had found an edge case in the new dashboard. A third, Dani Park, her most important account, wanted a feature tweak that sounded small but could quietly bend the whole product direction.

Mara asked her AI stack for help. The drafts came back quickly. They were logical, polite, and structurally useful. They were also almost right, which is the most exhausting kind of wrong.

The pricing email sounded generous but set a precedent she might regret. The edge-case response closed the ticket but missed what the bug revealed about onboarding. Dani’s reply was the most dangerous because the draft sounded confident while misunderstanding the actual trust problem underneath the request.

Mara rewrote all three.

The stack had worked. That was the strange part. AI had not failed her. The tools had done exactly what they were supposed to do: draft, summarize, route, and accelerate the work that used to consume entire days.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

What is the Solopreneur Ceiling?

The Solopreneur Ceiling is the point where a solo founder’s AI stack can increase output faster than the founder can review, prioritize, and make high-consequence decisions.

The ceiling is not proof that solo work is wrong. Many founders can now build, publish, prototype, support, and sell with a level of leverage that would have seemed absurd a few years ago. The solo win is real, and pretending otherwise would be contrarian for its own sake.

The ceiling shows up when output scales faster than judgment.

A founder may no longer be writing every draft, building every screen, researching every market, or answering every first-pass support message. Still, the important calls often route back to the same place. What ships? What waits? What violates the product promise? What protects trust? What sounds right, but is quietly wrong?

Why is the solo win real?

Any honest article about the Solopreneur Ceiling has to begin by saying the obvious part out loud: AI can make solo work dramatically more powerful.

In fields like software development and education, early studies have found that AI assistance can speed up specific tasks such as coding, drafting, and grading, without removing the need for human judgment on the hard calls.

Empathy Engine exists because the solo win is real. AI helps me move from research to article, from article to infographic, from infographic to Note, and from Note to a larger topic cluster without needing a full production team behind me. That has changed the practical ceiling on what I can build alone.

At the same time, the most important decisions have not left my desk. AI can help me produce options, but I still decide which one is worth trusting. It can help me sharpen a claim, but I still decide whether that claim is fair. It can help me scale the surface area of the work, but I still own the meaning underneath it.

AI can make execution cheaper, faster, and more available. A solo founder who once needed a small team to test an idea can now produce an early version, write the announcement, generate the onboarding draft, summarize customer research, and sketch the sales sequence in less time than a traditional team would spend planning the work.

For many founders, the solo window has expanded.

Mara’s two-day dashboard launch is not fantasy. A modern founder with good taste, enough domain knowledge, and a strong stack can now move with stunning speed. The stack can compress weeks into days and days into hours.

The problem begins when that speed creates more outputs than the founder can safely judge.

Why does the bottleneck move from doing to deciding?

AI does not remove every bottleneck. Sometimes AI moves the bottleneck.

Before the stack, the obvious constraint was execution. There were not enough hands, hours, drafts, prototypes, research summaries, support responses, or landing page variants. Work piled up because someone had to do the work.

After the stack, the visible constraint changes. The founder can suddenly generate a dozen useful options, three customer responses, five feature summaries, a new dashboard, and a product announcement in a fraction of the time. The work appears faster than the founder’s ability to decide what deserves trust.

That second question is heavier. A machine can give you ten pricing responses, but the machine does not own the future precedent. A tool can suggest a roadmap change, but the tool does not know what kind of company the product is becoming. An agent can draft a customer apology, but the agent does not understand the relationship history hiding behind a single frustrated sentence.

That hinge, output cheap and judgment not free, is where the work changes shape.

Misread this as a productivity problem and you do not just stay busy. You may approve the wrong pricing exception, ship the polished answer that quietly erodes trust, or add help that creates more work to review. The cost is not only time. The cost is decision quality.

Which raises the only question that reliably points to the right fix: is this a tool problem, a system problem, or a judgment problem?

Share

What are the signs you are still the bottleneck?

The first sign is the Rewrite Ritual.

The Rewrite Ritual happens when AI gives you a first pass, and the first pass is close enough to be useful but wrong enough to require real attention. The grammar is fine. The structure is fine. The tone is almost fine. Then you realize the draft missed the one thing that mattered.

Almost-right work can be more draining than obviously bad work. Obviously bad work can be rejected quickly. Almost-right work asks you to slow down, inspect the seams, find the hidden drift, and decide whether the output is safe enough to ship.

Mara’s customer replies were not useless. That was the problem. They were useful enough to keep, but not trustworthy enough to send. She had automated the typing, but not the judgment.

I recognize that feeling from my own work. While developing a client-recommendation example for Episode One, I got an AI draft that looked useful enough to keep. The structure was clean, the tone was professional, and the recommendation sounded reasonable.

Then I looked past the polish.

The draft had treated the client’s issue as a tooling problem. Better intake, better workflow, better software. Those ideas were not silly, which made the mistake harder to catch. The real issue was decision clarity: the team had not agreed who owned the call, what tradeoffs mattered, or what would make the decision good enough.

That is the Rewrite Ritual at its most expensive. The cost is not the typing. The cost is noticing when a polished answer solves the wrong problem.

The second sign is the Human Router.

This happens when your tools, agents, contractors, dashboards, and workflows all depend on you to move context between them. The research agent does not know what the support agent learned. The contractor does not know why the product direction changed. The dashboard knows something happened, but not why it matters.

You become the handoff.

The system looks automated from the outside. From the inside, you are the person translating meaning from one part of the machine to another. Every output still needs your context because the context was never fully externalized.

The third sign is the Dashboard Stare.

The Dashboard Stare happens when everything is green, and you still cannot move. The deployment succeeded, the automations ran, the drafts are ready, the data is clean, and the next step is one decision that only you can make. The work is not blocked by labor anymore. The work is blocked by your remaining decision capacity.

You are probably feeling this if:

• You rewrite most AI outputs before they reach a customer.

• You feel slower after the stack runs, not faster.

• Your day ends in unresolved decisions, not finished work.

• You are considering help but cannot name what kind.

If two of these are true, you are probably not looking at a tool problem.

Read more

The Demo Found the Gap

The demo is going well, which is the dangerous part. Dana has run this customer demo in her head a dozen times, and the board has been green all sprint. The feature shipped on time. The client is leaning in, nodding, asking the kind of questions you only ask when you are already imagining the rollout.

Then Dana clicks through to the new data feed. The screen hangs on a spinner. The spinner turns over once, twice, and resolves into a 500 error, live, in the one room where it absolutely cannot. Someone laughs the wrong kind of laugh. The client’s polite smile tightens into a polite question: “Is that something on your end?”

In Part B, The Rebuilt Route, the core distinction was simple: receiving is not routing. This demo exposes the next failure in that same family. Three external dependencies fed the feature. Each had its own ticket, assignee, and due date. Six weeks ago, all three were marked done. Every record says this work is finished, owned, and shipped.

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

If You’re Skimming

Cross-team work fails most often where ownership is assumed, not accepted.

The fix is not another meeting. It is naming who catches the work, and confirming they caught it.

Run the Five-Handoff Field Test at the bottom to find where your own routes leave ownership optional.

The Handoff That Wasn’t

The team did not fail because nobody owned the work. The team failed because nobody owned the transfer of the work. That distinction is small enough to miss in a standup and expensive enough to surface in a demo.

In Episode 1, we said it plainly: receiving is not routing. A warning can land in a channel and never reach an owner. Here the same failure repeats one boundary over, at the handoff between teams. The sender marks the work done and believes it moved. The receiving team gets a notification, assumes it is backlog grooming, and lets it sit. No one is wrong, and no one caught the baton.

Dana, Sam, and Priya are composites (not a disguised client or one remembered demo). I use them because the pattern is real even when no single incident should carry the whole argument. I have seen versions of this in planning rooms, retros, tool rollouts, and dependency reviews. The names change, the tools change, the industry changes; the move does not. The work becomes visible, the room relaxes, and no one confirms that ownership landed.

Here is the confession. I have seen a handoff clearly and still let it drop (not because I was careless, and not because the people around me were, but because the work looked visible enough to feel safe). It was the professional version of setting the baton down behind me without glancing back to see whether the next runner had a hand out. I told myself someone closer to the work had it. Later, when the dependency resurfaced, I understood what the route had actually produced: awareness without acceptance.

Closed Ticket, Open Handoff

There are two routes hiding inside every dependency, and we usually only watch one of them. The first is the route the tool records: ticket, assignee, status, closed. It has a clean beginning and a clean end, which is exactly why it looks finished.

The second is the route the work actually needed: sender, named receiver, accepted criteria, a confirmation that someone caught it. Those are not the same route, and the gap between them is where six weeks of silence live.

Picture a relay. The runner who finishes a leg does not get to decide the baton was passed. The pass only happens when the next runner’s hand closes around it. What we built instead is a track where the first runner sets the baton down, the clock keeps running, and everyone stands around admiring the relay dashboard. The board is green because the baton was placed. Nobody confirmed it was taken.

A closed ticket is not a completed handoff. A closed ticket means a record reached its endpoint. A completed handoff means someone caught the work (understood what arrived, knew what good looked like, and knew when to escalate). The difference is where ownership either lands or quietly becomes optional.

This is the line worth keeping: closed ticket, open handoff. The dashboard in Dana’s demo was not lying; it was answering the wrong question. It could tell her the tickets were closed. It could not tell her whether anyone had accepted what came next.

That is one of the illusions this article is built to diagnose. Not the only failure a team can have, but a specific, common, and fixable one: work that everyone can see and no one has caught.

The Ack Trap at Scale

Once a handoff moves into a shared channel, a quieter failure shows up. Acknowledgment starts to feel like movement.

It looks like this. Sam posts in the platform channel: “Hey team, auth dependency is ready for integration. Shout if you need anything.” A thumbs-up appears. Someone adds “nice, thanks!” The thread goes calm, the sender feels heard, and the group feels aligned. What none of that produced is a person who has said, out loud, “I’ve got it.”

An emoji is a read receipt. “Looks good” is a courtesy. Neither one is acceptance, and the difference is invisible right up until the demo. A useful lens here is diffusion of responsibility (when a message goes to a group and no one is named, it gets easier for each person to assume someone else will pick it up). I am borrowing that idea as a metaphor, not claiming your Slack channel behaves like a laboratory. But the shape is familiar enough to respect: the more people who can see a thing, the less certain it is that any one of them owns it.

There is a human reason this happens, and it is not laziness. Saying “I accept this” means signing up for the next move. Saying “this isn’t ready, I can’t take it yet” means friction with a colleague. A thumbs-up costs nothing and buys a day of quiet. In a hurry, the cheap signal often wins. Everyone saw it. That was the problem.

The Optional Receiver

I have a name for this pattern in the series: the Optional Receiver. It is a handoff where no specific person or team has clearly accepted the next move, so the route treats acceptance as something that will simply happen on its own.

Watch the chain of assumptions. The sender assumes the group saw it. The group assumes someone will clarify. The manager assumes the tool will surface anything stuck. The customer assumes the product will work. Written out, the chain looks absurd. Lived inside a busy sprint, it feels completely normal.

If you have ever marked something done and then stayed online a little longer because you were not entirely sure it had landed with anyone (you have felt this gap from the inside). That low background hum is the sound of work that is visible and unowned. It does not need a villain to stall there. It only needs a route that never forced anyone to say yes, no, or not yet. That is why the next move cannot be blame. It has to be route tracing.

Trace the Route, Not the Blame

This gap is almost never built by careless people. It is built by reasonable people whose vantage points do not line up. The designers of the route (the PMs who write and close the tickets) see work leave their board and read that as complete. The inspectors (the leads watching velocity and running the retro afterward) see healthy movement. The enforcers (the customers and account teams) feel the gap last, as a broken promise.

You can watch all three truths collide in a postmortem. Someone shares their screen and scrolls back through the ticket history. “It was assigned six weeks ago,” the PM says, and the history agrees. “I got a notification,” the platform engineer says, “and I assumed it was grooming.” The history agrees with that too. The room goes quiet, because everyone in it acted reasonably and the work still fell through.

The instinct I have earned in that quiet is to listen for two words: I thought. “I thought they had it.” “I thought that meant it was done.” “I thought the other team was tracking it.” When those sentences start arriving, I stop the conversation and ask what the route actually confirmed. “I thought” is often the sound a missing handoff makes after the fact.

That is why blame is the lazy diagnosis. The useful question after a handoff fails is not “who dropped this?” It is “where did the route let this drop?” When the person who can see the warning is not the person with the authority to move it, the route is already fragile (and no amount of trying harder closes that gap). A blameless review is not softer than blame. It is stricter, because blame stops at the nearest name and the route keeps failing the next time.

Share

The Local Cost of an Unowned Handoff

The cost of an unowned handoff is real, but the honest number is local. There are broad industry estimates for the cost of poor software quality (useful for sizing the problem space, but they are industry-wide figures, not handoff-specific, and borrowing one to describe your team would be a guess wearing a suit).

The honest accounting lives in your own work, and it comes in three shapes. Bystander Burn is the time several people spend seeing, monitoring, and half-investigating a thing nobody has accepted. Investigation Tax is the duplicated effort when the gap finally surfaces and someone has to reconstruct what happened. Compounding Rework is the cleanup when downstream work was built on a foundation that was never confirmed.

You do not need a number to feel it. I have watched the cost of an unowned handoff accumulate without a single dramatic failure. First the clarification thread. Then the duplicate investigation. Then the meeting where everyone tried to reconstruct what should have happened when the work changed hands. By the time the team understood the gap, the original task was no longer the only work (the cleanup had become its own dependency). Picture three people each losing an afternoon to a dependency no one accepted: that is a workday gone before the real fix even starts. Your numbers will differ; the pattern will not. The point is to stop pretending the gap was free.

The Ownership Assignment Checklist

The repair does not start with a bigger meeting. It starts with a smaller, clearer handoff (one that makes acceptance visible before the work moves on).

Ownership Assignment Checklist

612KB ∙ PDF file

Download

The Ownership Assignment Checklist helps teams turn a visible handoff into an accepted handoff before the route breaks. It gives you the seven fields, paste-ready ticket and chat blocks, Five-Handoff Field Test, MTTO capture line, false-handoff warnings, and team working agreement needed to make ownership explicit instead of assumed. Use it when cross-team work looks “done” on the board but still needs a named receiver, clear criteria, and a visible confirmation signal before the baton is truly caught.

Download

Rewind to the Tuesday Sam marked his dependency done, and watch the same moment go differently. Instead of “Backend dependency complete. Marking done,” Sam writes: “Ready for mobile integration. Receiver: Priya. Artifact: API contract v3 and test payloads. Acceptance criteria: mobile confirms response format and error handling by Thursday 2pm. Escalation: if not confirmed by then, route to dependency review. Confirmation: comment ‘accepted for integration’ on this ticket.” Priya reads it, finds the error-handling spec thin, and replies “returning (need the 4xx cases before I can accept).” That is not a failed handoff. That is the first handoff in this whole story that actually worked.

The difference is not paperwork. It is that someone is now the catcher (the named person who has to say I’ve got it or not yet, and either answer moves the route forward). Before you close any cross-team dependency, you can run a three-minute pass over the checklist’s core questions: who receives this, what exactly are they receiving, what do they now own, what proves they accepted it, and when do we escalate if they do not? If you cannot answer those, the ticket may be closed, but the route is still open.

What I have seen work are pieces of this, not a perfect system (a named-owner rule here, a blocker-escalation policy there, a readiness check that stopped one team from pulling work forward before the receiver had accepted it). The pieces worked when they changed behavior in the room, not when they looked impressive in a process document. They failed when they became invisible, optional, or socially unsafe to use. That is why I trust lightweight mechanisms, but only when each handoff comes out a little clearer than the last.

A word on what this is and is not, so the rest of the piece can stay confident. The checklist does not guarantee success; it gives a team a place to ask the questions that prevent silent failure. It does not create the trust that lets someone say not yet. It gives them shared, neutral language for using the trust they already have (“we’re missing acceptance criteria,” not “you did this wrong”). And it is a pattern to test and adapt to your own work, not a certified standard or a cure. Right-size it: heavier where the handoff crosses teams, customers, or release boundaries; barely there for routine work.

The Five-Handoff Field Test

You do not fix this with a transformation program.

You fix it five handoffs at a time.

Five Handoff Field Test Tracker

10.6KB ∙ XLSX file

Download

The Five-Handoff Field Test Tracker gives your team an editable way to inspect the next five cross-team handoffs and see where ownership is being assumed instead of accepted. It captures the receiver, acceptance signal, criteria, escalation path, confirmation signal, handoff status, MTTO, and first repair so the team can move from vague “handoff problems” to a specific broken field in the route. Use it alongside the Ownership Assignment Checklist when you want to stop debating whether work was “done” and start proving whether the baton was actually caught.

Download

The Five-Handoff Field Test. This week, pick the next five cross-team handoffs and, for each one, check:

• Was a receiver named?

• Did that receiver explicitly accept?

• Were the acceptance criteria clear?

• Was there an escalation path?

• Was there a confirmation signal?

Circle the handoff where no one was the catcher. That is your first repair. The review question that travels with it is short enough to say in any standup:

Subscribe now

Now run Dana’s demo again, in the version where Sam named Priya and Priya accepted. The new data feed loads. The integration holds, because the team that owned it knew it was theirs three weeks before anyone pointed a projector at it. The difference between the demo that failed and the demo that held was not talent, effort, or a better tool. It was a route that made someone catch the baton.

The Rebuild

Subscribers receive the Ownership Assignment Checklist for this episode. It turns a vague handoff into a lightweight, seven-field agreement (sender, named receiver, transferred artifact, acceptance criteria, review time, escalation path, and confirmation signal) that you can drop onto any cross-team ticket in under three minutes.

It also includes the reject-and-return path so receivers can push back on incomplete work safely, a local MTTO diagnostic for measuring your own time-to-ownership, and optional tool-automation examples for making incomplete handoffs harder to miss.

A note on that diagnostic: MTTO is a local lens in this series, not an industry benchmark. Use it to inspect your own ownership gaps, not to pretend your context matches anyone else’s.

The Route Was Missing

The team in the opening did not lack effort, tools, or assigned work. The ticket had a name. The board had a status. The demo had a date. What it lacked was a moment where someone caught the work and said so.

A closed ticket can end a task. Only accepted ownership completes the route. That is the whole difference between work that looks finished and work that survives the next handoff, and it is the difference between Dana’s first demo and her second.

This is also the larger argument behind my upcoming book, Collaborate Better. Better collaboration is not softer language or more cheerful meetings. It is the discipline of making work, ownership, trust, and decisions visible enough for people to act on them together. You can learn more at CollaborateBetter.us.

Next in Route Rebuilder: Part 3, The Route That Trained Override Behavior (how a review gate became the thing everyone learned to skip).

Next:

P.S. What is the last handoff you saw that looked closed but was not complete? Reply and tell me about the moment the work looked assigned but the route still failed. I read every one.

Regards,

Mark 👋

Citations and Research Binder

3.74MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Route Rebuilder Episode 002: The Route That Made Ownership Optional, along with the article’s eight infographics, Ownership Assignment Checklist, Five-Handoff Field Test, local MTTO language, and core distinction between a closed ticket and a completed handoff. It ties the article’s key claims to admissible evidence, separates practitioner tools from formal research, and defines the limits of the ownership-transfer argument. The binder’s core claim is simple: a status change can show that a record moved, but accepted ownership requires more than visibility. Reliable cross-team handoffs need a named receiver, a transferred artifact, clear acceptance criteria, a review point, an escalation path, and a confirmation signal. Without those elements, teams can create the illusion of done while the actual route remains open. The research layer supports the article’s careful use of coordination failure, role clarity, dependency management, psychological safety, escalation behavior, diffusion of responsibility, blameless review, checklist design, and team communication under pressure. The cost layer supports local modeling through Bystander Burn, Investigation Tax, and Compounding Rework. These are practitioner cost categories, not universal financial benchmarks. The tool layer supports the Ownership Assignment Checklist as a lightweight handoff pattern that helps teams clarify sender, receiver, artifact, criteria, timing, escalation, and confirmation before cross-team work is treated as complete. It also supports the Five-Handoff Field Test as a practical way to inspect recent or upcoming handoffs and find where ownership is being assumed instead of accepted. The binder also defines the guardrails for Episode 002. The Ownership Assignment Checklist is not a replacement for incident command, formal release governance, compliance review, root-cause analysis, or mature delivery judgment. MTTO, Mean Time to Ownership, is treated as a local learning metric, not an established industry standard, universal benchmark, or personal scorecard. The cost examples are illustrative local modeling, not claims that every open handoff produces the same impact. The result is a decision-grade evidence pack for product leaders, delivery teams, Agile coaches, engineering managers, program leads, and cross-functional teams that need to distinguish recorded movement from accepted ownership, protect accountability from becoming blame, and rebuild the route between assigned work and owned action.

Download

Previous:

More Content to Discover:

Leadership in Change

3 Structural Failures Behind Every Failed AI Pilot

TL;DR: Most AI pilots fail for three structural reasons that existed long before AI: mandate pressure that bypasses intake discipline, decision moments that do not survive the room, and intake systems that treat every request as equally urgent. Guest writer…

Read more

a month ago · 36 likes · 21 comments · Joel Salinas and Mark S. Carroll

AI can help you ship more alone. It still leaves the final call with you.

👋 Welcome to my paid subscriber-only edition of Empathy Engine (🔒 Leader’s Dispatch). Each week I build evidence-informed tools for product professionals, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

Not the prototype. Not the internal demo. The real workflow was live, data was moving through it, and customers could touch it. Her old five-person team would have needed three weeks, two rounds of handoffs, and at least one meeting where the bravest person in the room finally asked why the meeting existed.

Cursor helped her scaffold the code. v0 helped her get the interface moving. Her AI stack handled research, drafting, testing notes, and the kind of repetitive cleanup work that used to make a founder question every life choice between 4:00 and 4:17 p.m. Mara still made the product calls, but the distance between idea and shipped workflow had collapsed.

If you read Episode Zero, you will recognize the starting point. The stack works. You are still the nervous system.

That line was not meant as a complaint about AI. It was meant as a warning against confusing output with operating clarity. Tools can move work faster than the old system ever could, but the founder still feels the decisions arrive, stack up, and ask to be owned.

Mara’s Tuesday proves the first half. Episode One begins there because any honest conversation about what comes next has to start by admitting what AI has already made possible.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

The Solo Win Deserves Respect

A strange amount of commentary around solo founders skips the respect step. The commentary hears “solo” and immediately starts diagnosing the person. Too attached to control, too allergic to management, too dazzled by agents, too lonely, too stubborn, too something.

That misses the point. For many founders, staying solo is not avoidance. Staying solo can be strategy. Fewer handoffs. Fewer misaligned incentives. Fewer status meetings. Fewer people translating the founder’s intent into a slower and more expensive version of itself.

AI makes that strategy more powerful because AI reduces the cost of first versions. The blank page gets less blank. The prototype appears sooner. This article is not here to shame the solo founder. This article is here to help the solo founder see the solo stack clearly.

I am not writing about this from the press box. I work as a solo operator with AI in the stack, compressing drafts, sharpening options, and moving real client work faster, while still owning the judgment no tool can safely make for me.

What AI Changed

That does not mean every founder becomes magically productive the moment they open a new tab and type “act as my chief operating officer.” The evidence does not support that fairy tale, and neither does the lived experience of anyone who has ever asked an AI tool for one small revision and received a brand-new religion. Gains vary by task, tool, and operator. That boundary makes the celebration more credible, not less.

AI can expand solo execution capacity in meaningful ways, especially in drafting, prototyping, repetitive knowledge work, research synthesis, support triage, and first-pass software work. The solo window is not a universal promise, but the window is a real opening.

Mara felt the difference most on the support documentation. Before the stack, she would have spent a full afternoon writing the onboarding guide for the new dashboard: screenshots, step-by-step instructions, the FAQ section that customers actually use and the FAQ section that exists because someone once asked a question at 11 p.m. and the founder could not sleep until the answer lived somewhere permanent.

With the stack, the first draft existed before lunch. Not a good draft. Not a draft she would ship. But a draft complete enough that her afternoon changed shape entirely. She was no longer writing from scratch. She was reading, correcting, and deciding which sections matched how her product actually worked versus the product the AI imagined she had built.

That is the solo window at work: usable enough to begin thinking. AI is very good at creating the next thing to evaluate. Creating the next thing to evaluate is not the same as finishing the evaluation.

The Work That Stayed Human

Here is where the internet tends to get sloppy. Because AI can generate more work, people start speaking as if the work is done. A draft is not a decision. A prototype is not a product strategy. A polished paragraph is not necessarily an accurate paragraph, which is a deeply inconvenient fact for everyone who enjoys confidence with their hallucinations.

That is where Mara’s Tuesday victory becomes a Wednesday reality.

Three customers email her after the dashboard goes live. One asks for a pricing exception, one reports an edge case that technically works but feels wrong in the customer’s workflow, and one asks for a feature variant that sounds simple until Mara realizes the request could bend the product away from its original promise.

AI can summarize those emails. AI can draft replies. AI can generate three possible pricing responses and a tidy little table of pros and cons that looks authoritative enough to make a founder suspicious. But the emails are not asking for a summary. They are asking Mara what her company believes, what it will bend on, and what it will hold.

I have had the same Wednesday moment in my own work. I asked AI to help shape a client-facing recommendation, and the first version looked polished enough to pass a casual skim. The problem was not the writing. The problem was that it treated the situation like a tooling issue when I knew, from the actual conversations, that the real risk was decision clarity. If I had shipped the polished version, it would have sounded smart and solved the wrong problem. The tool could organize the material, but it could not know what the room had taught me.

The stack cannot decide what kind of company Mara is building. It cannot know which customer exception is generosity and which one is product drift. It cannot absorb the consequence if a rushed answer damages trust with her best account. Final approval, customer judgment, product direction, quality verification, pricing calls, and accountability for consequences ((that is the work that stayed human). Evidence that the founder’s job still exists.

In many workflows, AI compresses the doing.

What expands is the deciding.

Before AI, much of the founder’s time went into production work. Making, building, writing, coding, designing, formatting. After AI enters the workflow, some of that production time shrinks, but the founder’s role does not shrink with it. The work changes shape. The founder selects, edits, verifies, prioritizes, and owns outcomes.

I noticed the same shift in my own week before I had clean language for it. I was producing more, but my calendar felt less like making and more like reviewing, choosing, correcting, and deciding which version was actually worth putting my name on.

Mara felt it on Thursday. She asked her stack to draft three versions of the pricing exception response for her Wednesday customer. By the time she sat down with coffee, all three were waiting. Clean formatting, reasonable logic, slightly different positioning. The old version of this task would have taken an hour of staring and drafting. The new version took four minutes to generate and forty minutes to decide.

The draft was done before Mara had finished thinking about what the answer should be. That gap (between the draft arriving and the decision catching up) is where the shift lives.

The Judgment Tax

There is a name for this leftover burden: the Judgment Tax. Not a clinical diagnosis. A practical metaphor for the extra evaluation work that compounds when one person reviews everything AI produces.

I have felt this most clearly on afternoons when AI has given me exactly what I asked for: three clean outlines, two sharper titles, a stronger client-facing explanation, and a tidy set of options that all look plausible. Nothing is broken. That is almost the problem. By 3 p.m., the work is no longer generating material. The work is deciding which version deserves trust, which one misses the real context, and which one should quietly go in the folder marked “nice, but no.”

Share

The tax shows up as review load, context switching, decision volume, accountability weight, and the slow calibration of learning when to trust each tool’s output and when to verify line by line.

This is why measuring only time saved can mislead a founder. A workflow can save time and still increase judgment load. A tool can generate more output and still leave the founder with more to approve. That does not mean the tool failed. It means the founder needs to know what kind of leverage the tool is actually creating.

Read more

If you read the piece we published last week on Leadership in Change, you saw the structural diagnosis: mandate pressure, decision collapse, intake collapse. Three failures that sit underneath almost every AI pilot that goes sideways. That piece mapped the architecture. What it did not cover is what happens on the human side of the same problem, when the structure is missing and the team adapts by going quiet.

Leadership in Change

3 Structural Failures Behind Every Failed AI Pilot

TL;DR: Most AI pilots fail for three structural reasons that existed long before AI: mandate pressure that bypasses intake discipline, decision moments that do not survive the room, and intake systems that treat every request as equally urgent. Guest writer…

Read more

a month ago · 28 likes · 13 comments · Joel Salinas and Mark S. Carroll

is the person I would call for that conversation. He runs fractional Chief AI Officer engagements with mid-market teams and coaches individual leaders through AI adoption at the point where strategy meets behavior. His newsletter, , is one of the few places I have found where the advice sounds like someone who has actually sat in the room when the reaction went wrong, because he has.

What Joel wrote here names the part most leaders skip: the moment your team stops telling you the truth about what they are using, and why both of your natural reactions (excitement and panic-policy) make it worse. If my work gives you the intake funnel and the decision circuit, Joel’s work gives you the leadership posture that makes people willing to use them honestly.

I will let Joel take it from here.

TL;DR - Shadow AI usage spreads inside most organizations because leaders react to discovery with either excitement or panic-policy, and both reactions train teams to hide further. Closing the gap takes leader literacy before policy and a three-tier risk sanctioning system. Process alone never closes it.

In June 2023, a New York attorney named Steven Schwartz filed a legal brief built on six court cases that didn’t exist. He hadn’t invented them. ChatGPT had. He filed them anyway because he hadn’t told anyone he was using it, including the partner at his firm who signed off on the work. The judge sanctioned the lawyer, the firm took the public hit, and the story ran for weeks.

Here’s the thing, the story isn’t really about a lawyer who got lazy with a chatbot, because the more interesting question is what was happening above his head, in a firm where AI had quietly entered the workflow and nobody had created a place where saying “I’m using ChatGPT to draft this” sounded like anything other than a confession. The visible failure was one filing, but the pattern underneath it is running silently across most teams right now.

The pattern beneath the headlines

As you read this on Mark S. Carroll’s substack () you’ve probably already seen his recent diagnostic over at where he mapped the structural failures sitting under most failed AI pilots in the guest post he wrote for me. He gave you the architectural view. This piece is what I’d add from the behavioral side, because once the architecture is in place, you still have to deal with the very human reasons your team keeps defaulting to the broken pattern.

Here’s what I keep seeing when I sit with leadership teams… people on the team are already using AI, not in the sanctioned way, not in the official rollout, not in the tools listed on the IT inventory.

The first time leadership learns the dependency exists is usually when something breaks: a hallucinated stat in a board deck, a bad source in a client memo, a fabricated quote in a press release that’s already out the door.

By the time you find out, the credibility cost has already cleared.

Subscribe now

The leader frames the discovery as a sign of bottom-up adoption, posts about it on LinkedIn, and mentions it to the board as proof that the org is AI-forward. And the team reads that reaction in about ten seconds. The signal back to them is: don’t bring me the risk stuff. Don’t tell me the contract you drafted used a model that’s known to fabricate citations. And please don’t mention that the marketing copy went out without anyone checking the source attribution. The excitement is a vibe, and a vibe is the worst possible environment for somebody trying to say “actually, I’m a little worried about what I just sent.”

The second reaction is panic-policy. “We need a committee. We need an approval process. We need a sign-off workflow.” A memo goes out. Anyone using AI without sanctioned access gets called into a meeting. The next people who get caught become the cautionary tale at the all-hands. And the team reads that reaction in about ten seconds too. The signal back to them is: hide harder. Usage doesn’t stop, it just goes one layer deeper, into personal accounts, into Slack DMs instead of email, into “I just typed this myself” disclaimers on work the model actually wrote.

Both reactions train your team to stop telling you the truth. That’s the actual cost.

The literacy gap nobody names

Underneath both reactions sits the part nobody wants to name out loud. The leader is usually more ignorant of the tool than the people using it.

I mean it. The person on your team who quietly figured out that Claude is better at long-form drafts and ChatGPT is faster at code, who knows which prompts produce hallucinations and which ones don’t, who has been using these tools for hundreds of hours, has more practical literacy than the executive deciding what the policy should be. And the executive often hasn’t sat down and personally used the tool past a couple of curious afternoon sessions.

That’s the real problem with the “more discussion, more stakeholders, more alignment” reflex. Adding people to the conversation doesn’t add competence. It adds a room full of leaders who all share roughly the same incomplete picture of the tool, who then collectively write a policy that the team can immediately tell was written by people who’ve never used it. The policy gets routed around inside a week, not because the team is malicious, but because the policy is naive, and naive policy is friction without protection.

The honest version of “we need to talk about AI in this org” usually starts with the leader admitting they’re 12 months behind their own people. That admission is the most expensive sentence in the room. It’s also the only one that gets anything moving.

Share

Two moves that actually work

So what do you do instead? Two moves. I’d give you a long list, but two is what a leader can actually do this month, and a list of ten is the same as a list of zero.

Move one: leader literacy before team policy. Before you write a policy about a tool, you personally use that tool for at least four hours of real work. Not a demo, not a vendor walkthrough. Pull up your own deliverables and put the tool through them. After four hours, you’ll know things you didn’t know. You’ll have a list of failure modes you watched it produce. And you’ll have a feel for where it’s strong, where it lies, where it needs supervision. Then you write the policy. The policy will be shorter, sharper, and the team will recognize within two paragraphs that someone who actually used the tool wrote it.

Move two: a three-tier risk sanctioning system. Three buckets, posted somewhere visible.

• Green: anything goes, no disclosure needed. Grammar polishing, formatting cleanup, and summarizing an email thread for personal use. Use what you want, no tracking.

• Yellow: disclose what you’re using, no approval needed. Drafting documents, summarizing research, anything that gets human review before leaving the team. Light disclosure in the doc or the project tracker.

• Red: explicit approval before use. Anything touching client data, legal exposure, financial figures, or anything externally facing that won’t get another human pass. Approval, sourcing, named reviewer.

Three categories, posted on a wall. That’s the whole system. It removes the “ask permission to breathe” problem that kills sanctioned adoption, and it puts real protection where real protection is needed.

The parenting version

Here’s the analogy I keep coming back to. I have a seven-year-old and a two-year-old. In about eight years, my older one is going to show up at the dinner table using AI tools I don’t fully understand yet. And I’ll have the same two failure modes that show up in your conference rooms. Option one, I get excited. “She’s so smart, look at her using these tools!” and she stops bringing the harder questions to me. Option two, I panic. “You’re not allowed on these tools without my approval,” and she just uses them in her room with the door closed. Either way, I lose the conversation that actually matters.

The only version that works is me doing the work now, before she gets there, so I’m literate enough to be useful when the real conversation shows up. That’s the same job you have as a leader. Same playbook, lower stakes.

Where this lands

So here’s where I’d land this. The shadow AI in your org isn’t a technology problem you can policy your way out of. The team is bypassing you because at some point, you signaled you weren’t a safe place to bring the truth. That signal happened in a meeting you don’t remember, in a reaction you didn’t think mattered, in a hallway conversation where someone tested the waters and you fumbled the response.

The fix is slower than installing a new approval workflow, because you’re working on a relationship, and relationships don’t respond to policy memos. That work starts with literacy. It continues with tier systems that don’t humiliate people for using tools. And it ends with the leader who can sit across from a junior associate and say, “show me what you’re actually running, no consequences, I just want to learn.”

The team you’re afraid to ask is the team you’ve already lost.

When was the last time you asked one of your people to show you exactly what AI they’re using, with no policy consequences attached? Reply in the comments. The honest answers will tell you more about your team than any audit will.

About the author

is an Executive AI Coach for leaders at small and mid-sized businesses and nonprofits. 1:1 coaching, team workshops, and AI strategy work built around amplifying what your team is already good at. Creator of the AI Leadership Triad. He writes Leadership in Change.

If this piece landed, the deeper version of this work shows up weekly in Leadership in Change, a free newsletter for leaders navigating AI without losing their teams.

SEO Metadata

• Meta title (≤60 chars): Half Your Team Is Using AI. You Don’t Know Which Half.

• Meta description (≤155 chars): Shadow AI is spreading in your org because both your natural reactions, excitement and panic-policy, train your team to hide. Two moves that fix it.

• Primary keyword: shadow AI

• Secondary keywords: AI policy, AI adoption, leader literacy, AI governance, shadow IT

Closer

Thank you, Joel!

This piece lands where mine deliberately stops. Structure without trust is a form teams route around in a week. Joel names exactly why, and the three-tier sanctioning system he offers is the simplest operational bridge I have seen between “we need a policy” and “we need people to actually follow it.”

If your team is already using AI and you are not sure how honestly they would tell you about it, that is not an audit problem. It is a relationship problem. Joel’s newsletter, , is where that conversation continues.

And if the next AI mandate is already moving toward your team, I built the AI Intake OS Toolkit for that exact moment.

It is a multi-page field guide for product leads, delivery leads, and anyone who has watched an AI pilot quietly become a permanent obligation. Inside, you get ready-to-use scripts for introducing the decision map to executives, peers, and your team; a five-field charter that forces every experiment to prove it is ready before work begins; a conservative financial argument you can forward to a VP without embarrassment; and one hard rule that stops zombie pilots before they consume a sprint.

Pick it up thirty seconds before the mandate hits, and you will know what to say, what to document, and what decision to leave the room with.

Regards,

Mark 👋 (and thanks to !)

AI Intake OS Toolkit

290KB ∙ PDF file

Download

The AI Intake OS Leader’s Toolkit gives product, delivery, and executive teams a practical front door for AI requests before pilots quietly become permanent obligations. It includes a live-use Decision Map, meeting protocol, communication scripts, experiment and commitment charters, risk-screening gate, override record, and quick-reference intake record so teams can classify requests, name owners, document tradeoffs, and decide whether to approve, escalate, or park the work. The value is simple: move faster on AI without letting urgency outrun judgment, ownership, or governance.

Download

Previous:

Leadership in Change

3 Structural Failures Behind Every Failed AI Pilot

TL;DR: Most AI pilots fail for three structural reasons that existed long before AI: mandate pressure that bypasses intake discipline, decision moments that do not survive the room, and intake systems that treat every request as equally urgent. Guest writer…

Read more

a month ago · 25 likes · 13 comments · Joel Salinas and Mark S. Carroll

More Content to Discover:

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

In Part A, a visible warning sat in an incident channel for fourteen days while the room assumed someone else owned it. We named that failure an Orphaned Alert and showed how acknowledgment fakes ownership, how reasonable people build the broken route, and why the failure stays invisible from above.

The local cost of a broken route

The cost language in this article is local and illustrative. I am describing estimate categories a team can adapt using its own labor rates, timelines, and remediation data. The point is not that every team pays the same amount. The point is that the labor cost of a broken route usually hides inside normal work until someone traces it.

Three local cost categories tend to surface when you trace a broken route backward.

Bystander Burn is the coordination time multiple people spend seeing, monitoring, or briefly investigating an unowned warning.

Investigation Tax is the duplicated effort that appears when the first investigation does not become a documented handoff.

Compounding Rework is the extra cleanup and remediation that accumulates when a known problem sits unresolved while downstream work continues building on top of it.

I have traced this kind of cost through an Azure DevOps board. A work item was marked blocked, comments were added, and the assignee was visible, so the board looked like it had captured the risk. But the person assigned to the work did not own the decision that would unblock it. Over the next week, the item appeared in standup, backlog refinement, a review conversation, and a stakeholder update. Each time it generated questions nobody could close.

The conservative cost: two developers spending roughly three hours each checking the dependency, a delivery lead spending two hours chasing status, a product owner adjusting expectations, and a lead reconstructing who could actually make the decision. Roughly eleven to twelve hours before counting the eventual fix.

Multiply those hours by your team’s loaded rate and the math becomes local, specific, and hard to ignore. A $500 Day 0 fix quietly became a multi-week remediation because the signal had a channel but not a route.

The Day 0 fix would have been boring: name the decision owner, confirm the authority, and set a twenty-four-hour escalation rule. Boring would have been cheaper.

That is why the math should stay local. A team does not need to claim that every minute of delay costs some theatrical number borrowed from a vendor deck. The team only needs to ask what the delay cost here, in this workflow, with these people, this cleanup, and this missed handoff. The route did not save time. It moved the cost to more calendars.

Trace the route, not the person

Ownership language turns dangerous when handled badly. “When did this become someone’s job?” is a useful question when the team is tracing the route. The same question becomes politically unsafe when the team is hunting for a person to blame.

A blameless review does not mean no one is accountable. It means the review inspects system conditions, handoffs, and authority gaps before inferring personal failure. Accountability still matters. But accountability works better when people know what they owned, what authority they had, and where the next move should have gone. The safest postmortem questions are route questions: where did the signal first become visible, what happened between visibility and explicit ownership, and what timer or escalation rule should have moved the signal when ownership remained unclear?

I have facilitated retrospectives that handled the same kind of failure in completely different ways. In the weaker version, the room decides the problem was “communication.” Nobody says “we are blaming someone,” but the questions start orbiting the person closest to the miss. The retro ends with an action item like “communicate sooner,” and everyone nods because nobody wants to argue with a virtue. The weeks afterward reveal the real effect: people become more careful, not more transparent. They bring screenshots, soften risks, and turn updates into little legal exhibits for the defense. That is not learning. That is workplace theater with better bullet points.

The better reviews feel different in the first five minutes. They still ask hard questions, but the questions follow the route: where did the signal appear, where did ownership become assumed, who had authority, and what rule should have moved the warning when authority was unclear? When a team leaves with a named receiver, a return date, and an escalation rule, the next few weeks look different. People have something better than a reminder to be brave. They have a path.

Share

The rebuild: from signal to named owner

Most incident frameworks assume ownership already exists. This one exists to create it.

The rebuilt route does not start with another channel. It starts with a lightweight aid that helps a team move a visible warning into explicit ownership. That is why I am giving away the Incident Triage Decision Aid with this article.

The aid asks four routing questions.

MTTO (time from first visible signal to explicit ownership). Use as a local learning metric, not a personal scorecard. This is the gap the graveyard dashboard was hiding.

Run the Part 1 warning through the aid, and the route becomes visible.

In practice, the first two branches work together: classify the warning and clarify its urgency. When severity is unknown, the correct answer is not drift. It is rapid clarification. The third branch names the owner with authority, because a name without authority creates false ownership. The fourth branch sets the escalation timer and destination, because ambiguity needs an expiration date.

For the inference pipeline warning in Part 1, the rebuilt route might look like this: signal type, model inference degradation; severity, unknown but customer-impacting potential; owner, on-call platform lead with authority to pause the related rollout or escalate; escalation timer, ownership and next action explicit within one hour, otherwise escalate to the engineering manager. That is not a heroic intervention. That is four questions asked before the channel swallows the warning.

Do not use the aid as a replacement for formal incident command in major or regulated response structures. And do not use it to assign fault after the fact. A named owner is a coordination mechanism for the next move, not a retroactive fault label.

I have not always seen the full version of this work as cleanly as I would like. What I have seen are pieces of it work: a blocker policy that forced escalation after a day, a readiness checklist that caught an unowned dependency before sprint commitment, a working agreement that said a repeated warning gets a named owner before the meeting ends. Each one worked for the same reason. It moved the decision out of personal courage and into a shared route. Many warnings drift for social reasons, not technical ones. Nobody wants to overreact, interrupt the wrong person, or turn a weak signal into a fire drill. A lightweight routing mechanism gives the team permission to act without making someone perform urgency. The tool works when it is small, visible, trusted, and attached to a moment the team already inhabits.

Subscribe now

Run the five-warning field test

Do not start by redesigning your entire incident process. Start with the next five credible warnings that appear in your workflow. For each one, track when the signal first became visible, when acknowledgment happened, when a named owner with authority claimed it, when the next action became explicit, and whether an escalation timer and destination existed.

Then ask: which warning had the longest gap between visibility and ownership? That is your first route repair. That small exercise will show whether your team has a visibility problem, an acknowledgment problem, an ownership problem, or an authority problem. Those are not the same diagnosis, and they do not require the same repair.

Download the Incident Triage Decision Aid with this article. It is the routing logic this episode diagnoses as missing. Pin it in Slack, add it to the runbook, or print it for the room. The diagnosis is free because a visible warning still needs a route, and the route should not start behind a paywall. Paid subscribers help fund the next round of practitioner tools, field guides, and Route Rebuilder artifacts.

Incident Triage Decision Aid

67.4KB ∙ PDF file

Download

The Incident Triage Decision Aid helps teams route a visible warning to a named owner before drift begins, using four gates: signal type and severity, named owner with authority, escalation timer and destination, and route confirmation. It includes a worked example showing how an inference pipeline warning moves from first visibility to explicit ownership, plus copy-paste versions for Slack, Jira, tickets, runbooks, and wikis. Use it when a credible warning lacks an obvious next move, because Part 1 diagnoses the broken route, while this Part 2 premium tool helps prevent the next Orphaned Alert in real time.

Download

The moment that started this series was quieter than I wish. Nobody slammed a table. Someone wrote “communicate better” on a retro board, and I remember thinking: we have written this before. Not this exact team, not this exact issue, not this exact room, but the same conclusion wearing the same harmless little sweater.

The people in the room cared. They had worked hard. They wanted the next blocked handoff to go differently. But the action item was asking human beings to remember harder inside a route that still had no owner, no timer, and no authority path. That was when I realized the work was not to lecture teams about communication. The work was to rebuild the route.

That realization also sits at the heart of my upcoming book, Collaborate Better. The book is built around the same conviction behind Route Rebuilder: collaboration does not improve because people care harder inside broken systems. Collaboration improves when teams build clearer routes for trust, ownership, decisions, and action. You can learn more at CollaborateBetter.us.

Route Rebuilder starts here because this is the smallest route failure with the biggest consequences. A warning appears. People see it. Everyone assumes the system is working because the channel is active.

But activity is not movement.

The first route to rebuild is the one between signal and ownership.

Because unread messages do not bury bad news.

Unowned warnings do.

P.S. Pull one warning from your last incident review or retro. Ask four questions: When did this become someone’s job? Did that person have authority? Was there an escalation timer? Where should the signal have gone next? If nobody can answer quickly, run it through the Decision Aid before the next review. Then reply and tell me what you found. I read every one.

Next:

Next in The Route Rebuilder: The Route That Made Ownership Optional, where a handoff became a gap when nobody named a receiver.

Citations and Research Binder

3.78MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Route Rebuilder Episode 001, Part B: The Rebuilt Route, along with the article’s local cost language, Part B infographics, Incident Triage Decision Aid, and closing half of The Route That Buried Bad News. It ties the article’s key claims to admissible evidence, separates practitioner tools from formal research, and defines the limits of the rebuild argument. The binder’s core claim is simple: once a visible warning has been diagnosed as an Orphaned Alert, the next step is not more vague communication. The next step is route design. The research layer supports the article’s careful use of local cost modeling through Bystander Burn, Investigation Tax, and Compounding Rework. These are practitioner cost categories, not universal financial benchmarks. The organizational layer draws from research on role clarity, authority, escalation, psychological safety, voice behavior, postmortem learning, coordination failure, cognitive load, and decision support under pressure. The tool layer supports the Incident Triage Decision Aid as a lightweight routing mechanism that helps teams classify signal type, clarify severity, name an owner with authority, and set an escalation timer before ambiguity becomes drift. The binder also defines the guardrails for Part B. The Incident Triage Decision Aid is not a replacement for incident command, root-cause analysis, compliance procedures, or formal safety protocols. MTTO, Mean Time to Ownership, is treated as a local learning metric, not an established industry standard or personal scorecard. The cost examples are illustrative local modeling, not claims that every broken route produces the same financial impact. The result is a decision-grade evidence pack for leaders, product teams, SREs, Agile coaches, and delivery groups that need to trace the cost of a broken route, protect accountability from becoming blame, and rebuild the path between visible signal and owned action.

Download

Previous:

More Content to Discover:

Leadership in Change

3 Structural Failures Behind Every Failed AI Pilot

TL;DR: Most AI pilots fail for three structural reasons that existed long before AI: mandate pressure that bypasses intake discipline, decision moments that do not survive the room, and intake systems that treat every request as equally urgent. Guest writer…

Read more

a month ago · 34 likes · 21 comments · Joel Salinas and Mark S. Carroll

AI can expand solo output. The burden of review, judgment, and accountability does not automatically disappear with it.

👋 Welcome to my paid subscriber-only edition of Empathy Engine (🔒 Leader’s Dispatch). Each week I build evidence-informed tools for product professionals, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

A few days ago, the first draft of this article went through the kind of AI feedback loop that would have sounded absurd not long ago. Grok, Gemini, Perplexity, Copilot, Claude, and ChatGPT all gave me useful notes, and most of them agreed on the same thing: the piece worked, but it was carrying too much. That did not make the decision for me. It gave me more signal, then left me with the harder question of what to cut without cutting the soul out of the piece.

The code ships, the support draft appears, the content calendar fills itself in, and the research summary lands in your inbox before coffee has finished pretending to be breakfast. For a moment, the dream looks real.

One person can suddenly move with team-speed output. No standups, no salary burn, no misunderstandings disguised as process. Then the customer escalation arrives. Not the easy one, not the one the support agent can answer from the knowledge base, but the weird one where the customer is technically wrong, emotionally right, and possibly still worth saving.

The stack has three suggested replies. All of them are fine. None of them are yours. The work comes back to you, not because the AI failed exactly, but because the system cannot fully own what happens next.

You can automate the draft, the summary, the first pass, the second pass, and the polite version of the thing you were absolutely not going to say in the first draft. What remains is judgment. What remains is taste. What remains is the part where someone has to decide what matters, what is good enough, what can go out the door, what should be held back, and what kind of company this is becoming.

That is the moment this series is about. Not the fantasy that AI does not help, because AI absolutely helps. Not the scolding lecture that solopreneurs need to grow up and hire people, because they do not. Not the tired startup sermon where every problem is solved by raising money, adding headcount, and hiring a person with “growth” in their title who says “motion” too often.

The same business, viewed from two sides of the same day. One side hums. The other side waits for you.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

The solo win is real

The AI-solopreneur story did not come out of nowhere. For years, starting a serious business meant eventually running into the wall of labor. Someone had to write, code, design, answer customers, analyze data, build the landing page, make the deck, and do the dull work nobody posts about because the dull work makes entrepreneurship look suspiciously like paperwork in a hoodie. AI changed that math.

Consider what one person can now move in a single morning. Draft the page. Sketch the workflow. Analyze the interview notes. Build the prototype. Generate the first support response. Rewrite the announcement. Test five positioning angles. Sometimes that happens before lunch on a Tuesday. Sometimes it happens before brushing teeth, which is a separate governance issue. Either way, the leverage is real.

A solo founder can now produce work that used to require a small team, or at least a small team’s worth of meetings. A creator can turn one idea into a newsletter, a podcast script, a short video, a product outline, a launch note, and a reusable asset. A no-code builder can wire together a business that would have looked absurdly ambitious ten years ago. None of that should be waved away.

Solo is not a failure state. Solo can be a deliberate design choice that protects speed, simplicity, margin, autonomy, and focus. Plenty of founders should stay solo longer than old startup advice would suggest. Some should stay solo indefinitely.

This is not a universal arc. Some AI-enabled solo businesses work beautifully for years without hitting the particular wall this series describes, and there is nothing deficient about that.

There is nothing inherently noble about adding people too early. Early teams can create drag, cofounder relationships can become expensive marriages with worse furniture, contractors can execute the brief while missing the context, and employees can require management before the business can afford management. This series is not an argument against the solo builder. The solo builder won something important.

The question is what happens after the win. Once output gets easier, the unresolved parts of the business become more visible. Those unresolved parts are not always solved by another tool. Sometimes they are not even output problems anymore.

Output stopped being the obvious bottleneck

The old bottleneck was visible. You did not have enough hands, enough hours, enough attention, or enough calendar to move everything forward. The work sat in the queue because one person had one body, one calendar, and a deeply unreasonable relationship with browser tabs. Then AI entered the workflow, and the constraint shifted from capacity to something harder to name.

The draft appears, and now someone has to decide whether the draft is true. The prototype works, and now someone has to decide whether it solves the right problem. The automation fires, and now someone has to notice when the automation is producing polished nonsense. The agent answers the customer, and now someone has to decide whether the answer protects trust or merely resolves the ticket.

The work can leave your hands before the consequences leave your desk

This is what practitioners sometimes call the judgment bottleneck. Not as a formal academic category, and not as a universal law. The phrase is simply a practical way to name a familiar feeling: a business can produce more than ever, and yet the hardest calls can still route through one person.

The supervision tax

The founder is not writing every support reply anymore, but the founder is reviewing the support reply. The founder is not drafting every article from scratch anymore, but the founder is checking whether the article still sounds like a human with a point of view.

The founder is not manually moving every lead through the workflow anymore. Instead, the founder is checking whether the workflow broke because one tool changed its API, another tool changed its pricing, and a third tool has decided, spiritually, to become worse. This is not a reason to reject the tools. This is a reason to tell the truth about what tools move around.

The same thing happened with the iceberg graphic I made for this article. The image captured the idea beautifully: everyone sees the clean output above the waterline while the founder carries the judgment underneath. But when I read the labels closely, the AI had produced sentences that were almost right and therefore dangerous. They looked professional from a distance, but a few words were garbled enough to make the whole artifact less trustworthy.

Sometimes the burden shifts into monitoring, routing, debugging, reviewing, and deciding when the system has crossed the line from efficient into technically functional but spiritually suspicious.

Research on AI-assisted work points to the same constraint: faster tools do not remove the need for human validation, oversight, and accountability. The gains in output are real. The review burden can remain.

Share

Every business has a place where ambiguous work goes to become a decision. In a larger company, that place might be a product lead, a manager, or a committee that multiplies until the original question dies of natural causes. In a solo business, that place is usually one person. Quick decisions are one of the great joys of working solo. As volume and complexity grow, some of those decisions get heavier. Should this customer get a refund? Should this feature ship even though the workflow technically works but feels wrong? Should this AI-generated content go live if the facts are accurate but the tone is flat? These are judgment calls, and judgment does not become lighter simply because the first draft arrives faster.

Three things tend to show up together after the AI stack starts working. More output. More decisions that need reviewing. More things to supervise. The first one often gets automated. The other two tend to stay. That is the pattern.

AI did not create that accountability. AI revealed where accountability already lived. That is when some founders start noticing the difference between being free and being unsupported.

The false binary

The usual advice gives founders two bad buckets. One says stay solo and stack harder. The other says grow up and hire a team. Each protects something real. Each carries a risk the advice tends to skip over.

Read more

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

Episode Zero argued that bad news is often buried by a broken route, not by a lack of visibility. This is what that looks like before anyone knows they are inside the failure.

A senior engineer flags an intermittent failure in the inference pipeline. The warning goes into the incident channel, which already has 847 unread messages. Someone reacts, someone says something brief, and the day moves forward. The warning sits in the channel with a timestamp and an emoji, which in many organizations can feel like proof that the system is working.

The team enters the postmortem. Someone shares their screen and scrolls back through the channel. The original warning is right there, with all the clarity that only hindsight provides. The room does not go quiet because nobody saw the signal. The room goes quiet because multiple people saw the signal, and nobody can say when it became someone’s job.

I have had my own version of that moment. In a standup or review, someone would mention a shaky dependency or a flaky environment — significant but not yet urgent. I would hear it, recognize the shape of it, and let the meeting move forward because I was focused on the timebox or the next planning commitment. I was not being careless. I was doing the thing competent people do in busy systems: deciding, often unconsciously, that a visible problem must already belong to someone closer to it.

When the issue resurfaced later, the realization was not “I caused this.” The realization was worse: I was one of the people who saw the signal and accepted visibility as enough.

I call that failure an Orphaned Alert. An Orphaned Alert is a visible warning that receives attention but never forms into explicit ownership. The phrase is a practitioner metaphor, not a formal industry term, and that distinction matters. The goal is to make a pattern easier to discuss, not to pretend the label arrived with a certification and a conference badge.

A warning does not need to be hidden to get buried. Sometimes the warning is right there, sitting in the same channel where everyone claims the team is keeping an eye on things. The dangerous part is not silence. The dangerous part is a noisy room where enough people can see the problem that everyone assumes someone else must be moving it forward.

For readers who want the receipts, the evidence notes and source citations for this article are compiled in a research binder linked at the bottom of this piece.

The reporting channel was built to receive warnings. Nobody built it to route them. Receiving and routing are different jobs. The channel only ever had one of them.

Receiving is not routing

Receiving a signal means the warning arrived somewhere people can see it. Routing a signal means the warning has moved to a named owner with authority for the next move. Those are different operating states, and confusing them is how a busy incident channel becomes a very polished waiting room for bad news.

The broken route looks like this: signal → channel → acknowledgment → assumption → drift → postmortem.

The rebuilt route does something different: signal → named owner → decision → next action → escalation timer.

The broken route often feels active because people are reacting, checking, discussing, and assuming. The rebuilt route feels less dramatic because it asks four plain questions: what kind of signal is this, how severe is it, who owns the next move with authority, and when does escalation happen if ownership remains unclear? Those plain questions are the difference between “everyone saw it” and “someone is driving it.”

Share

The Ack Trap

The Ack Trap happens when acknowledgment creates the appearance of control. A responder clicks acknowledge, a teammate drops an emoji, or someone says “looking into it,” and the system relaxes. The warning has reached attention, but attention is not the same thing as ownership.

A useful acknowledgment tells the team that someone has seen the signal, and that can reduce duplicated noise in the first few minutes. The problem begins when acknowledgment becomes a stopping point instead of a handoff point. Without a named owner, authority to act, and an escalation path if the issue stalls, the acknowledgment becomes operational wallpaper. Everyone sees it, everyone feels slightly safer, and the warning keeps aging behind the scenery.

I have been fooled by “we’re tracking it.” In a dependency conversation, that phrase sounds wonderfully responsible — as if the issue has been escorted into a mature operating system with a clipboard and sensible shoes. I felt reassured. I moved the conversation forward because I did not want to micromanage the team that supposedly owned the work. The problem resurfaced later as a blocked story or a review conversation where the same concern had somehow become new again. “Tracking” had meant awareness, not ownership. Nobody had named the next decision, the person with authority, or the timer for escalation. The issue had not been routed. It had been given a place to sit.

Alert fatigue belongs in this conversation because noisy channels make weak handoffs easier to miss. But alert fatigue and ownership failure are not the same problem. Alert fatigue can increase the chances that a weak handoff gets buried in noise. It does not explain why a visible, credible warning never became a named person’s next move. A quieter channel without ownership rules is just a tidier place for bad news to wait.

The architects of the broken route

This is not a validated taxonomy. It is a practical lens for inspecting how a broken route gets built by reasonable people doing reasonable things. Some roles build intake — they give signals a place to land without building a path for the signal to travel. Some roles monitor volume without holding the authority to halt work or redirect priorities; they can see the warning but may not be empowered to move it. And some roles, especially leaders reading from the outside, interpret quiet or a lack of formal escalation as evidence of stability — when from the outside, no escalation can look like no problem, especially when leaders are trained to read exception reports as reality. When visibility exceeds authority, the route is already fragile.

I have been both the builder and the monitor in this pattern. As a consultant, I have helped teams make work more visible: cleaner boards, clearer ceremonies, better intake, more explicit blockers. That work mattered. But I have also learned that better visibility can seduce you into thinking you have built a better route. I could see impediments, hear dependency risks, and notice when the same warning kept reappearing in different meetings with slightly different nouns. I could ask better questions and help the team name the risk, but I did not always have the authority to change priorities or force a cross-team decision. The system had given the role visibility and responsibility language, but not enough authority to make the route move. Changing the actor would not fix that script.

A graveyard dressed as a dashboard

This is the turn.

The system is optimized for signal volume, not signal routing. High message counts look like high engagement. High engagement looks like a healthy reporting culture. A busy dashboard can look like control. A thread full of reactions, status fragments, and unread-message counts can create the impression that the team is processing risk when the team may only be stacking risk in chronological order.

That illusion is where this article’s central failure hides. The channel did not fail because it was silent. The channel failed because it was active enough to look like a route while functioning only as a destination. The activity was real. The movement was not.

I have seen this happen on an Azure DevOps board. The work items had assignees, tags, comments, and enough activity history to make the board look alive. Nothing looked abandoned. Then the question landed: “For the blocked items, who owns the next decision?” For a few seconds, everyone looked back at the screen as if the answer might be hiding in a field we had not expanded yet. That silence did not mean people were careless. It meant the dashboard had been answering a different question. It could tell us that an item existed, that someone had touched it, and that the status had changed. It could not tell us whether the next decision had an owner with authority. The dashboard still looked green, but the room no longer believed it.

Some teams find a local metric useful here. I use MTTO — Mean Time to Ownership — as a practical lens for one specific question: how long did the signal remain visible before explicit ownership formed? MTTO is not an industry-standard SRE metric. It is a local operating measure I use to inspect the interval between visibility and ownership. Used carefully, that interval reveals the route gap. Used carelessly, it becomes a tool for scoring individuals instead of inspecting systems.

MTTO does not ask how fast someone clicked acknowledge or how long the fix took. It asks how long the signal lived in the gap between those two moments.

MTTA, Mean Time to Acknowledge, can be useful but can mislead when used alone. Acknowledgment can look like progress while the route underneath remains empty. MTTR, Mean Time to Resolve, can flatten the timeline so much that the team loses sight of where the delay actually began — and the expensive rework that accumulated in the gap. MTTO does not replace either metric. It sits between them and asks the question neither was designed to answer: when did visibility become ownership?

Subscribe now

Here is the exercise I wish I had run when I was trying to be a good facilitator and accidentally became a good witness instead. I kept the meeting moving, but I did not make sure the signal could move. These four questions are the pause I did not take.

Quick Route Check

356KB ∙ PDF file

Download

The Quick Route Check is a 5-minute diagnostic you can use on one warning from your last postmortem, retro, or incident review to see whether the issue was merely visible or actually routed. It helps you identify where the route broke: detection, ownership, authority, or escalation timing. Use it to spot an Orphaned Alert without turning the review into blame theater, so Part 1 gives you an immediate way to inspect the failure before Part 2 rebuilds the route.

Download

Quick route check

Pick one warning from your last postmortem, retro, or incident review and ask four questions:

Where did the signal first become visible?

Who owned the next move?

Did that person have authority?

What timer should have escalated it?

If the team cannot answer those four questions quickly, the problem was not just communication. The route was missing.

That is the failure this series is built to repair. The warning was visible. The channel received it. The room acknowledged it. The route never formed.

This is also why I am writing Collaborate Better. The book is built around the same conviction behind Route Rebuilder: collaboration does not improve because people care harder in broken systems. It improves when teams build clearer routes for trust, ownership, decisions, and action.

Once you can see that pattern, the next question becomes harder to avoid: what does the route need to make the next warning move?

Part 2 answers that question. We will trace the local cost of a broken route, then rebuild the path with the Incident Triage Decision Aid: signal type, severity, named owner with authority, escalation timer, and MTTO as a local learning lens.

Next: Part 2 — The Rebuilt Route

Citattions and Research Binder

3.78MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Route Rebuilder Episode 001, Part A: The Orphaned Alert, along with the article’s diagnostic language, Part A infographics, and the opening half of The Route That Buried Bad News. It ties the article’s key claims to admissible evidence, separates practitioner metaphors from formal research, and defines the limits of the argument. The binder’s core claim is simple: a warning does not need to disappear to become buried. In many organizational systems, the warning is visible, acknowledged, and even discussed, but never routed to a named owner with authority for the next move. The research layer supports the article’s distinction between receiving and routing, acknowledgment and ownership, alert fatigue and ownership failure, and visibility and accountable action. It treats The Orphaned Alert, The Ack Trap, and A Graveyard Dressed as a Dashboard as practitioner frames, not formal industry constructs. The organizational layer draws from research on role clarity, psychological safety, voice behavior, team coordination, incident response, cognitive load, decision-making under pressure, and postmortem learning. The metric layer defines MTTO, Mean Time to Ownership, as a local operating lens for inspecting the interval between first visible signal and explicit ownership, not as an industry-standard SRE metric. The binder also defines the guardrails for Part A. The Orphaned Alert is not a blame label, performance tool, compliance instrument, or claim that every incident can be prevented. The Architects lens is not a validated taxonomy, but a practical way to inspect how reasonable people can build broken routes without intending to. The result is a decision-grade evidence pack for incident reviews, retrospectives, dependency conversations, sprint reviews, and leadership discussions where the work looks visible, the channel looks active, and the dashboard looks green, but nobody can answer the route question that matters most: when did this become someone’s job?

Download

Previous:

More Content to Discover:

Why your hybrid solo business stops scaling when coordination grows faster than leverage

👋 Welcome to my paid subscriber-only edition of Empathy Engine (🔒 Leader’s Dispatch). Each week I build evidence-informed tools for product professionals, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

Here’s the final episode of The Hybrid Solopreneur, my six-part series about what happens when serious solo operators stop treating AI as a magic employee and start treating it as leverage that must be governed.

In Episode 1, I separated the fantasy of cheap AI leverage from the hidden orchestration tax.

In Episode 2, the stack reassigned management directly back onto the founder.

In Episode 3, completion theater produced outputs the client could see through.

Episode 4 redesigned the role from doer to director.

Episode 5 defined and defended the human premium.

Episode 6 is the capstone: what can this whole system safely govern before leverage bends into fragility?

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

The automations still fire. The dashboards still glow. The agents still produce drafts, summaries, plans, replies, and polished little rectangles of confidence. Nothing looks broken enough to panic. That is what makes the problem so slippery. The system is still producing output, yet you are quietly becoming the person who checks, fixes, reroutes, approves, rewrites, and recovers everything the system cannot safely finish.

At first, that arrangement feels like leverage. Then it starts to feel like oversight. Eventually, it begins to feel like a job you accidentally hired yourself to do. You built a hybrid solo operation with amplified reach, but somewhere along the way, the stack turned you into its unpaid integration layer.

This is the final trap in the hybrid solopreneur journey. The early promise is real. AI gives a solo operator more reach, more drafts, more speed, more experiments, and more output. You can do things that once required an assistant, a research analyst, a junior copywriter, a coordinator, and one highly specific person who somehow remembers where the client onboarding template lives.

Then the stack grows. One tool becomes four. Four tools become a workflow. The workflow becomes a chain. The chain becomes an operating system. And the operating system requires a manager. The problem is not that AI stops being useful. The problem is that usefulness does not equal governability.

Your stack can keep expanding while your ability to understand, verify, recover, and trust it levels off. That widening gap is the Orchestration Ceiling.

If your AI stack is genuinely saving you time, you should not need to check it constantly. If you are rereading everything before it goes out, fixing outputs more than using them, nervous about what ran overnight, or adding tools to monitor the tools that were supposed to reduce the work, you are not scaling. You are supervising. The stack is not broken. Worse, the stack is plausible. It produces just enough value to keep you maintaining it.

The ceiling is not output. The ceiling is governability.

Most conversations about AI leverage are still trapped in output math. How many drafts can I generate? How many leads can I enrich? How many workflows can I automate?

Output can scale faster than oversight. Automation can begin producing more things than one person can meaningfully inspect. Toolchains can generate more movement than the business can absorb. The stack does not become risky only when it fails. The stack becomes risky when it produces faster than your judgment can keep up.

This is why the phrase “AI leverage” can become misleading. Leverage sounds clean. Push here, move the big thing over there. Real hybrid work is a system, and systems have dependencies. Dependencies have failure modes. Failure modes have recovery costs. Recovery costs usually land on the person who least has time to absorb them.

In a solo business, that person is you. The practical limit is not whether the AI can produce more. The practical limit is whether you can still supervise, verify, recover, and calibrate trust across the work it produces. Once that limit is breached, more output no longer feels like scale. More output feels like more surfaces to inspect.

The Monday morning test

Picture the scene. You sit down Monday morning expecting your weekend AI stack to have created leverage. The research agent has gathered sources. The content agent has drafted an outline. The CRM automation has updated leads. The proposal workflow has generated a first pass. The scheduler has queued follow-ups. The dashboard says several things are “complete.”

Then you open the outputs. The research is broad but misses the client’s actual market. The outline sounds polished but points toward the wrong argument. The CRM automation updated the wrong field because one label changed. The proposal is mostly usable, except for the part that makes the client wonder whether you read the brief. The follow-up email is technically accurate and socially cursed.

Nothing exploded. The stack did what it was told. The problem is that what it was told was not enough. Now your Monday morning is gone, not because you did the work manually, but because you supervised the work that was supposed to free you from doing the work manually.

I felt a quieter version of this while building this series. The more useful my AI-assisted content workflow became, the more my role shifted from writer to orchestrator. I had research coming in from multiple models, evidence checks flagging what I could and could not safely publish, infographic logic to place, companion artifacts to keep evidence-safe, and feedback from five different AI critics that I had to grade, synthesize, and sometimes overrule. The stack was helping. No question. But it was also creating a new job: governor of the stack.

That was the moment the ceiling became personally visible. The question was no longer “Can I make more?” The question became “Can I still responsibly govern what this system helps me make?” Every episode in this series was produced inside the same tension it describes. The article you are reading right now is proof of its own thesis.

The four warning signals

There are four warning signals that your AI stack may be crossing from sustainable leverage into fragile complexity.

The first signal is complexity creep. Complexity creep begins when you need a map to understand the map. Your workflow no longer has a simple story. It has tools, agents, prompts, folders, triggers, fallback paths, dashboard views, hidden dependencies, and one crucial connection you set up at 1:13 a.m. with the confidence of a frontier dentist. You cannot explain the system in two minutes, and you cannot change one piece without wondering which other piece will quietly break.

The second signal is oversight strain. Oversight strain begins when review becomes the real job. You are not using the output anymore. You are inspecting it. You are not trusting the automation. You are checking whether it behaved. A little oversight is responsible. Constant oversight is a warning sign that the system has not earned the right to run without you.

The third signal is quality drift. Quality drift is dangerous because the work still looks finished. The document is formatted. The email is coherent. The spreadsheet has rows. The summary has bullets. The deck has a title slide, which is the business equivalent of wearing a tie to a burglary. Yet the output may miss context, flatten judgment, or lose the client’s nuance. Quality drift appears as “completed” work that quietly leaks trust.

The fourth signal is recovery fragility. Recovery fragility is what happens when a workflow breaks and no one besides you can diagnose, repair, or rebuild it. The person who set up the automation is the only person who understands it, and unfortunately, that person is also you. When recovery depends entirely on founder memory and founder availability, the system is not resilient. It is renting space in your nervous system.

When those four signals compound, the human premium starts to erode. The work gets faster, but the offer gets less distinctive. AI can help with assembly, drafting, summarizing, sorting, formatting, and first-pass synthesis. Clients, however, do not pay you only for volume. They pay for judgment, taste, trust, timing, relevance, and knowing when not to say the technically correct thing in a way that makes everyone regret the meeting. When your stack automates too close to the trust layer, your offer may get faster while becoming less defensible. That is not scale. That is dilution.

How the whole season arrives here

Cheap tools became operational load. Automation became management work. “Done” became a quality illusion. The founder had to shift from execution to design. The human premium became the part of the offer worth protecting. The Orchestration Ceiling appears when all of those lessons arrive at once, and the question is no longer how to fix any single workflow but whether the whole system producing those workflows can still be safely governed.

The false solution trap

When hybrid systems start to strain, the first instinct is usually to add. Add another dashboard. Add a monitoring tool. Add a QA agent. Add an observability layer. Add a second automation to check the first automation, then a third automation to notify you when the second automation has lost its will to live.

Share

Adding is not neutral. Every tool brings a maintenance surface. Every automation brings a failure mode. Every agent brings an oversight question. Every dashboard brings a temptation to monitor instead of decide. A serious operator eventually learns that “more” is not a strategy. More can be avoidance. More can be denial with a product tour. The stack does not need expansion. The stack needs boundaries.

Automation debt

I think of automation debt differently from technical debt. Technical debt is the interest you pay on past engineering shortcuts. Automation debt is the interest you pay on fragile workflows that only function because you keep supplying attention.

Automation debt is a practitioner’s term, not a textbook term. It describes what happens when a brittle workflow survives not because it is reliable, but because one person keeps nursing it through each run. A client sends a weird input. A field name changes. A model behaves differently. A prompt misses context. A tool updates its interface. A workflow finishes, but the finish line was drawn in the wrong place.

You pay it in checking time, recovery time, rework, context switching, and the little stomach drop that happens when you realize the system ran while you were not looking. The cost of automation is not just the subscription or API bill. The cost can also show up as supervision time, failure handling, delayed delivery, and trust repair.

Pruning is not retreat

Read more

The Route Rebuilder begins with the moment everyone saw the warning and nobody owned what happened next.

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

The Warning Was There

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.

A senior engineer drops a warning in the incident channel. There is an intermittent failure in the inference pipeline. The channel already has 847 unread messages. The warning lands, someone sees it, and the day keeps moving.

Fourteen days later, the team is in the postmortem, scrolling back through the noise. The warning is right there. Timestamped, visible, and maybe even acknowledged. Nobody can answer the harder question: when did this become someone’s job?

That is where The Route Rebuilder begins. Not with blame. Not with another dashboard. Not with a heroic speech about accountability delivered in the tone of someone who has never had to find a missing Jira ticket at 11:47 p.m.

I have been the person scrolling back through that channel. I remember seeing an alert on a Tuesday afternoon that looked like one of those transient errors that clears itself before anyone has to care. I even remember thinking, “That is odd,” then going back to sprint review prep. When it came up in the postmortem two weeks later, I felt my stomach drop because I knew I had seen it. The worst part was not that I missed it. The worst part was realizing I had quietly decided it belonged to someone else.

If you are skimming:

The signal was visible. The owner was not. That gap is the broken route. This article gives you the language for the series and one question you can use in your next review. If you are short on time, read the next section and the Broken Route Finder box, then skip to Part 1 Begins Here.

The Gap Between Seeing and Owning

A lot of organizational failure hides inside one small assumption: if people can see the signal, then someone must be handling it. That assumption feels reasonable until the postmortem proves otherwise.

Teams often confuse visibility with movement. A dashboard makes the signal visible. A channel makes it discussable. Neither guarantees that the signal has moved to the person who can decide and act. Everyone knows enough to feel concerned. Nobody knows enough to feel responsible. The organization is aware, but the next action is still floating around the room like a ghost with calendar access.

I once sat in a program review looking at a dashboard with every project marked green, yellow, or red. It had dates, categories, dependencies, and a beautiful executive summary. Then someone asked, “Who owns the next action on the yellow items?” The room got quiet. That was when I realized the dashboard was tracking concern, not ownership.

Receiving Is Not Routing

A signal can be a warning, a ticket, a customer complaint, or the quiet risk someone raises before everyone moves on. A route is the path that moves the signal from visibility to a named owner with the authority to act. A broken route is what happens when that path exists in theory but not in practice.

Here is the difference in one line. A signal has not been routed because someone reacted to it, dropped an emoji under it, or said “Good catch.” A signal is routed when someone owns the next move.

The language for this series:

Route: the path from signal to decision to action.

Broken route: when the signal is visible but never reaches a named owner with authority.

Rebuild: a lightweight mechanism that makes the next move obvious. Later episodes will ship one per episode.

Pressure test: the real-world moment that reveals whether the route works when stakes rise.

Here is the broken route in one line:

Signal → channel → acknowledgment → assumption → drift → postmortem.

Here is the rebuilt route:

Signal → named owner → decision → next action → escalation timer.

That single contrast is the lens for this entire series. A route that only works during planning is a hope, not a route.

The Broken Route Finder (Free for All Subscribers)

You now have the vocabulary. The next step is aiming it. Without a diagnostic, most teams default to fixing the loudest problem rather than the most expensive one.

The Broken Route Finder is a one-page diagnostic that walks you through six observable symptoms. The kinds of things that surface in incident reviews, sprint retros, and quiet hallway conversations and helps you identify which type of routing failure your team is living with right now.

Each symptom maps to one of the six episodes in this series. You do not need to read every episode to get value. You need to start with the one that matches your team today.

It takes ten minutes. It requires no preparation, no facilitator, and no meeting about the meeting. Download it, run it before your next review, and pick the symptom that makes you wince. That is your first broken route.

This is a decision-grade diagnostic tool. The kind of artifact that would normally sit inside a consulting engagement alongside a strategy offsite. It is free for every subscriber because the goal of this series is not to gate the diagnosis. The goal is to make sure the diagnosis reaches the people who can act on it.

The Broken Route Finder (Free for All Subscribers)

59KB ∙ PDF file

Download

The Broken Route Finder is a 10-minute diagnostic you can use in a retro, incident review, planning session, or leadership sync to identify which routing failure is costing your team the most right now. It walks you through six observable symptoms, from warnings seen but never owned to AI recommendations becoming decisions without a human owner, then points each symptom to the Route Rebuilder episode that will diagnose and rebuild it. This is the kind of decision-grade worksheet that would normally sit inside a $99.99+ operating toolkit, but subscribers get it free so you can name the broken route before the next review turns into another expensive archaeology dig.

Download

Share

Why Broken Routes Get Expensive

Broken routes rarely announce themselves as strategy problems. They show up as rework, cleanup, firefighting, delayed decisions, and that special corporate ritual where everyone stares at the same old message and pretends the timestamp is not judging them. The bill arrives anyway.

Empirical software engineering research suggests that more than 70% of many systems’ lifecycle cost lands in maintenance and operations, not in the launch week.

That is the long tail where warnings that never find an owner turn into rework, firefighting, and slow drag on the team. The claim is not that broken routes cause all of that cost. The claim is simpler: when signals fail to move early, they often become more expensive later.

I once traced a single unrouted warning through four weeks of downstream work. It had been listed as a minor risk in a weekly status update for a month. The original fix would have been one decision in week one. Instead, the cleanup took two engineers for six days, one QA analyst for three days, a PM rewriting scope, support drafting customer messages, and leadership asking for updates twice a day. We did not save time by waiting. We just moved the cost to more calendars, more Slack threads, and more meeting invites.

This is why the Route Rebuilder starts before the disaster. A route is easiest to repair before the incident, before the escalation, before the customer impact. Once the work has entered the long tail, the team is no longer preventing cost. The team is negotiating with it.

That is also why “we have tools for this” is only half an answer. Tools can capture, alert, assign, and archive. Those are useful jobs. The harder question is whether the organization has a working path from “we can all see this” to “one person clearly owns what happens next.”

This Is Not a People Problem

Broken routes are usually not one person’s fault. Fast-moving teams add tools, alerts, channels, tickets, and dashboards faster than they add clear paths from “I see it” to “I own it.” The result is not apathy. The result is a system full of responsible people surrounded by unclear handoffs.

That is why blame is such a poor repair tool. Blame makes people hide signals, defend themselves, or wait for someone safer to speak first. Blame can produce a name, but a name is not always a route.

I have watched this play out. A manager was pushed out after a delivery miss. The story became that they had failed to coordinate the handoffs. What nobody traced was that the handoffs were never designed. The dependency map was vague, receiving teams had no named owners, and the escalation path depended on personal relationships. The organization changed the actor and kept the script.

A competitor hired the original manager within a month, with a pay increase (which should have been the first clue that the problem was not individual competence). Three months later, the new manager hit the exact same dependency miss. Same teams. Same handoff gap. Different name on the escalation thread. The system did not get safer. It just got more careful about leaving fingerprints.

The better question is not, “Who dropped the ball?” The better question is, “Where did the ball stop moving?” That question changes the room. It points attention away from character and toward design.

A broken route does not mean nobody cared. It means the organization had not yet built a reliable path for the signal to travel. That is a much more useful problem because useful problems can be rebuilt.

If the gap between seeing and owning sounds familiar beyond incident channels (in how teams collaborate, escalate, and make decisions together) that is the territory Collaborate Better was written for. Collaboration is not just people being nicer in meetings. It is the design of the paths people use to notice, decide, and act together. CollaborateBetter.us

From Profit With Proof to Route Rebuilder

Profit With Proof was about pricing what teams usually ignore. Rework. Escalation delay. Predictable churn. Compliance theater.

The Route Rebuilder asks the next question. Once we can see the cost, what route do we rebuild? Naming the waste is useful, but naming the waste is not enough if the same signals keep entering the same broken paths.

That is the shift. Profit With Proof helped expose the bill. The Route Rebuilder follows the signal back through the organization to find the missing path that created the bill in the first place.

Part 1 Begins Here

I built this series because I kept finding myself in the same room with different people. Different company, different tool stack, different org chart. Same silence when someone finally asked who owned the next action. The warning had been there. The ticket had been there. The dashboard had been there. Everyone could point to the moment the signal entered the system, but nobody could point to the moment it became someone’s job.

That pattern costs teams more than money. It costs trust. It costs weekends. It costs good people their confidence because they start wondering whether they missed something obvious (when the truth is worse: the organization had no route for the signal to travel). I built The Route Rebuilder because I am tired of watching teams pay emergency prices for problems they could have handled early.

Part 1 begins back in that incident channel. Fourteen days of drift, one warning that never became someone’s job. The channel received the warning. The route never moved it.

In the first episode, we will look at the route that buried bad news. We will ask how an organization can receive a warning and still fail to move it. And we will begin shaping the first rebuild: a way to move from signal to severity to owner to escalation before the postmortem has to reconstruct the crime scene.

The Route Rebuilder Starter Kit (Free for All Subscribers)

Episode Zero gives you here the lens. The Starter Kit gives you the first set of working tools.

Inside: a Route Diagnostic Card, a Receiving Is Not Routing explainer, five copy-paste Signal Routing Prompts, a Team Discussion Guide, and a Route Trace Template.

Use it in a live conversation, not after the fact. Pick one real signal, trace where it entered, name who owns the next action, and decide whether the route is broken, rebuilt, or still untested.

Everything fits on a single page or screen. No training, no configuration, and no meeting about the meeting.

The Route Rebuilder Starter Kit (Free for All Subscribers)

457KB ∙ PDF file

Download

The Route Rebuilder Starter Kit is an 8-page operating toolkit that gives subscribers a shared language, a Route Diagnostic Card, a Route Trace Template, copy-paste Signal Routing Prompts, and a Team Discussion Guide for turning one visible signal into one named owner, one decision, and one next action. It is designed for real retros, incident reviews, planning sessions, Slack or Teams threads, and leadership syncs, so your team can diagnose a broken route in the room instead of discovering it later in the postmortem. This is the kind of practitioner-grade workflow kit that would normally sell for at least $199.99 as part of a paid operations or facilitation bundle, but subscribers get it free so they can start rebuilding the route before the next warning gets expensive.

Download

The Series Ahead

This series follows the same failure pattern through six different rooms: the incident channel, the ownership handoff, the review gate, the velocity dashboard, the AI workflow, and finally the route that survived pressure.

This is not a postmortem archive or a framework deck. Each episode starts in a room you will recognize and ends with one tool you can use before the next incident.

Each episode will name the broken route, show why the route failed, and ship one practical rebuild you can use in a sprint, retrospective, incident review, or leadership conversation.

Public posts in this series will name the broken route and show why it failed. Paid dispatches go one layer deeper with the practical rebuilds: decision trees, checklists, and operating prompts you can adapt for your own team.

Part 1 ships next week with the first rebuild: the Incident Triage Decision Tree. A one-page decision tool designed to be pinned in your incident channel before the next postmortem writes itself. Paid subscribers receive the Leader’s Dispatch for each episode: the decision tool, the field notes, and the practical prompts designed to help you bring the rebuild into your next real conversation.

At your next incident review or planning meeting, choose one warning and ask out loud: can we trace the route from the first signal to a named owner to the next action?

Subscribe now

P.S. Have you ever found the original warning during the postmortem and realized nobody could name when it became someone’s job? Reply and tell me what you found. I read every one.

Evidence note

The lifecycle-cost figure is based on empirical software-engineering research showing that more than 70% of many systems’ total lifecycle cost occurs during maintenance and operations (IEEE Transactions on Software Engineering, 2023). This is used as a phase-of-cost anchor, not as a claim that broken routes cause 70% of software cost.

The Route Rebuilder · Episode 000

Next: Part 1 of 6 — The Route That Buried Bad News

Citations and Research Binder

3.83MB ∙ PDF file

Download

This article’s Citations and Research Binder supports Episode 000 of The Route Rebuilder, the Broken Route Finder, the Route Rebuilder Starter Kit, and the related infographics. It ties the article’s key claims to admissible evidence, separates practitioner examples from formal research, and defines the limits of the argument. The binder’s core claim is simple: many failures do not begin because nobody saw the signal. They begin because the signal never reached a named owner with authority to decide and act. The financial layer supports the article’s careful use of lifecycle-cost research as a phase-of-cost anchor, not a claim that broken routes cause 70% of software cost. The organizational layer draws from research on psychological safety, voice, blame, role clarity, team coordination, decision aids, incident response, and cognitive load under stress. It also defines the guardrails: The Route Rebuilder is not a blame tool, performance tool, compliance instrument, or promise that every incident can be prevented. The result is a decision-grade evidence pack for retrospectives, incident reviews, planning sessions, and leadership conversations where the work looks tracked, but nobody can answer the question that matters most: who owns the next action?

Download

Previous:

More Content to Discover:

The tool that turns invisible judgment into language you can defend

👋 Welcome to my paid subscriber-only edition of Empathy Engine (Leader’s Dispatch). Each week I build evidence-informed tools for serious solo operators, leaders, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

From naming the premium to defending it

Last week I argued that the human premium is not the output. It is the judgment that makes the output worth using. Useful evidence changes the decision. Impressive noise changes the mood in the room. That’s the distinction. The question that followed was harder: what do you actually say when a client tests it?

A sloppy version of last week’s argument would say: AI makes mistakes. Humans catch them. Therefore, humans are the premium. That sounds comforting. Comfort is not clarity.

Research on automation bias suggests that uncritical deference to AI output causes a systematic drop in vigilance, making the human verification layer a critical business function, not a redundant one. But human review only helps when the human is actually reviewing with critical distance. A person who rubber-stamps an AI draft is not adding judgment. They are adding a warm signature to a machine’s confidence. That is not a premium. That is clerical theater.

The better question is not, “Did a human touch this?” The better question is, “What did the human actually change?” Did they verify weak claims? Did they challenge the framing? Did they adapt the answer to the client’s specific situation? Did they own the final call? That is the difference between symbolic review and meaningful review.

The hard part is not claiming you added judgment. The hard part is being honest about whether your judgment changed the output.

When the client asks about AI

At some point, a client may ask whether AI was used. The wrong answer is a panic monologue. The other wrong answer is a slippery dodge wrapped in eight syllables of “augmentation.” The better answer starts with preparation that happens before the call, when you can explain the role of AI and the role of your judgment without sounding like a kid with their hand caught in the cookie jar.

I had a client once who wanted a clean answer on a roadmap decision that was politically loaded before the meeting even started. The room was the same kind of evidence pile I described last week: every function had data, every function could defend their slice, and nobody had agreed on which evidence should govern the decision.

Before I gave a recommendation, I walked through how I was weighting the evidence. The sales escalation was urgent, but not necessarily representative. The support pattern was less dramatic, but more recurring. The executive commitment mattered politically, but it should not be disguised as customer evidence.

That is where a bad consultant can look more attractive than a good one. A bad consultant sells certainty. A better consultant sells calibrated judgment. Serious product decisions carry variance, tradeoffs, timing issues, and risk. The useful answer was not, “Do the feature” or “do not do the feature.” The useful answer was, “There are three viable paths, and the right one depends on which risk you are most willing to carry.” Certainty feels like leadership until reality starts charging interest.

The breakthrough came when they stopped asking, “Which answer is correct?” and started asking, “Which tradeoff are we choosing, and can we defend it?” That was the real work.

A prompt can generate a draft and simulate confidence. What the client still needs is the convergence of judgment, trust, and taste inside a real context. Judgment decides what deserves weight. Trust comes from knowing what was checked and owned. Taste filters the output into something usable for this client, in this moment, with these consequences.

In practice, that convergence looks different depending on the operator. A fractional CMO curating AI strategy options to protect a retainer is doing judgment work. A solo consultant synthesizing market research into actionable product features is doing judgment work. The task is visible. The judgment layer is what makes the task worth paying for.

Share

That is why the worksheet belongs in the system. Not as a prop to wave at the client. Not as proof that the client should pay more. Use it to clarify your thinking before pressure enters the room.

Read more

Premium artifact: Bus Factor Cost Model (FREE)

The exit interview

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday (formerly Tuesday), I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Previous article in this series: Episode 7 (The Profit Your Sprint Plan Already Spent)

The VP of Engineering thought the meeting would be difficult. Difficult would have been anger, accusation, or a senior engineer finally saying the thing everyone else had trained themselves not to hear. This was worse. The principal engineer sat across from them calm, specific, and already gone.

They had been with the company for six years. Long enough to remember the original architecture conversation, long enough to know why billing behaved differently for three enterprise customers, and long enough to know which deployment script could be trusted only if someone watched the logs like a hawk. They did not say leadership had failed them. They simply named the last eighteen months.

Eleven releases where they stayed late because nobody else knew the critical path. Three incidents that never became incidents because they saw the failure pattern before the dashboard did. A legacy service nobody wanted to own, but everybody depended on. A decision history scattered across Slack, memory, and the phrase, “Ask Priya before you touch that.”

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.

Names and identifying details throughout this article are changed, but the pattern is real. I have seen teams lose “one person” and then discover they had actually lost the release history, the workaround memory, the stakeholder trust, and the unofficial operating manual. The real cost of replacing them was not their salary. The cost was every decision the organization never bothered to make transferable.

Leadership sees one senior employee leaving. The team sees five invisible systems with no second owner. The bill does not begin when the person resigns. The bill begins when the organization lets one person become the route.

TL;DR

Hero mode is not a personality type. It is a system failure that found a person-shaped workaround. The hero makes the system look reliable while making the organization less resilient. The Bus Factor Cost Model turns invisible dependence into a practical, board-safe resilience conversation, using local assumptions rather than fake universal benchmarks.

If one person saves every release, the organization does not have a hero. It has a single point of failure with good calendar manners.

Most organizations describe hero mode as a talent story. Someone steps up, someone knows the system, someone stays late, and someone saves the release. That version is flattering, incomplete, and expensive.

Hero mode is what happens when the route requires one person to function. The system depends on them because the organization never built the conditions that would let anyone else carry the work. Nobody wrote “make Priya the resilience strategy” on a whiteboard, but the system behaved as though someone had.

This is another broken route problem. The signal exists, the decision history exists, the operational knowledge exists, and the escalation path exists. The problem is that all of it passes through one person. The pattern forms quietly. The first time the hero stays late, people call it commitment. The fifth time, people call it reliability. The fiftieth time, people stop calling it anything because it has become the operating model.

Reliability is not resilience

The hero makes the system more reliable. That is the trap. They prevent incidents, stabilize releases, answer questions nobody else can answer, and make the dashboard look safer than the system actually is. The release shipped. The customer was saved. The metrics stayed green. From the inside, one person absorbed the gap.

I have watched delivery trains report confidence while knowing the actual plan depended on a few people privately reconciling dependencies the official board made look solved. The metrics were not useless, but they were incomplete. They showed the plan people had agreed to. They did not show the hidden human labor required to make that plan survivable.

Management sees green dashboards, a praised hero, and “great work, team.” The team lives one person online at 2:00 AM, Slack archaeology for rollback scripts, and architecture decisions that still require a human oracle. Reliability asks, “Did we ship?” Resilience asks, “Could we ship without them?”

That distinction matters because reliable systems can still be fragile. Every rescue can increase confidence in the result while decreasing resilience in the route. The organization praises the firefighter, then quietly builds more of the building out of matches.

The hidden dependency map

The real dependency map does not appear in the org chart. It appears in patterns: who gets called when the release breaks, who knows why the workaround exists, who remembers which customer exception changed the architecture. That map usually carries three kinds of knowledge.

System knowledge: legacy services, release scripts, migration history, and operational folklore that never made it into the official runbook. Decision knowledge: why a technical compromise exists, why a customer exception became permanent, and why one old service still behaves like a haunted filing cabinet. Rescue knowledge: incident intuition, rollback judgment, escalation shortcuts, and the “I know who to call” memory that saves hours when something breaks.

Share

The tracked surface is visible: tickets closed, incidents resolved, releases shipped. The organizational memory is harder to see: decision history, rollback judgment, folklore, and the quiet knowledge of what not to touch. When they leave, the codebase stays. The context walks. You can hire another principal engineer. You cannot instantly hire six years of local memory, political context, customer scars, and operational judgment. Recruiting replaces capacity. Knowledge transfer restores continuity.

The season lands here

Profit With Proof has spent seven episodes pricing costs organizations hide from themselves. The Rework Tax priced ambiguity.

The Escalation Delay Cost priced silence.

The Churn You Can Predict priced ignored signals.

The Compliance Theater Budget priced controls that photograph well but do not work well.

The Integration Penalty priced tool rollouts that never became adoption.

The Agile Meeting Burn Rate priced coordination theater.

The Ghost Capacity Trap priced the hours the spreadsheet pretended did not exist.

Episode 8 names the person who absorbed those costs until the system mistook their exhaustion for resilience. Even if this is your first Profit With Proof article, the pattern is simple: every hidden cost survives longer when one person quietly absorbs it. The hero’s nights and weekends became the missing capacity the spreadsheet never counted. That is the capstone logic. The first seven costs were survivable because someone absorbed them. That someone is now in the exit interview.

The comfortable dependency trap

Here is where this gets uncomfortable. A team can be psychologically safe enough to admit the problem and still not be structured to survive it. Many leaders assume that once people feel safe to speak up, the system will naturally improve. That is only half true.

Psychological safety, as Amy Edmondson’s work defines it, tells us whether people feel safe taking interpersonal risks, asking for help, admitting mistakes, and raising problems. In hero-mode teams, that climate matters because someone must be able to say, “We are one person away from a serious delivery failure.” But psychological safety is not the same thing as structural resilience.

A team can trust the hero, admire the hero, and feel safe asking the hero for help. A team can be kind, warm, collaborative, and deeply fragile. That is what I call comfortable dependency: an editorial label for a pattern the research indirectly points to but has not named as such. The term is doing narrative work here, not scientific work.

I have been in rooms where everyone believed the team could handle whatever came next, but once we got specific, the plan quietly depended on Sarah knowing the deployment path and Miguel knowing the one integration nobody else could safely touch.

The dangerous quadrant is the comfortable one: the hero is trusted, everyone knows who to ask, and nobody pushes hard enough to change the structure. The answer is not “build psychological safety” and declare victory. Safety opens the conversation. Structure changes the system.

Where the time goes

Hero mode is often described as dramatic. Sometimes it is: a Sev 1 incident, a late-night rollback, a deployment that survives because one person knows which sequence of scripts and prayers will keep the system upright. Most of the time, though, hero mode is not cinematic. It is fragmented, interruptive, and boring in the way only chronic organizational failure can be boring.

There was a period where my calendar said coaching and facilitation, but the actual work was being human middleware for Sarah, James, and Priya as they tried to reconcile the official process with the work the team actually had to survive. Every interruption felt reasonable in isolation. Together, they became a one-person rescue operation.

Incidents and on-call, release firefighting, customer exceptions, ad hoc architecture consults, legacy context provision, and actual roadmap work squeezed into whatever oxygen remains. The hero is not only doing extra work. They are losing the conditions required to do the work leadership thinks they are paying them to do. When leaders ask why the roadmap is slipping, the answer may be sitting in five categories of invisible labor. That is not productivity. That is containment.

What the evidence actually lets us price

Now we can talk about money. Not first. Now. Profit With Proof has one job: name the hidden cost, price what can be priced, and refuse to launder folklore into finance.

The tempting move would be to say, “Replacing a senior engineer costs three times their salary,” then build the whole argument around that number. That would be convenient. It would also be too soft. The evidence review found no strong, role-specific basis for treating “3x salary” as a universal benchmark for senior technical replacement cost. No borrowed benchmark should be allowed to wear a cape indoors.

The safer frame is this: the model does not tell you what every hero costs. It helps you price what your organization has chosen to leave concentrated.

The equation is built around user-supplied assumptions. Estimated exposure includes replacement assumptions, ramp time assumptions, incident and release exposure, the knowledge transfer gap, and local cost inputs. The output is a scenario range and a risk band, not a universal benchmark, not a precise accounting number, and not a performance score. That distinction is not academic. It is the difference between a model a CFO can challenge productively and a model they can dismiss in twelve seconds while adjusting their glasses.

The strongest financial context belongs at the macro level: industry-level estimates put the cost of poor software quality in the trillions, but those figures are modeled context, not audited line items and not a bus-factor benchmark. Hero-mode dependency is one local mechanism by which operational fragility stays hidden until it becomes expensive. Those macro numbers tell you there is a lot of money on the table, not how much any single hero costs.

The Bus Factor Cost Model and what leaders should do next

The Bus Factor Cost Model is a resilience inventory (available bottom of this page for download). It is not a hero detector, an HR instrument, or a surveillance dashboard for ranking “risky employees,” a phrase that should be taken outside and made to think about what it has done. It asks leaders to define one scope: one system, service, or release path where everyone already suspects the same person gets called. Then it asks practical questions. Who can execute this path end-to-end? Is the runbook current? Is there a backup owner?

The Varajão team resilience model is useful here as a supporting diagnostic, not as a financial benchmark. Scorecard here means a small set of questions and observations, not a numeric performance score. It gives leaders language for the underlying resilience factors, including trust and solidarity, management and accountability, and skills and behaviors.

Do not start with the whole organization. That is how practical ideas go to die in a steering committee wearing loafers. Start with one critical release path. Name the person-shaped dependency without blaming the person. Write, “The release rollback process depends on knowledge currently concentrated with Priya.” Assign a backup owner. Not a vague team, not “engineering,” and not “platform will handle this,” which often means “a meeting will absorb this concern until everyone forgets why it mattered.” A named person needs hands-on capability.

Create one transfer artifact per dependency: a runbook, decision record, pairing session, or incident replay. Then give the work time. Do not punish the hero by turning them into a documentation factory. Knowledge transfer is not extra work. Knowledge transfer is the work that proves the organization actually wants resilience. In one fictional example, a single rollback dependency moved from red to yellow in thirty days, without adding headcount. That is what measurable reduction looks like. Treat whatever numbers you get as inputs to a conversation, not as the final answer your finance team should book into a model.

Subscribe now

Do not use this model for performance reviews, compensation discussions, blaming the hero, ranking risky employees, declaring precise dollar costs, or during a live incident. Use it for QBR prep, succession planning, incident retrospectives, capacity planning, roadmap risk reviews, and resilience investment discussions.

The cost of gratitude without design

Return to the exit interview. The engineer leaves. The VP finally understands the cost, but too late. The releases were stable, the incidents were avoided, the customers were protected, and the dashboards stayed green.

The organization called that performance. The engineer called it exhaustion.

Hero mode is expensive because it hides the bill until the person carrying it stops carrying it. That decision to depend on one person often looks rational in the moment. Ask the hero, move faster, save the release, keep the customer calm, skip the documentation, and promise to fix the structure later. Later becomes next quarter. Next quarter becomes after the migration. After the migration becomes once hiring improves.

That is the premium. Not the salary, the recruiter fee, or the replacement timeline alone. The premium is the accumulated cost of every dependency the system normalized because the hero kept making the consequences invisible. The person who saves every release is not your resilience strategy. They are the receipt for the one you never built.

Earlier in my career, I wish I had understood that gratitude can become an exceptionally polite form of avoidance. If Sarah is saving every release, thanking her is not the same as redesigning the system so she does not have to.

That is also the larger case behind my upcoming book, Collaborate Better. Better collaboration is about designing systems where responsibility, knowledge, and decisions do not collapse onto the same exhausted person. When collaboration fails, people absorb the damage. When collaboration works, the route survives without requiring a hero every Friday night. Learn more at CollaborateBetter.us.

Premium artifact (FREE)

Here’s the Bus Factor Cost Model. It helps engineering and product leaders inventory key dependencies, estimate exposure using local assumptions, and identify the top knowledge-transfer actions that reduce hero-mode risk.

This model helps you ask the questions your dashboards cannot answer: who actually carries the critical path, what would fail if they were unavailable, and what transfer work would reduce the exposure before the exit interview.

Bus Factor Cost Model

102KB ∙ XLSX file

Download

The Bus Factor Cost Model helps you identify where critical knowledge, release judgment, incident response, or customer context has become concentrated in one person before that dependency turns into an exit-interview surprise. It walks you through a knowledge inventory, dependency audit, scenario-based exposure estimate, resilience scorecard, and executive-ready summary so you can make a board-safe case for transfer work, backup ownership, and continuity investment. Use it when your team keeps saying “ask Sarah before touching that” and you need to turn that uneasy feeling into a practical resilience plan.

Download

The Route Rebuilder begins next

Profit With Proof was about naming the dollar value of operational failure. The Route Rebuilder moves to the next question: once you can see the cost, how do you rebuild the route that created it?

This next series is for engineering and product teams living inside real organizational systems: incident channels that bury warnings, handoffs that make ownership optional, review gates people learn to skip, velocity metrics that hide rework, AI tools that quietly absorb judgment, and pressure-tested routes that survive because someone designed them to survive.

That is the bridge from this episode. Hero mode is what happens when the route through the system becomes a person. The Route Rebuilder asks what comes next: how to name the broken route, redesign the decision path, and ship a practical tool the team can use before the next sprint, incident, or launch turns theory into consequences.

P.S. If your resilience plan has a first name, a Slack handle, and a vacation calendar everyone fears, which critical path will you inventory first?

Regards,

Mark 👋

Empathy Engine | Substack.Mark-Carroll.com | Evidence-Forward Product Leadership

Citattions and Research Binder

3.79MB ∙ PDF file

Download

This article’s Citations and Research Binder is an evidence-forward pack supporting The Hero-Mode Premium, the Bus Factor Cost Model, and the related infographics. It ties material claims to admissible sources, separates scenario-based estimates from direct measurements, and makes the article’s limits explicit. The binder’s core argument is that hero mode is not simply admirable commitment or a morale problem. It is a structural dependency pattern where release judgment, incident response, customer exception memory, decision history, and tacit knowledge concentrate in one or two people until the system looks more resilient than it is. The financial layer rejects a universal “3x salary” benchmark and instead supports the workbook’s safer approach: local assumptions, scenario ranges, ramp-time estimates, incident or release exposure, and knowledge-transfer investment. The organizational layer draws from research on tacit knowledge, knowledge transfer, psychological safety, team resilience, turnover, software delivery performance, and incident response. The binder also defines the guardrails. The Bus Factor Cost Model is not an HR tool, compensation tool, performance review instrument, or way to rank “risky employees.” It prices structural dependency, not a person’s worth. The result is a decision-grade evidence pack for QBRs, board updates, succession planning, incident retrospectives, roadmap reviews, and resilience conversations where the dashboard says “stable” but the team knows the route still runs through one person.

Download

Previous:

More Content to Discover:

What Still Has Value When AI Does the Task

👋 Welcome to my paid subscriber-only edition of Empathy Engine (Leader’s Dispatch). Each week I build evidence-informed tools for serious solo operators, leaders, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks and contemporary organizations.

In Episode 4, I argued that the hybrid solopreneur has to shift from doer to director. This week asks the next question: once AI can execute more of the task, what part of the offer still truly requires your judgment?

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this post.

The Rough Draft That Changed the Conversation

I had a moment where AI produced a rough version of something I would normally sell.

The uncomfortable part was not that the output was brilliant. The uncomfortable part was that it was good enough to change the pricing conversation. It had the structure, the polish, the confidence, and the familiar shape of professional work. A client could look at it and reasonably wonder how much of the old fee was tied to producing the first draft.

That forced me to sit with an unpleasant distinction. If I was pricing the existence of the deliverable, AI had just weakened the case. But if I was pricing the judgment behind the deliverable, the work was still there. What should be promised? What should be rejected? Which evidence deserves weight? What risk is hiding under the clean language? What recommendation am I willing to stand behind?

That was the useful discomfort. AI did not make the work worthless. It made the lazy explanation of the work harder to defend. The premium was never the rough draft. The premium was the calibrated judgment that turned the rough draft into something a client could trust, use, and defend.

The work was executed. The offer that produced it was never designed. This episode is about that second sentence.

A task-only offer says, “I write research summaries.” A judgment-based offer says, “I help product leaders separate useful evidence from impressive noise so they can make roadmap decisions they can defend.” That distinction is the rest of this article.

Episodes 1 through 3 diagnosed the trap. The orchestration tax. The unpaid management job. The gap between completed and done. Episode 4 redesigned the role. This episode answers the question that redesign exposes. Once you stop proving your value by staying inside every workflow, what exactly is the value you are protecting? That is not a philosophical question. It is a pricing question.

The reason this question matters is structural, not inspirational. Clients who cannot see what you filtered, what you checked, and what you decided cannot weight your judgment appropriately. They are not being difficult. They have no signal. Making the judgment layer visible is not a communication strategy. It is the mechanism by which your recommendation gets used.

Without that visibility, even polished AI output becomes hollow completion: high-speed work that lacks contextual weight and accountability. The machine finishes the task in seconds. Only you own the consequence.

That is the human premium. Not mystical humanity. Not personality glitter. Not a scented candle called Authenticity. The human premium is evidence judgment: the ability to separate useful evidence from impressive noise so a client can make a decision they can defend.

The task is not the safest place to build your value

Most solo offers start with the visible artifact. I write research summaries. I create content calendars. I build competitive scans. I draft strategy decks. None of those are useless. The risk appears when the entire offer depends on the existence of the artifact.

AI reduces the effort required to produce many first-pass outputs. That changes what clients can compare, question, and discount. When the client can produce a rough output themselves, the client may assume the remaining difference is polish. That is where weak offers collapse.

The task is the visible layer. The documents, windows, drafts, and summaries are the part everyone recognizes. What it takes is the work underneath: context intake, accuracy checks, expert review, structure, order, and final validation. Those steps decide whether the output deserves trust.

More information is not the same as better evidence

Product leaders already live inside evidence overload. A customer quote can be emotionally powerful and strategically weak. A sales request can be urgent and still not represent the market. A competitor can look threatening on paper while serving a different buyer. A metric can be clean, current, and irrelevant to the decision in front of the team.

AI makes this harder in one specific way. It can organize the pile so beautifully that the pile starts to look like an answer. The pattern is well-documented across decision science: more information without structured filtering often degrades decision quality rather than improving it.

In product work, I have seen this happen when a team had customer feedback, stakeholder requests, usage data, defect reports, executive pressure, and sales escalations all sitting in the same conversation. Nobody lacked evidence. The problem was that every piece of evidence had been given equal moral standing. A loud sales escalation, a recurring customer pain, an executive preference, a support pattern, and a usage metric were all treated like they belonged on the same scale. The room had plenty of information. What the room did not have was a shared way to decide which evidence deserved weight.

The moment I realized the pile was not the answer was when someone said, “The data is clear,” and three people in the room clearly meant three different things by “the data.” Product meant customer impact. Sales meant deal urgency. Engineering meant delivery risk. Leadership meant the commitment already made upstairs. Everyone had evidence. Everyone could defend their slice of the pile. The team was not arguing over whether evidence existed. The team was arguing over which evidence should govern the decision.

That is the moment the work changes. You stop needing another summary or AI-generated synthesis that politely arranges the same conflict into cleaner bullet points. You need someone to say: this quote is loud, but not representative; this escalation is urgent, but not strategic; this metric is relevant, but not sufficient; this executive preference matters politically, but should not be disguised as customer evidence.

That is the difference between a pile and an answer. A pile contains evidence. An answer ranks it. The premium is not the summary. The premium is the weighting. It is separating useful evidence from impressive noise before the room mistakes motion for clarity.

A practitioner model that maps this cleanly is the 10-80-10 rule. AI handles the 80% middle: the research gathering, the first-pass synthesis, the comparison tables. You own the 10% on each end: the framing that determines what question is worth answering, and the verification that determines whether the answer survives contact with reality. The edges are where your judgment becomes visible.

Share

The human premium is evidence judgment

Read more

Your resourcing model says you have time. Your engineers know otherwise.

👋 Welcome to this week’s edition of Empathy Engine. Every Wednesday (formerly Tuesday), I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Previous article in this series: Episode 6 (A Meeting Killed Your Profits)

I have watched a resourcing spreadsheet turn a drowning team into a neat green row while the “20% available” column quietly ignored support rotation, code review, production noise, and the one senior engineer every urgent question somehow found first. Everyone could see the number was wrong, but nobody wanted to be the first person to make the meeting uncomfortable.

A resourcing manager prepares a capacity plan for the next quarter. Four engineering teams. 80% allocated. 20% available for new work. The spreadsheet looks responsible. The numbers are clean. Three engineering leads review the plan and ask the same question: “available to whom?”

The 20% represents time that exists on paper between scheduled deliverables. It does not account for context switching costs, interrupt-driven support requests, code review obligations, documentation debt, or the undocumented work that fills every gap the plan does not acknowledge. The capacity is real in the spreadsheet. It is ghost capacity in the building.

That is the Ghost Capacity Trap!

The plan looked clean because the system only counts the work that made it onto the board. Here is what happens to that plan by Wednesday.

The Rework Tax priced work paid for twice. The Escalation Delay Cost priced the silence between warning and owner. The Integration Penalty priced the workaround nobody removed. The Agile Meeting Burn Rate priced coordination that lost its return. Each of those costs was survivable. That is the trap. Ghost capacity is the operating condition that made every one of those costs absorbable long enough to ignore.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.

What this article does and does not claim

Does: give you a defensible way to estimate your own ghost capacity exposure, and a diagnostic structure you can carry into a capacity planning conversation.

Does not: claim a universal benchmark for invisible work, guaranteed capacity recovery, or a specific percentage that applies to your team without measurement.

TL;DR

• Ghost capacity is the gap between what the resourcing model says is available and what the team can actually direct to new work.

• Most capacity models measure allocation, not availability. The gap between them is where burnout accumulates and delivery commitments quietly become unrealistic.

• The system does not just fail to measure invisible work. It rewards absorbing it silently and punishes naming it openly.

• The Capacity Reality Check turns that gap into a number your leadership team can challenge in a QBR.

You start the sprint with less than you think

Capacity planning feels reliable because the system produces a specific number. The number is clean. It reconciles with the headcount. It maps to the sprint. It looks like something you can commit against.

The CISQ 2022 Cost of Poor Software Quality report, aggregated from 88 US public sources, estimates that roughly 33% of developer time is consumed by unplanned work and rework. For a 10-person team that appears to have 10 developer-days available, true starting capacity is closer to 6.7. The missing 3.3 developer-days are not a rounding error. They are a structural misread of reality that the plan never accounts for, because the plan was not designed to see work the system does not formally track.

When that missing capacity inevitably surfaces mid-sprint, it looks like disruption. It is not. It is a delayed reveal of time that was already spoken for before the sprint began.

The missing 3.3 developer-days do not vanish randomly. They follow consistent, repeatable channels that show up across teams. Context switching imposes a recovery tax: each interruption costs an average of twenty-three minutes of cognitive reorientation before deep work resumes. Unplanned requests arrive through side channels (ie. Slack pings and “quick favors” that bypass the sprint board entirely). Technical debt accumulates as a permanent, undocumented capacity tax. Meeting overhead consumes executable hours. Recovery overhead compounds the cost of every interruption beyond its visible duration. Additionally, knowledge concentration routes critical decisions through one person, creating a single-point-of-failure that quietly absorbs capacity nobody budgeted. Yeah! It’s a lot.

The plan did not lie. It had no place to put the truth.

Six categories of invisible work consume capacity before commitments are made. None of them appear on the sprint board.

The system trains teams to overcommit

The most dangerous part is not the extra work. It is what the organization learns from watching the team survive it. When teams successfully “handle it,” the organization quietly updates its expectation of what that team can do. Over time, invisible effort becomes normalized capacity, and overcommitment stops looking like a problem and starts looking like performance.

When absorption looks like performance, the trap has already closed.

The sprint starts clean. New work enters informally. Nothing is removed from the original plan. The team absorbs the additional load without updating the commitment. The next sprint then starts from the same unrealistic baseline, because the previous sprint appeared to succeed. The illusion reinforces itself. Each cycle raises the organization’s expectation of what the team can carry, because the team kept carrying it. The fact that they carried it through overtime, cut corners, and quiet exhaustion does not appear in any system the planning process consults.

Invisible work is not disruption. It is the operating system. The system fails to account for it because accounting for it would make the plan less comfortable to present, and the meeting rewards comfortable plans.

Share

For the record, I’ve experience with all of this and my track record isn’t spotless. Case in point, a client once needed a “quick deck refresh” before their steering committee meeting, and I treated it like a light polish because the moment felt urgent. In reality, the refresh required new data, revised screenshots, updated assumptions, and a full review from engineering. Only later did I realize the ask was quick for me because someone else paid the recovery cost. I chalk this up as a lesson learned the hard way.

Three views of the same fiction

The resourcing lead sees efficiency. 80% allocated means the team is well-utilized. 20% available means there is room for new work. The model does exactly what it was designed to do.

The PMO and delivery function sees assignable bandwidth. The 20% is an input to the next project commitment. It enters a slide. It enters a timeline. It enters a promise made to a stakeholder who will hold the organization to it six months from now.

The engineers see a promise they cannot keep. The 20% does not account for the code reviews, the interrupt-driven support requests, the documentation debt, the undocumented recurring work, or the context-switching overhead that consumes twenty-three minutes of recovery per interruption. The capacity is real in the model. It is ghost capacity created within the building.

The presenter said the team had “roughly 20% available capacity” while the engineering lead was already on support rotation, carrying two production issues, and reviewing the architecture for a dependency nobody had staffed. The absurd part was watching that 20% get treated like available inventory, as if the person attached to it were sitting untouched on a shelf.

The system is optimized for utilization optics. High utilization looks efficient. Available capacity looks like slack to be assigned. So the resourcing model removes slack, fills available time, and calls it optimization. The engineers experience the optimization as drowning while the spreadsheet shows green.

This is not a communication problem. It is a decision structure problem.

Formal commitments and informal requests follow different rules. Planned work moves through a structured mechanism where capacity is evaluated and locked. Unplanned work arrives through conversations, messages, and “quick favors” with no equivalent removal process. The gap between those two systems is where ghost capacity is created. A request can be valid, urgent, and strategically important without creating new capacity. When work is added without a tradeoff, the team is effectively financing that work through hidden effort.

The spreadsheet shows green

That is the verdict. Everything else in this article exists to help the reader make that verdict financially legible. Not universally, not theatrically, and not with fake precision dressed up as proof. Locally. Defensibly. In the language of the next capacity planning conversation.

The organization now operates on two realities. The visible one, where the plan reconciles and the sprint looks viable, and the operational one, where the team is already absorbing work the plan never acknowledged. Both realities cost money. Only one appears in the reporting. The gap between them is the exposure this article prices.

What the evidence actually lets us price

There is no clean, universal benchmark for ghost capacity cost. There is no portable industry number you can borrow, place into a chart, and treat as revealed truth. What the evidence does support is a structural model grounded in defensible benchmarks that the reader can apply to their own environment.

The CISQ 2022 Cost of Poor Software Quality report estimates that roughly 33% of developer time is consumed by unplanned work and rework. Google’s DORA State of DevOps research consistently finds that sustainable work pace correlates with delivery performance, and that organizations protecting capacity outperform those optimizing for utilization. Context-switching research estimates that each interruption costs approximately twenty-three minutes of recovery time before deep-focus work resumes. The figure originates from Gloria Mark’s work at UC Irvine on workplace interruptions and has been widely cited across productivity research. A ten-minute favor actually burns closer to thirty-five minutes of cognitive runway.

Start with a 10-person team running two-week sprints. Eight hundred total team hours per sprint. Apply the CISQ 33% benchmark: roughly 264 hours per sprint are consumed by work the plan does not track. Use the BLS median loaded labor rate of approximately $70 per hour. That is roughly $18,500 per sprint in ghost capacity for unplanned work alone. Factor in context-switching overhead and recovery time and the range widens to $36,000 to $45,000 per sprint. Annualized across 26 sprints, that produces roughly $480,000 in capacity exposure for a single 10-person team at the CISQ 33% benchmark. Organizations running lower ghost percentages or lower loaded rates will land closer to $390,000. The range depends on your inputs. The structure does not.

(These are modeled estimates using research benchmarks and BLS salary data, not a universal cost figure. Your numbers will differ. The structure will not.)

That is not just cost. That is lost optionality. This is why migrations slip without being reprioritized. This is where roadmap confidence erodes without an obvious failure. This is why teams feel busy while strategy stalls. The money is real. What it could have purchased is the part that keeps compounding.

The Ghost Capacity Ratio

Reported available hours divided by hours that can actually be directed to new planned work after subtracting context switching, interrupts, undocumented recurring obligations, and recovery overhead.

If the ratio is above 1.5, the gap between the spreadsheet and reality is large enough to be costing real money every sprint. If you cannot calculate this ratio for your team in under thirty minutes, that is not a data inconvenience. That is the finding.

Three things the spreadsheet teaches people to say

“But we already account for overhead.” Most capacity models deduct holidays, PTO, and maybe training. They do not deduct context switching, interrupt-driven support, code review obligations, documentation debt, undocumented recurring work, or recovery time. That is why the plan starts at 80% allocated and still fails by Wednesday.

“This is just engineers complaining about being busy.” It is a capacity measurement question. The spreadsheet reports one number. The building operates on a different one. This article is asking which number your next commitment should be based on.

“We cannot reduce unplanned work to zero.” Correct. The artifact is not designed to eliminate it. It is designed to make it visible before commitments are made, so the next promise is based on reality, not on the plan’s comfortable fiction.

What leaders should do next

Before you run the Capacity Reality Check, try this. Pick one team. One sprint. No permission slip required.

1. Name the ghosts. Write down every category of work that consumed team time but did not appear in the original sprint plan. Unplanned requests, interruptions, context-switching overhead, code review, undocumented recurring obligations. Do not judge. Just list.

2. Count the injections. How many times did something enter the sprint without anything being removed or deferred? One count. One number.

3. Estimate one ghost. Pick the most frequent category. Use your loaded daily rate and a conservative time estimate. Multiply by the number of occurrences in one sprint. Round down. You are building a floor, not a ceiling.

4. Calculate the delta. Hours committed to planned work minus hours actually available after ghost work is subtracted. Apply the loaded rate. That is your ghost capacity cost for one sprint.

5. Bring the number. One slide. One sprint. One team. Show the number in the next capacity planning conversation. Not a verdict. A range. Ask the room: is this number surprising?

The Decision Gate

Every new request that enters an active sprint needs one of three responses.

1. Remove. Something currently in the plan comes out to make room.

2. Defer. Something currently in the plan moves to the next sprint with a named re-entry point.

3. Escalate. A tradeoff conversation happens with someone who has the authority to reprioritize.

If a new item enters the sprint without triggering one of these three responses, the team is funding that work with ghost capacity. The cost is real. It is just not on anyone’s ledger.

Every new request needs one of three responses. If none of them fires, the team is financing that work with capacity the plan already spent.

Subscribe now

The Capacity Reality Check

Once you name the ghosts, the next question is obvious: how much capacity are they consuming? That is what the Capacity Reality Check gives you.

• What it is. A branded Excel workbook with four tabs: Start Here (a plain-language walkthrough that orients you in minutes), Capacity Inventory (where the six ghost categories are entered with time estimates and loaded rates), Executive Summary (a one-page, screenshot-ready strip for a QBR or board packet), and Gap Analysis (a ranked view of ghost categories by cost exposure with conservative and moderate scenario ranges).

• What it calculates. Scheduled capacity versus actual available capacity across six adjustment categories. True available capacity as a percentage of scheduled capacity. The dollar delta between what was promised and what can be delivered. Per-sprint and annual exposure ranges.

• What it answers. The one question most teams cannot currently answer: what percentage of your reported available capacity is ghost capacity that has already been consumed by work the plan does not track?

What conversation it supports. Capacity planning, quarterly commitment reviews, sprint retrospectives, and any room where someone is about to promise delivery based on a spreadsheet that has never been audited against reality.

Designed to be opened and understood in under ten minutes. The Executive Summary tab is built to be screenshot or forwarded to a VP, CFO, or board as a capacity-prioritization argument. The defaults are pre-populated from the article’s illustrative numbers so you immediately see the math in action and can substitute your own.

Subscribers will find the Capacity Reality Check below. It calculates the gap between your spreadsheet and your building. If you want the tool, it is here:

Capacity Reality Check

64.3KB ∙ XLSX file

Download

The Capacity Reality Check helps you compare scheduled capacity against the capacity your team can actually use. It subtracts six hidden work categories that usually stay out of the plan. The result is a defensible number you can bring into your next commitment conversation.

Download

The plan did not fail. It never reflected reality.

The sprint does not fall apart because teams lack discipline or effort. It falls apart because the planning system does not account for the full set of forces acting on capacity. The plan reflects the visible system. Execution reveals the real one.

The point is not to produce a definitive number for invisible work. The point is to remove the organization’s ability to keep planning against a fiction. Once that number exists, even as a bounded estimate using local inputs, it becomes harder to promise delivery using a spreadsheet nobody has audited against reality (unlike the Capacity Reality Check above).

You are not walking in to prove the plan is wrong. You are walking in to show what the plan cannot see. Bring the numbers, show your inputs, and let the conversation shift from an opinion to a tradeoff with receipts.

That is also the larger case behind my upcoming book, Collaborate Better. Better collaboration is not about being nicer in meetings. It is about reducing avoidable friction before it turns into waste, delay, and preventable cost. When resourcing models promise capacity that does not exist, teams absorb the damage. Collaborate Better is the manual for stopping that human and financial bleed. Learn more at CollaborateBetter.us.

Next week in Part 8: When Profit Depends on One Person. The season finale. Seven episodes have priced the hidden costs inside your delivery system. Episode 8 prices the person who has been absorbing them.

P.S. Before your next capacity meeting, pick one person your plan shows as “available” and list every invisible obligation already attached to them: support rotation, code review, production noise, onboarding, stakeholder pings. If the list takes more than a minute to write, that person is not available in the way the spreadsheet says.

Regards,

Mark 👋

Empathy Engine | Substack.Mark-Carroll.com | Evidence-Forward Product Leadership

Citations And Research Binder

4MB ∙ PDF file

Download

This article’s Citations and Research Binder is organized as an evidence-forward pack built to support the core claims in The Ghost Capacity Trap, the Capacity Reality Check workbook, and each infographic panel with source-labeled backing, modeled-estimate notes, and explicit limitation boundaries. The binder follows the Profit With Proof underwriting standard: material claims are tied to admissible evidence, numbers are traced to their source logic, and modeled estimates are clearly separated from direct measurements. For this episode, the spine centers on the safest argument the evidence supports: ghost capacity is not a vague morale complaint or a poetic name for being busy. It is the measurable gap between reported available capacity and the work already consumed by unplanned work, rework, interruptions, support drag, code review, documentation debt, recovery time, and knowledge concentration. The binder’s first layer establishes the benchmark inputs behind the article’s financial model. CISQ’s 2022 software quality report provides the core unplanned work and rework benchmark used to model the gap between scheduled capacity and true available capacity, while BLS wage data supplies the labor-rate foundation for translating hidden hours into sprint-level and annualized exposure. The binder is explicit that these figures are structural inputs, not universal team benchmarks. Your numbers will vary, but the modeling logic is traceable. The second layer underwrites the cognitive and operational mechanisms behind ghost capacity. Gloria Mark’s interruption research, Microsoft developer productivity studies, DORA research, technical debt sources, Agile sustainable pace principles, WIP-limit evidence, and developer productivity research all support the article’s central mechanism: planned work is only one part of delivery reality. The binder shows why interruption recovery, communication load, technical debt, fragmented work, and unstable priorities can consume capacity before a new commitment is ever added. The third layer is evidence boundaries. This binder does not pretend ghost capacity has one clean universal percentage, one guaranteed recovery number, or one portable cost-per-team benchmark. Instead, it supports local estimation: start with defensible benchmarks, replace defaults with your own data, calculate the delta, and use the result as a decision input rather than a verdict. The final layer is operational reuse. The binder maps evidence directly to the article’s core jobs: making hidden work visible, translating capacity fiction into financial exposure, distinguishing allocation from availability, supporting the Decision Gate, and equipping leaders to bring a number into QBRs, sprint reviews, roadmap reviews, and capacity planning conversations. The result is a decision-grade evidence pack built for transparency, defensibility, and practical reuse in any room where the spreadsheet says “available” and the team knows otherwise.

Download

Previous:

More Content to Discover:

Why the skill that built your solo business is now the one holding it back

The Summer-Camp Parking Lot

👋 Welcome to my paid subscriber-only edition of Empathy Engine (Leader’s Dispatch). Each week I build evidence-informed tools for serious solo operators, leaders, and team leads who have moved past the hype and are now w…

Read more

Thirty-one hours out of eighty. Count it on your own calendar.

👋 Welcome to this week’s 2nd edition of Empathy Engine. Every Tuesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.

What this article does and does not claim

Does: give you a defensible way to estimate your own meeting burn, and a one-sprint audit structure you can carry into a capacity conversation.

Does not: claim a universal benchmark for meeting overhead, guaranteed productivity recovery, or a specific percentage that applies to your team without measurement.

TL;DR

• Meeting cost is not a productivity complaint. It is a resource allocation fact.

• When a sprint starts absorbing 26 or more meeting hours per engineer, the calendar is behaving less like an alignment tool and more like an expense structure.

• The Meeting Cost Ledger turns that calendar into a number your finance partners can defend in a QBR.

Previous article in this series: Episode 5 (The Catastrophic Cost of Looking Safe)

The calendar stopped being a calendar.

A few years back, I was in a large SAFe planning cycle. RTEs, engineering managers, product managers, architects, and a director who kept returning to the importance of alignment. Someone had just finished praising the event as a success because, “all teams got on the same page.”

I asked a simple question. How many hours per engineer did this planning cycle consume once you included team planning, cross-team breakouts, dependency syncs, risk review, ART sync prep, and the follow-up re-planning sessions?

The room treated it as a harmless facilitation exercise. Then the number landed. Twenty-six hours for some teams. Thirty-one for others. More for a few. Someone started dividing against available sprint capacity. The room went quiet when they realized they had burned a third or more of the opening sprint just coordinating the right to begin work.

One PM stared at the spreadsheet like it had betrayed them personally. An engineering manager laughed once, then stopped. A voice from leadership tried to salvage it: “Well, some of that is necessary.” Which was not wrong. It just sounded a lot weaker after the total was visible.

The director stopped saying alignment. The director started asking whether everyone agreed with the math.

The calendar stopped being a calendar. It had been behaving as a budget all along. Nobody had ever read it that way.

I say that as someone who has added meetings that felt responsible at the time.

The visible ceremonies are not the cost center. The duplicated coordination accumulating beneath them is.

Teams call it alignment. It is duplicate billing.

Not every hour on the calendar is the same kind of hour. Planning, standups, refinement, retros each earn their place when they sharpen priorities and support real decisions. The trouble begins when the same conversation gets replayed across adjacent rooms because nobody trusts the first room to hold.

This is not a story about leaders who love meetings. It is a story about a visibility vacuum: when asynchronous channels fail to give executives the financial and timeline safety they need, calendar invites multiply. The extra meetings are not anxiety running wild. They are anxiety doing its job inside a system that stopped producing trust by other means.

This is not just a local gripe. Microsoft’s Work Trend Index documents a broad pattern of meetings and chat absorbing most of the professional workday, with attention fragmentation rising alongside it. Leslie Perlow’s long-running research at Harvard Business Review shows that even modest, disciplined cuts in meeting frequency produce outsized recovery in team focus. Those macro findings are the weather; your Ledger is the receipt. Full citations and source notes appear in the Research Binder attached at the end of this article.

Zoom in on any single sprint and the pattern has a shape. Monday looks like clarity. By Friday the plan is no longer the plan, and the team is re-planning instead of delivering.

The sprint plan did not fail because the engineers missed the work. The sprint plan failed because the coordination spine got overridden by the layered meetings that formed around it.

The calendar is not a planning tool. It is an expense structure.

A team can be over-informed and under-decided at the same time. Once that happens, every hour on the calendar is a line item. Most of those line items have never been reviewed for renewal.

A meeting that outlived its reason is not tradition. It is unbilled inventory.

The most durable recurring sync in any organization is often the one nobody has the heart, the memory, or the political cover to kill. Every office has at least one agenda item that is no longer really a topic; for the longest time, it has been nothing more than a commemorative plaque. A surprising number of meetings survive on one idea alone: nobody wants to be the first person accused of being the reason the holy cow was sent to the butcher.

Each meeting made sense. Together they made a system.

Meeting one surfaces the issue. Meeting two restates it for another audience. Meeting three revisits it because the second room lacked decision authority. Meeting four exists because nobody trusts the first three to hold.

Every step feels reasonable in isolation. Put together, they create a system that rewards attendance over decision compression. Nothing says operational confidence like a pre-meeting to prepare for the meeting where nobody is going to decide anything anyway.

This is another broken route, but the one running between decision signal and owner, not between functions.

At scale the shape hardens. Frameworks that promise alignment often deliver layered sprawl instead, where the middle of the stack thickens with syncs and follow-ups that consume the capacity the core teams needed to ship.

This pattern appears in any scaling structure where coordination volume rises faster than decision authority. SAFe makes it easy to see because the layers are named. The diagnosis is not framework-specific. The math that exposes it is the same math any team can run.

You bought the same uncertainty four times.

One meeting cost is easy to calculate. Duration times attendees times loaded rate gives you a number. The deeper cost begins when the same issue keeps reappearing and still does not land.

Duplicate status loops cost time. Re-planning costs time. Follow-up sessions caused by weak ownership cost time. Delayed decisions extend those costs into blocked work, stale assumptions, and duplicated labor downstream.

This is not meeting overhead. It is duplication spend.

A team that discusses the same unresolved issue in four rooms is not aligned. It is billing the same coordination four times.

The Duplication Index

DI = (# of meetings where the same unresolved issue appears) ÷ (# of decisions produced).

DI > 1: you are buying repetition.

DI > 2: you are funding a parallel coordination system.

Most teams have never calculated this. That is the finding before the number is the finding.

Here is what duplication spend looks like in dollars. Consider one eight-person team, running two-week sprints, at a fully-loaded rate of $140 per engineer-hour. That rate is conservative once you include benefits, tooling, and higher than entry-level engineers who still count against delivery capacity. Most organizations run higher. Now assume 26.5 hours of recurring meetings per engineer per sprint. In the SAFe cycle I described earlier, several teams ran past 31. Twenty-six and a half is the low end of what is already common.

That math produces a sprint meeting cost of $29,680. Six sprints per quarter brings the quarterly burn to roughly $178,000. This is before rework, decision lag, or context-switching cost. The numbers are illustrative. The structure is not.

The exact figure will vary. The significance will not. A cost center that large should not remain culturally invisible just because it arrives as calendar time instead of invoices.

Once a team can produce that number from its own calendar, the conversation about meetings stops being an opinion exchange and starts being a budget review.

If procurement signed a quarterly contract for $178,000 that re-billed the same uncertainty every sprint, no leader would call that alignment. They would call it a broken vendor relationship and escalate it. The only reason meetings survive that logic is because the invoice arrives in time slices small enough to ignore.

The Budget Line Test

If this exact meeting structure appeared as a line item in next quarter’s operating budget, would you approve it without changes?

If not, which line item would you cut first?

If you cannot answer that, the calendar has escaped the budget process.

Three objections you will hear. Three answers ready.

“But coordination is necessary.”

Correct, and the Ledger is built to separate the spine that is necessary from the sprawl that is just expensive. The audit is about duplication, not ceremonies.

“We will lose alignment.”

If alignment requires four rooms and no decision owner, what the organization has is not alignment. It is duplication spend wearing better clothes.

“This is just a productivity complaint.”

It is a capacity allocation question. The calendar is a budget whether finance reads it that way or not. This article is asking finance to read it.

Put one sprint on a single page and the picture sharpens further. Spine on one side, sprawl on the other, priced in the same dollars.

Share

No outside number will tell you what your week costs.

No external source can tell your team its exact meeting burn rate. That should not make the exercise feel weaker. It should make it more credible. The only number that matters is yours.

How to run your one-sprint meeting audit.

One team. One sprint. Five steps. No permission slip required.

1. Pick one team and one sprint. Focus on meetings that touch in-flight delivery work. Skip all-hands and training.

2. List each recurring meeting. Name, duration in minutes, number of attendees, occurrences per sprint.

3. Compute total engineer-hours per meeting. (Duration ÷ 60) × attendees × occurrences. Round. Perfection is not required.

4. Classify Core or Layered. Core: the ceremony is doing the job it was designed for. Layered: status replay, duplicate sync, follow-up from a room that did not produce a decision.

5. Total each bucket. Any issue discussed twice gets marked in red. Any discussion without ownership gets marked again. Multiply layered hours by your loaded rate for a local cost range.

That is your local meeting burn receipt. One team. One sprint. No benchmark required.

Think before you sync.

The decision is not whether to coordinate. The decision is how. One filter, run before the calendar invite goes out, changes most of what follows.

Broadcast it in writing. Meet only if ambiguity remains. End every live discussion with a named owner, or kill the recurrence. That last clause is the one most organizations skip, which is why the sprawl grows back.

The Renewal Rule

Every recurring meeting on your calendar must declare three things to keep its seat:

Decision owner. A named person with authority to act on the output.

Output artifact. A document, decision log, or ticket the meeting produces.

Expiry date. The meeting auto-cancels unless someone deliberately renews it.

If a meeting cannot name all three, it is status theater. Write it instead.

Two weeks. One team. The ledger or the excuse.

Run the experiment for two weeks on one team. Track every recurring meeting touching delivery work. Price the total. Mark repeated issues and unowned discussions. Pick one duplicated sync to cut and one room to redesign as a decision forum.

Meeting Cost Ledger

105KB ∙ XLSX file

Download

The Meeting Cost Ledger is the one-page receipt you can screenshot into a QBR to end the meeting argument. It turns your team's recurring calendar into a sprint cost, a quarterly burn, and the Duplication Index your organization has never calculated. Fifteen minutes for one team, one sprint. No macros. Opens offline. The Executive Strip is built to print on a single portrait page without a covering slide.

Download

If a team cannot produce a two-week Meeting Cost Ledger by the end of the next sprint, the organization does not yet have a defensible basis for claiming it understands its own delivery capacity. Bring the ledger into the retro. Pick one meeting to cut and one to redesign. Measure the reclaimed hours next sprint. That is the difference between doing the pilot and shipping the outcome.

The recovery does not come from working harder. It comes from replacing synchronous status with written updates, pruning bloated standups, and routing live conversation only to decisions that require it.

Preserve the spine. Starve the sprawl.

Preserve the ceremonies that actually help work move. Become far more suspicious of repeated status layers, stakeholder reassurance loops, and ad hoc re-planning sessions that do not produce real decisions. Use the Ledger as a shared diagnostic for system improvement, not as a weapon against individuals trapped inside the system.

The same filter that decides whether a single meeting earns its hour also decides how the organization’s overall coordination pattern should be redesigned. Slack norms, documentation discipline, renewal rules, all of it downstream of the same question: does this still need a live room?

Three hours per person per week, at one eight-person team and a $140 loaded rate, works out to more than $170,000 per year. The math: 3 hours × 8 engineers × $140 × 52 weeks = $174,720. That is not a theoretical benefit. That is the budget line leadership did not know it had.

How to bring this to leadership without sounding like you hate their meetings?

The audit is only as useful as the conversation it enables. A few rules keep the Ledger a mirror instead of a weapon:

• Aggregate at team level. Bring team totals and percentages. Do not screenshot individual calendars.

• Lead with the audit, not the grievance. “We ran a one-sprint audit and found that X% of our meeting time is layered coordination. I want to test whether we can buy back some of that capacity without losing visibility.”

• Offer experiments, not ultimatums. Propose one or two specific changes and commit to re-running the Ledger afterwards.

• Treat the Ledger as a mirror. The goal is better coordination design, not blaming people for attending the meetings the system gave them.

Subscribe now

For subscribers

This is the one-page receipt you can screenshot into a QBR to end the meeting argument.

The Meeting Cost Ledger is a board-safe spreadsheet tool that reads your ceremony calendar as a budget line. It gives you a way to turn meeting fatigue into a number a director, finance partner, or VP can challenge, refine, and still use.

What it is. A branded Excel workbook with a Meeting Inventory tab, a Cost Summary tab, a Meeting-Type Breakdown split into decision/status/alignment, and a Priority View that ranks meetings by cost-to-value.

What it calculates. Sprint cost. Quarterly burn. Percentage of capacity absorbed by ceremony. Core-versus-layered split. A ranked list of the ten most expensive recurring meetings on your calendar.

What it answers. The one question most teams cannot currently answer: what percentage of your team’s capacity is currently going to meetings that do not close nor improve anything?

Scroll up to find your Meeting Cost Ledger just above the ‘Reclaiming the Coordination Spine’ infographic

The calendar was always a budget. You just stopped reading it that way.

I said early on that I’ve added meetings that felt responsible at the time. I would have called them visibility, alignment, or proactive communication. Looking back, some of them were at least partly about reassurance. I was managing anxiety in the surrounding system with another calendar block.

I have also watched one of those meetings grow beyond its original purpose. A few more attendees. A little more prep. Follow-up conversations because the first room did not quite produce a decision. Before long the meeting was no longer a coordination aid. It was another reporting layer.

Adding structure is easy. Pruning it, without making people feel blindsided or politically exposed, is the harder and more responsible skill. If your calendar this sprint looks like the one I described in the SAFe room, you’re not bad at meeting hygiene. You are funding the coordination system your organization forgot to cost. The Ledger is how you start reading it, and the Renewal Rule is how you keep the sprawl from growing back.

That is the larger case behind my upcoming book, Collaborate Better. Better collaboration is not about being nicer in meetings. It is about reducing avoidable friction before it turns into waste, delay, and preventable cost. You can learn more at CollaborateBetter.us.

Next week in Part 7: The Profit Your Sprint Plan Already Spent. The reason meeting burn feels survivable is because most resourcing models still pretend that time exists after coordination. Episode 7 names the cost of that lie.

P.S. If you had to justify your team’s ceremony calendar as a line item in next quarter’s budget, which meeting would you fight hardest to defend, and which one would you quietly let go?

Regards,

Mark 👋

Empathy Engine | Substack.Mark-Carroll.com | Evidence-Forward Product Leadership

Citations and Research Binder

3.8MB ∙ PDF file

Download

This article’s citations and research are organized as an evidence-forward binder built to support the core claims in The Agile Meeting Burn Rate and each infographic panel with source-labeled backing, adjacent basis, and explicit limitation notes. The pack follows the same underwriting standard used across Profit With Proof: strong claims are tied to the strongest admissible evidence, weaker or more rhetorical moves are clearly bounded, and the binder does not pretend a clean universal benchmark exists where the research only supports a local estimate. For this episode, the spine centers on the safest argument the evidence supports: meeting overload in delivery environments is not only a morale complaint or calendar nuisance. It can represent real resource allocation loss through duplicated coordination, fragmented attention, delayed decisions, follow-up work, and the hidden labor cost of repeated discussion that never closes. The article and artifact are therefore anchored to the core distinction that governs Episode 6: the issue is not the existence of coordination itself, but the accumulation of layered syncs around the same work after the legitimate coordination spine has already done its job. The second layer is there on purpose: evidence boundaries. This binder does not just collect what supports the article. It also marks what remains adjacent, contextual, illustrative, or article-safe only. That matters for a topic like meeting burn, where the research can support the economic relevance of meetings, interruptions, coordination overhead, and attention fragmentation, but does not provide a single honest universal threshold for when a team has “too many” meetings or a portable benchmark for the exact percentage of sprint capacity any organization should expect to lose. The binder is explicit about that boundary. It supports claims that duplicated coordination and fragmented work can create measurable hidden cost, that calendars can function as informal budget structures, and that local estimates built from actual meeting hours, loaded labor rates, repeated issue counts, and decision carryover are more defensible than borrowed headline statistics. It does not treat those findings as a license to claim a universal burn-rate percentage, a guaranteed productivity recovery number, or a one-size-fits-all cost-per-meeting benchmark. The final layer is operational reuse. The binder maps the evidence directly to the article’s core jobs and the Episode 6 visual sequence: reframing meeting load as a financial and capacity question rather than a soft productivity gripe, distinguishing the coordination spine from the layered sprawl around it, pricing repeated discussion as duplication spend rather than harmless alignment, translating calendar time into a board-safe local cost model, and equipping leaders with a defensible audit structure they can use in retrospectives, QBRs, capacity planning conversations, and budget reviews. The result is a decision-grade pack built for transparency, defensibility, and practical reuse in any operating discussion where the goal is to price what the ceremony calendar is actually buying, what it is quietly re-buying, and what capacity could be recovered by preserving the spine while starving the sprawl, without overclaiming.

Download

Previous:

More Content to Discover:

Why your workflow says finished while your output is still failing in the real world

👋 Welcome to my paid subscriber-only edition of Empathy Engine (Leader’s Dispatch). Each week I build evidence-informed tools for serious solo operators, leaders, and team leads who have moved past the hype and are now wrestling with the real operating cost of hybrid AI stacks.

In Episode 1, I separated the fantasy of cheap AI leverage from the hidden orchestration tax that eats your week. In Episode 2, I showed how the stack that promised freedom often reassigns management directly back onto the founder. Episode 3 is where that hidden management burden becomes visible in the output itself. The workflow says the task is complete. Reality says it is not done. And by now, the client can see the gap.

Research Binder: the receipts (citations + source notes) are compiled in a PDF at the bottom of this article.

The Moment Everything Looks Fine

At first, a representative told us the product passed muster. Unfortunately, as it would turn out, this person was not qualified to make this assessment. The real user community needed less than a week to show us we had solved the wrong problem beautifully.

You already know this feeling. You run the workflow on clean inputs. The output looks polished. The formatting is tight. The system returns a satisfying signal. Nothing throws an error. The task moves to done.

Not to approve it. To ask why a competitor you both know well is missing from the brief entirely. Or to correct a fact the agent stated with complete confidence and got completely wrong. Or to say, in two careful sentences, that the deliverable addresses a problem they stopped having six months ago.

You spend the next two hours on cleanup that should have been impossible. The task was marked complete. The client found the gap in under three minutes.

Operators who have lived this describe the same structural pattern. In production, the agent does not crash. It degrades silently. Everything looks fine until you check the output against what the user actually needed. The workflow said done. Reality said otherwise.

This is not a rare failure. It is the pattern hybrid workflows produce at scale, quietly, without error messages, until someone outside the system touches the output.

The failure that the client sees is only the surface. Below it, the same two structural causes appear in every case.

Approval mismatch and invisible judgment calls are the underwater mass. They are what make the gap structural rather than accidental. The sections that follow map each one.

The Gap Between Completed and Done

“Completed” is a system signal. “Done” is a reality signal. Hybrid workflows fail when they mistake the first for proof of the second.

That distinction sounds technical until you have paid for it. A task can be generated correctly, routed correctly, reviewed internally, and approved without friction, yet still fail the moment a real human depends on it. The client can see the gap. The customer can feel the mismatch. The downstream user can discover, within minutes, that the thing they received solves a cleaner, simpler, more fictional version of the problem than the one they actually live with.

“Completed” is one of the most dangerous words in a hybrid business. Requirements research consistently shows that internal completion signals diverge from external usefulness signals most sharply at exactly this point, where approved becomes assumed rather than verified. It sounds objective, responsible, and final. In practice it often means something much narrower: the workflow reached its stopping point. The visible steps were satisfied. The machine stopped talking. None of that proves the output can survive contact with reality.

Completion Theater

Completion theater looks like productivity because it borrows the surface cues of disciplined work. Tasks close. Dashboards stay green. Milestones appear to move. Internal status language remains reassuring. The work seems to flow.

Then the rework bill arrives. And it arrives later, when the cost is higher and the explanation is uglier, because the delay is exactly what makes completion theater so dangerous.

If the work broke loudly and immediately, the system could correct itself faster. Instead, hybrid workflows often produce a quieter failure mode. The output leaves the system looking composed. The client sees it before the operator sees the flaw. The user works around it before the founder learns it solved the wrong problem. The correction arrives downstream, after the invoice has been sent and the relationship has absorbed the gap.

Every time completion theater wins, you are pre-authorizing rework you will not log honestly later. The workflow records productivity. The calendar records cleanup. The founder feels busy, the client feels uncertainty, and the real cost gets distributed across small fixes that are only small when measured one at a time.

That cost accumulates in a sequence most operators recognize only after they have run it once.

The 79% figure is not a warning about bad operators. It is a finding about where validation gets removed from the system. That removal is designed in, not accidental.

Why Hybrid Workflows Create This Gap

This is not a carelessness problem. It is a design problem. Better prompting helps at the surface level. Better communication helps. Better specifications help. Those things reduce the frequency of the gap. They do not solve the deeper one.

The deeper problem is that hybrid workflows are optimized to confirm internal completion conditions rather than external usefulness conditions. They are built to recognize when the visible sequence has run, not when the work has actually earned trust. Most operators begin by thinking they need clearer instructions. Then better prompts. Then more review. What they usually need is a different standard for what counts as finished in the first place.

Research across complex project environments consistently finds that defects caught after internal approval cost substantially more to fix than those identified upstream. The cost is not only time. It accumulates in trust erosion, silent workarounds, and the downstream labor that never gets logged honestly. Industry-wide analyses put the majority of rework cost at the requirements and validation layer, not the implementation layer. The solo version of that pattern is paid in weekends and client trust instead of budget lines.

Share

Read more

How to calculate the real cost of software your teams refuse to adopt

👋 Welcome to this week’s 2nd edition of Empathy Engine. Every Tuesday, I publish a new article for paid subscribers first, then unlock the full piece for everyone late Thursday morning. Each week, I turn product leadership friction into practical tools, sharper language, and more defensible decisions.

You can learn a lot from the part of a meeting nobody writes into the notes. Not the polished answers. Not the architecture slide. The glances. The timing. The moment when the people who will actually have to live inside the workflow stop asking whether the tool is good and start calculating how they are going to survive it.

Previous article in this series: Episode 4 (The Catastrophic Cost of Looking Safe)

I once watched two engineers at the front of the room exchange the look that said they had already made peace with the workaround. The vendor said “change management” three times in twenty minutes. Nobody in the room said anything about the six workarounds already running on the team’s local machines.

The demo was excellent, btw. The rollout plan was thorough. The contract was signed. Ninety days later, most of the team is still getting the work done somewhere else.

That is the part leaders keep under-pricing. The tool is live, the licenses are active, and the dashboard says adoption is on track. Meanwhile, the engineers have already made a quieter decision. They are still delivering. They are just not delivering through the system the organization bought.

A VP of Engineering approves a six-figure developer productivity platform or greater. The evaluation is serious, procurement is careful, the vendor clears the security review, and the launch plan arrives with milestones everyone can admire without embarrassment. The first team uses it, the second team tolerates it, and by week six the workarounds begin to multiply in the usual places. A script here, a Slack handoff there, an old local ritual revived because everyone trusts it more than the official path.

By day ninety, adoption sits at twenty-two percent. The remaining seventy-eight percent of the engineering team has not stopped working. They have simply routed around the tool. The platform is still being paid for, and it is still being ignored.

Here is what the boardroom was measuring. Here is what was already operating underneath it.

The Adoption Mirage

Most organizations read this as a soft failure. Training needed reinforcement, change management needed improvement, leadership needed to drive adoption with more conviction and cleaner messaging. That reading is too small. This is not a software success story with a communication problems hanging off the side of it. This is an operating cost story.

The organization bought a tool. The engineers kept buying time somewhere else. That gap isn’t so much awkward as it is expensive.

Most leaders think software waste begins when a tool is bad. A clumsy interface, poor reliability, weak features, obvious mismatches with real use. Sometimes that is true. More often, the waste begins when a tool is good enough to buy and too friction-heavy to adopt.

That is the Integration Penalty

The hidden cost of software is not the invoice alone. It is the gap between what the company bought and what the team actually uses. Leaders tend to treat those two things as if they should converge naturally over time, as though deployment will mature into adoption if everyone remains patient and polite for long enough. In practice, that gap often widens in silence while the budget continues to treat the purchase as settled value.

This Is Not a Change Problem

Purchase and adoption are not the same event. The purchase decision measures capability, the rollout plan measures deployment, and neither one measures whether changing the workflow is worth the pain to the people doing the work. A vendor can win the evaluation and still lose the daily route.

That is the category mistake most organizations keep making. They assume software adoption failure is a change-management problem. It isn’t.

Software adoption failure is not a change-management problem. It is a friction-measurement problem.

The workaround is not a behavioral failure. It is a measurement. It is the team’s honest accounting of where the cost-benefit calculation actually landed. The official route cost more than it delivered. The shadow route cost less and delivered more. The team made a rational decision. The organization just was not watching the right ledger.

The official workflow and the real workflow diverge at a single friction point. Here is the exact moment the ghost town is created.

The Workaround Is the Proof

Friction is not irrational resistance. Friction is evidence. It tells you that the integration cost exceeds the perceived benefit, and it does so more honestly than a launch retrospective ever will. Teams do not quietly preserve side channels, personal scripts, duplicated tools, and manual handoffs because they enjoy administrative mischief. They do it because the unofficial route is protecting something they care about more than compliance. Usually that something is speed, clarity, or control.

That is why the workaround matters so much. The workaround is not a side effect. The workaround is the proof that the official route lost to the unofficial one. The moment the team builds a shadow path and keeps using it, the organization is no longer funding one workflow. It is funding two.

That is the penalty hiding inside the purchase. Everyone in the chain can still look competent while this happens. Procurement did its job. Engineering leadership approved the tool in good faith. IT and operations can point to deployment progress and license utilization. Finance can track contract value and renewal dates with admirable discipline. None of that is fake work. Nor does any of it answer the harder question.

The system is optimized for purchase, not adoption. Procurement ends at signature, and the adoption problem starts the day after. Vendors are strongly incentivized to sell, and almost nobody inside the organization is equally incentivized to measure whether the purchase actually changed the workflow in a way worth funding. That gap between incentives is where the penalty lives rent-free until someone decides to price it.

Your best engineers did not rebel against the platform. They did what engineers always do when a system creates more drag than it removes.

What the Dashboard Cannot See

The organization did not buy software. It bought a second workflow and forgot to price the first one.

That is the verdict. Everything else in this article exists to help the reader make that verdict financially legible. Not universally, not theatrically, and not with fake precision dressed up as proof. Locally. Defensibly. In the language of the next renewal meeting.

The tool survives because it looks official, the workaround survives because it works, and leadership is left with a dashboard that reports one reality while the team lives inside another. The organization now has a polished surface story and an underground operating system. Both cost money. Neither is counted honestly.

The dashboard measures the visible tip. Everything that actually ships the work is living below the waterline, unmeasured and unmaintained.

Share

Pricing the Hidden Route

This is where the evidence posture matters. There is no clean, universal benchmark for the integration penalty as such. The research supports the existence of hidden organizational costs when work routes around official tools, especially in the form of duplicate coordination, maintenance overhead, fragmentation, and time loss. What it does not support is a neat industry-wide number you can borrow and apply to your own environment without blushing when finance asks where it came from.

That does not weaken the argument. It disciplines it. In this series called Profit With Proof, discipline is not optional. The goal is not to prove that every organization pays the same penalty. The goal is to show the reader how to estimate their own exposure using numbers they can actually defend in a room with consequences. The smarter move here is not courtroom precision. It is decision-grade honesty.

So start with the number you actually need. Not what does failed adoption cost in general, but what are we still paying because the team routed around this tool? That is the question the procurement process never answered and the renewal cycle usually avoids answering unless someone forces it into daylight.

The structure can stay simple. Begin with annual license cost. Add the current adoption percentage. Estimate the engineer hours spent each week maintaining or using the workarounds that replaced the official route. Then apply an average hourly engineering cost. Those four inputs will not give you a universal truth. They will give you something more useful: a local estimate (keep reading, you’ll find my Adoption Friction Calculator below)

Three Diagnostic Checks Before Renewal

The first number is the cost of non-adoption. If the annual license cost is, say, $200,000 and actual adoption is twenty-two percent, then seventy-eight percent of that spend is not funding the workflow you thought it was funding. That is $156,000 per year paying for a route the team already abandoned.

The second number is the cost of workarounds. Ten engineers. Four hours a week. One hundred and fifty dollars an hour. That is $312,000 a year in shadow labor. Your dashboard does not contain that number. Nobody budgeted it. Nobody approved it. It arrived anyway, spread across a thousand small decisions to use the script instead of the portal.

The third number is the total integration penalty: the combined burden of paying for the official route and nursing the shadow one. In this illustration, that is $468,000 in annual exposure on a $200,000 contract. The tool did not cost $200,000. It cost the license plus the quiet labor required to bypass it.

That is why half-working tools are often more expensive than obviously failed ones. A total failure usually gets cut. A half-working tool justifies its existence enough to survive review while still pushing real work into un-tracked detours. It can remain alive in the contract long after it has died in the workflow.

If you want a fast pre-renewal check, use three questions. What percentage of the paid route is actually being used in daily work? How many hours each week are being spent on the shadow route that replaced it? What would leadership decide differently if those two numbers appeared on the same slide? If the answer to the third question is quite a lot, then the tool has already stopped being a workflow decision and become a portfolio problem.

Run these three checks before your next renewal. If you find these workarounds in place, you are funding adoption theater while real work routes underground.

What Changes When You Stop Pretending

This is also why leaders underestimate the cost. The spend is split across categories that do not naturally reconcile. License cost sits in procurement or platform budget. Workaround cost sits in engineering time. Friction sits in nobody’s ledger at all. The organization gets three partial truths and mistakes their coexistence for visibility.

The mature question is not :Did we deploy it?” The mature question is “What are we still paying because the team routed around it?” That is the question that moves the topic out of change language and into budget language. It is also the question that gives leaders a chance to regain control of a conversation they have been losing with comforting metrics.

That is the role of the artifact in this episode. The Adoption Friction Calculator is not supposed to be a grand system of record or an executive toy with twenty inputs and a false sense of authority. It is supposed to be a board-safe numbers strip. Four core inputs. Fast completion. Clear outputs. Enough structure to help a reader enter a renewal or portfolio conversation with something stronger than frustration and something less fraudulent than a borrowed benchmark.

Adoption Friction Calculator

26.5KB ∙ XLSX file

Download

The Adoption Friction Calculator turns four inputs into the one number your renewal conversation is missing: the total annual penalty of funding an official platform and a shadow workflow at the same time. It takes under three minutes, opens offline, and produces a figure defensible enough to put in a board packet. The default values alone are worth opening it for.

Download

Audit the Real Workflow

The point is not to produce a definitive number. The point is to remove the organization’s ability to keep pretending the hidden route has no cost. Once that number exists, even as a bounded estimate using local inputs, it becomes harder to admire the dashboard without asking what it failed to measure. Visibility does not solve the problem by itself. It just dramatically reduces leadership’s ability to lie to itself with confidence.

That is the larger tension beneath this entire episode. The contract says the platform won. The workflow says it lost. If those two truths are allowed to diverge for long enough, the budget eventually tells the truth in a voice nobody enjoys hearing.

If your workflow changed less than your vendor narrative did, the savings are fictional until proven otherwise. A tool that lives in the contract and dies in the workflow is not a productivity gain. It is an unmeasured tax.

That is also the broader argument behind Collaborate Better (to be published later in 2026). Better collaboration is not about being nicer in meetings or admiring cleaner diagrams. It is about reducing avoidable friction before it turns into waste, delay, and preventable cost. When organizations force people to choose between the official route and the functional one, the cost never disappears. It just moves somewhere leadership is not looking yet.

If you are walking into a renewal meeting next quarter with a green dashboard and a quiet suspicion that the number on that dashboard is not the number that matters, this is the article I wish someone had handed me the first time I sat in that room. You are not imagining the gap. You are just the first person in that meeting who decided to price it.

Subscribe now

A Meeting Killed Your Profits (Next article Episode 6) asks a question most organizations should have priced years ago: what exactly is your ceremony calendar buying, and what is it costing every quarter it goes un-audited? That episode moves from software non-adoption into a different kind of organizational overhead, one that people defend one meeting at a time and almost never price as a system.

P.S. If your team has routed around a tool leadership still considers adopted, what exactly made the workaround feel safer, faster, or more honest in the moment you chose it?

Regards,

Mark 👋

Empathy Engine | Substack.Mark-Carroll.com | Evidence-Forward Product Leadership

Citations And Research Binder

3.78MB ∙ PDF file

Download

This article’s citations and research are organized as an evidence-forward binder built to support the core claims in The Integration Penalty and each infographic panel with source-labeled backing, adjacent basis, and explicit limitation notes. The pack follows the same underwriting standard used across Profit With Proof: strong claims are tied to the strongest admissible evidence, weaker or more rhetorical moves are clearly bounded, and the binder does not fake certainty just because a cleaner narrative would be easier to market. For this episode, the spine centers on the safest argument the research supports: when work routes around official tools, organizations can absorb real hidden costs through duplicate coordination, maintenance overhead, fragmentation, shadow systems, and time loss, even when dashboards still report healthy adoption, rollout progress, or visible compliance. The article and artifact are therefore anchored to the core distinction that governs Episode 5, purchase and deployment are not the same as workflow adoption, and visible tool usage is not the same thing as real operational dependence. The second layer is there on purpose: evidence boundaries. This binder does not just collect what supports the article. It also marks what remains adjacent, contextual, illustrative, or article-safe only. That matters for a topic like software non-adoption, where the research supports the existence of shadow-workflow costs and friction-driven workarounds, but does not provide a clean universal benchmark for an “integration penalty” that can be lifted whole into any organization. The binder is explicit about that boundary. It supports claims that shadow systems and unofficial routes can create real organizational drag, that workflow friction can distort adoption in ways dashboards miss, and that local estimates built from license cost, usage reality, and workaround labor are more defensible than borrowed industry averages. It does not treat those findings as a license to claim a universal non-adoption percentage, a guaranteed ROI from tool consolidation, or an exact per-team benchmark for hidden software waste. The final layer is operational reuse. The binder maps the evidence directly to the article’s core jobs and the Episode 5 visual sequence: reframing low adoption as a cost and visibility problem rather than a soft change-management story, showing how official dashboards can measure the surface while real workflow shifts underground, pricing the gap between the contracted tool and the shadow route that actually ships the work, diagnosing the political and organizational incentives that let dual workflows survive, and giving leaders a board-safe way to estimate local exposure before a renewal, QBR, or portfolio review. The result is a decision-grade pack built for transparency, defensibility, and practical reuse in renewal prep, platform reviews, budget conversations, leadership debates, and any operating discussion where the goal is to price the gap between what the organization bought and what the team actually trusts, without overclaiming.

Download

Previous:

More Content to Discover: