One service-level indicator, defined before the data arrives: successful governed completions divided by eligible workflow instances, over a rolling 28-day window. Every term is load-bearing. Completions, not logins: instances of the target workflow finished through the governed path . Eligible instances, not enrolled users: the denominator comes from an eligibility ledger of cases the tool should have handled, which forces the instrumentation that makes the whole thing decidable. That means a shared case ID across the tool and the legacy path, and mutually exclusive terminal states per case: completed-governed, abandoned (with a timeout rule), manual-fallback, exception. If you can’t produce that event model, you don’t have an adoption problem yet; you have a measurement problem, and it’s cheaper.

Around the SLI, guardrails and diagnostics, not co-equal targets. User reach, meaning eligible users with at least one opportunity who used the tool, guards against coverage carried by three enthusiasts. Repeat use, measured only among users with eligible opportunities in both periods and windowed to the workflow’s natural frequency, separates habit from novelty; a fixed week-five cohort is arbitrary for a monthly workflow. Abandonment rate says where to investigate, as in, the tool wins the opening and loses a specific step, without claiming to say why. And the quality set (error rate, rework, cycle time, exceptions) holds the line the adoption number must never be allowed to buy.

Which is the objection that deserves the most respect: put adoption on someone’s review and recommend deleting the old button, and you’ve written the recipe for Goodhart. Two rules keep the SLO from being gamed. The target belongs to the tool’s owner, never to the users; adjusters are scored on claims quality, not assistant usage, so the owner can only move the number by making the governed path genuinely cheaper. And coercive defaults, such as removing the legacy button for covered cases, are permitted only while every quality guardrail holds; the moment rework or exceptions rise, the default reverts and the breach conversation is about the tool. Under those rules, persistently low adoption becomes what it sometimes is: the users correctly rejecting a tool that isn’t good enough, now visible as such instead of relaunched annually.

Then the part that makes it an SLO rather than an OKR: the breach protocol, agreed in writing at rollout. A floor, say 60% coverage with guardrails green (your numbers will differ), and a budget: two consecutive windows below the floor triggers the review, no discretion. The review has two exits. Exit one is a time-boxed remediation hypothesis: a named change to the workflow, defaults, or tool, an owner, a budget, a checkpoint date, guardrails unchanged. Exit two, taken automatically if the checkpoint misses, is decommissioning. Licenses lapse, the workflow reverts, the ledger closes. What breach can never buy is the third exit every failing tool currently takes: a relaunch email and another training session. Training is a legitimate remediation hypothesis exactly once, with a checkpoint like any other. Metrics without a breach condition are decoration.

The renewal meeting this was built for then gets its finance line: spend per accepted business outcome on the governed path, against the same figure for the legacy path. Not spend per completion, which a worthless completion satisfies. With McKinsey’s August survey putting about a fifth of organizations at cost-constrained AI use, the renewals that survive should be the ones that win that comparison with the breach protocol attached. Adoption is necessary for renewal, never sufficient. The tools that clear the bar are capabilities. The rest were licenses.

Self-reports both, so start with the explanations that require no one to be wrong. Measurement lag: EBIT is a long way from task speed, and enterprise technology historically takes a year or two to show up there. Absorption: the gains are real but spent, on adoption costs, on quality, on scope growth, or competed away in pricing. Inflation: people overestimate their own speedup. All three are live, and a survey can’t separate them. What a survey can do is tell you where to point instruments, and the instruments can separate them, because delayed conversion, spent gains, and destroyed gains leave different marks on a workflow’s queues.

Here is the mechanism worth instrumenting for, named so it can be falsified. Call it the handoff tax: an individual speedup converts to enterprise throughput only if the downstream stage absorbs the extra flow, and where it doesn’t, the gain converts to queue instead. The signature is specific. Task time down at one stage, end-to-end throughput flat, and waiting time or rework rising at a nameable transition. A developer produces changes twice as fast into a review process sized for the old arrival rate. A team drafts three proposals in the time one took, into a decision meeting that still meets weekly, and decision latency was a P&L variable before the arrivals tripled. Output volume rises into fixed verification capacity, so either backlog grows or scrutiny quietly falls. If the tax is your problem, those queues exist and are growing. If task time fell and no downstream queue grew and throughput still didn’t move, the tax is not your problem, and this diagnosis is wrong for your org. That’s the test, and it cuts both ways.

The survey offers one more clue, to be handled with care: 47% of mid-level managers and individual contributors report at least one negative AI-related strain, against 31% of executives and senior managers. That is not evidence that the middle layer causes the gap; strain could equally measure proximity to rollout churn or distance from insulation. Treat it as a searchlight, not a verdict. The layer reporting the most friction is the layer where handoffs, reviews, and exceptions live, which is reason to put the instruments there first, and no reason to blame the people improvising unpaid pipeline rebalancing.

The instrument itself is one workflow, traced. Pick a single customer-valued output. Timestamp five events per item: intake, draft-ready, review-start, exception, done. Four weeks of data gives you arrival rate, service rate, queue age, and first-pass yield per stage, before-and-after if you have history. The tax, if present, is legible in one picture: the stage where AI landed shows falling task time, and some downstream transition shows rising queue age. Then run the confirming experiment. Add capacity or change policy at that one transition, whether review staffing, the WIP limit, or the decision cadence, and watch end-to-end throughput. If it moves, you found where the 80% was leaking. If it doesn’t, reject the diagnosis and go test measurement lag, which is the serious competitor.

What makes this a leadership post rather than a queueing tutorial is who owns the fix. Rebalancing a pipeline after the tools changed its arrival rates is a management act: deciding where freed capacity goes, which is currently in nobody’s job description and therefore happens by default, and the default is queue. Unallocated speedup defaults to queue. So allocate it, into the constraint stage, into verification capacity that buys trustable autonomy , into fewer things finishing sooner. The decision rule for the next QBR fits in one sentence: individual gains are inventory until the next stage absorbs them, and inventory doesn’t show up in EBIT. Queues do.

One year-pair from one survey proves no trend, and I won’t pretend it does. What it provides is a warning label for that artifact. The argument for that label isn’t the survey; it’s the mechanism the survey is consistent with, and the mechanism is old.

A job is a bundle of tasks, and automation eats tasks, not bundles. The model drafts the letter; a human still decides the hard cases, works the exception queue, answers for the output, and does the coordination that never appeared in any task inventory. What disappears is a percentage of each person’s day, scattered, and scattered percentages don’t concentrate into a removable position by themselves. Concentrating them requires reorganizing the work, which is exactly the slow institutional labor pilots skip and diffusion demands . Meanwhile the same tools generate new tasks: review of machine output, evals and tripwires , a new incident class. The ledger has two columns, and capability forecasts read only one.

Note what this does not contradict. A senior driving agents can genuinely out-ship a senior and three juniors ; demonstrated substitution inside a bounded workflow is real, and the arithmetic pays this quarter. The gap is between that observation and an enterprise-wide reduction inferred from it. Bounded substitution is evidence about the workflow you measured. The org-wide cut extrapolates it across bundles nobody has decomposed, and that extrapolation is the step that came in at under half.

Now the strongest case for the other side: staffing has lead times. Hiring pipelines, budget cycles, and attrition planning all run on forecasts, and a rule of “no workforce planning until proof” guarantees overstaffing in any world where the cuts eventually arrive. Right. So give the forecast the jobs forecasts can hold: scenarios, contingent requisitions, replacement-approval gates, slower backfill on roles the models plausibly thin. What the forecast doesn’t get to govern is the irreversible acts: the layoff, and its quieter twin, the booked saving that finance builds next year on. A booked-but-unrealized reduction is corrosive in a specific way. Teams run short against savings that never materialized, absorb the new verification work uncounted, and when the number misses, the whole program wears the failure, which the bench you stopped filling then compounds. The org that cuts on forecast pays twice: once in the shortfall and once in the rebuild.

So write the promotion rule from scenario to plan, per workflow, decidably. Task elimination observed at representative volume: this queue or review step no longer routes to humans, measured across a full cycle’s case mix, including the bad weeks. Service levels held against named tolerances (error rate, latency, escalation volume) over a fixed window agreed before the change, not after. And the residual netted out: total human touch-time on the workflow, including the new review, exception, and coordination work the change created, down by enough concentrated capacity to equal actual positions rather than confetti. Three tests, thresholds written in advance. A workflow that passes them supports a reduction through attrition with a clear conscience. A workflow that hasn’t been run through them supports a scenario, and the deck should say which one it’s holding.

The board will read about AI layoffs weekly and ask why yours are slower. The answer is the survey’s own shape plus one question: expectations up seven points, reported declines at under half the forecast rate, so which side of that gap should our balance sheet be on? Throughput, measured per workflow , will tell you when the work has actually disappeared. Until it does, the saving is a hypothesis, and hypotheses don’t belong on the income statement.

A competency matrix describes skills: “demonstrates growing judgment in reviews.” Nobody can act on it, because it grants nothing and nothing tests it. What apprenticeship actually runs on is a contract per rung, four clauses, written where the team can read them. Permission: the real work this person may now do, with its boundaries. Supervised, dual-controlled, rollback-limited, but real. Evidence: the artifacts that show they’re doing it well, countable ones. Reviewer: the named person whose corrections they receive, because feedback with no owner is noise. Promotion rule: a decision rule specific enough that two managers reading the same record would make the same call. Miss any clause and you don’t have a rung, you have a vibe, and vibes are what apprenticeship consisted of when juniors learned by osmosis from work that no longer exists.

This is the contract I’d write for the first rung, in full, because the format is the point. Permission: first-pass review of agent-generated changes, verdict delivered as a written rejection or approval with reasons; no merge authority. Evidence: the rejection log, and a miss rate, meaning defects the apprentice approved that their reviewer caught, measured over a sample. Reviewer: a named senior who re-reviews a fixed sample, weighted toward approvals, because the dangerous failure here is the miss, not the false alarm. Promotion rule, concretely: thirty sampled reviews across six weeks, zero critical misses, noncritical miss rate under an agreed bar, sign-off from two seniors rather than one. Numbers your org would tune. But numbers, or the rung isn’t checkable.

How can juniors catch defects in code they’ve never been able to write? Alone, they can’t, which is why rung one has an entry gate as well as an exit gate. Before their verdicts count, the apprentice calibrates on seeded cases: changes with known defects, where the job is to find the flaw, reproduce it with a failing test, and propose the repair, shadowing a senior’s real reviews until their recall on the seeded set clears a threshold. Review-first learning works only when someone builds the reviewer’s mental model deliberately; the seeded set is that construction. It also answers whether this rung reduces senior load. Initially it doesn’t, since sampled re-review plus teaching costs more senior minutes than it saves. That’s an investment with a measurable payback: track senior review-minutes per merged change and escaped defects, and expect the crossover in months, not weeks. The review queue can afford it ; the bench can’t afford its absence.

The later rungs get the same four-clause treatment, and their order can flex by job family. Owned failure: one production failure mode end to end (alert, runbook, rotation, postmortem) under dual control until an incident shows the senior was informed rather than needed. Defended decisions: real design calls, written with alternatives and costs, scored when made, with assumptions explicit, rollback stated, escalation named, and production outcomes used as later calibration rather than the gate, because outcomes carry luck in both directions. Authored verification: the eval set and drift tripwire for something new, the benchmark only your org can build . Clearing that last contract is the crossing the whole pipeline exists to produce: unsupervised ownership, the numerator in the replacement-rate metric I argued you should track against senior attrition.

And write the failure clause with the same discipline, because a curriculum that can’t fail people honestly fails them dishonestly. An apprentice stalled at a rung gets a diagnosis first (wrong rung order for their role, wrong reviewer, insufficient reps), then a changed assignment and a documented reassessment, before anyone reaches for performance machinery. The contract cuts both ways: it’s how they know exactly what’s asked, and how you know exactly what you owe them. Four clauses, per rung, on one page. Everything else is a vibe.

Seniors are grown, not hired, and the lead time runs three to five years. The bench drains on its own schedule whether or not you refill it. Put rough numbers on it; your own will differ, but the shape holds. Attrition, retirement, internal moves, and poaching run something like 10 to 15% a year in most engineering orgs. Hold fifty seniors and you lose about six annually just standing still. Staying flat means minting six replacements. A junior who can own a system unsupervised takes around four years to produce, and maybe half of any cohort gets there. Work it backward and a steady bench needs something like a dozen new apprentices entering every year, which means several dozen in the pipeline at any time. Cut intake to zero and nothing visible happens for two years. In year three your incident reviews route to a thinner and thinner group, and by the time the gap reaches your metrics the fix is already three years out.

Grant the strongest version of the counterargument: agents probably do lower how many seniors you need per unit of output. That is a claim about demand. Insolvency is a claim about supply, and a falling demand curve does not repair a severed supply line. Drop from fifty seniors to forty and you still lose five a year, and you still have to source them.

From a market. That is what the seniors-plus-agents story leaves out: it balances only if someone, somewhere, is still producing seniors. When every firm runs the same model and cuts its juniors, the market for proven seniors thins at the exact moment everyone turns to it. You stop growing the asset and start buying it on a market you helped drain , as a price-taker, against everyone’s identical bet. Buying stays cheap only while the supplier still exists.

Why not go further and bet that agents absorb senior judgment too, skipping the pipeline entirely? Name that wager, because it is the one you are placing, and it loses on accountability. When an agent ships a bad migration, a human signs for it to a regulator, a customer, or a board, and the signature does not delegate to a model. Reliability sets the autonomy ceiling ; a human verifier sets the accountability one. You will always need people trusted to say the agent is wrong here, and that trust is earned only by doing the work on something that bites when you get it wrong.

That settles what juniors should be doing now that the code they used to learn on is gone. The rung moves up the value chain, onto the work the model cannot own, and that work is real and nameable: first-pass review of agent output, delivered as a written rejection with the reason; one failure mode owned end to end, on-call included; a design decision defended out loud to someone senior; the eval that proves the thing actually works. The work you automated away from juniors is now the work you have to teach them to supervise. Route the review load your seniors resent through the juniors first: the junior makes the call, the senior corrects it, and the tax becomes the curriculum. Run deliberately, this is the pipeline that mints those six replacements a year; left to chance, it is the pipeline you let lapse.

None of this surfaces in headcount, which lags . Watch a ratio instead: senior replacement rate against senior attrition rate, meaning how many engineers crossed into unsupervised ownership this year against how many seniors you lost. Below one, you are spending seniority faster than you produce it, and the income statement will read excellent the entire way down. The agents pay off this quarter. What matters is whether anyone is still tracking the rate at which the bench refills, and finance will not put that number on the table on its own.

A claims team pilots an assistant that drafts the first-pass adjustment letter. The trial is clean: on a held-out sample it produces a usable draft for 78% of cases, and the two adjusters running it cut letter-writing time roughly in half. The deck circulates. Everyone agrees it works. Eight months later, fourteen adjusters hold a license and nine have opened the tool twice. The default is still the old template button in the case system, because that is the button that has always been there.

The model did not fail. What failed is the work nobody scoped: moving a proven capability from “passes a trial” to “is how the job is done.” That is the distance between a model that performs and an organization that operates differently because of it, and it is where the money went.

Most companies running pilots have a graveyard of these . The audit is cheap: list every pilot that cleared its technical bar, then mark which daily workflow each one actually changed. The blanks are your real result, and they cluster for one reason. A pilot gets scored on whether the model works, which answers a question nobody important was asking. The question that pays is whether work will route through it next quarter.

Three things have to move for that to happen, and they fail as a set: ownership, cadence, and incentives.

The first two are org-chart edits a director can make before lunch. Ownership leaves the pilot team for a named operator whose performance review includes the adoption number. Cadence puts that number into a standing review , so it is read on a fixed clock rather than admired once. Do only these and you get a well-governed tool nobody uses. That is the claims pilot’s eight months exactly: a sponsor, a slide in the monthly deck, and usage in the low twenties, because the cheapest action on screen was still the old one.

Incentives is the lever everyone hand-waves as “drive adoption,” and it is the only hard one, because “path of least resistance” is not a mood. It is three concrete edits to the screen and the scorecard.

The first is to delete the old path for the cases the tool handles. The highest-leverage move is removing the legacy button: take the manual “insert template” action out of the case screen, so drafting through the assistant is the one-click route and the old way costs four extra clicks. That is not the same as deleting the template for the 22% the assistant can’t draft; those cases still route to it. Adoption is a UI default before it is a culture.

The second is to move the measured metric. Stop scoring adjusters on raw letters closed per day and start scoring first-pass acceptance, a number the assistant moves and the manual path does not. Now the comp-relevant metric rewards the new behavior instead of being neutral to it.

The third is to make the old path visible when chosen. The two holdouts still writing by hand show worse handle time on that same scorecard, which is a line in the weekly review, not a policy memo.

Incentives gets skipped because it is the expensive lever. It means touching a scorecard people are measured on, deleting a tool they are comfortable with, and eating the complaints when the familiar button is gone.

So write the pilot’s exit criteria as operating changes before it starts, not model targets after it ends:

• Which human task stops, and who stops doing it?
• Who owns the capability in production, with their name on the adoption metric?
• Which existing meeting reviews it, on what clock?
• What is the old path, and what is the plan to remove it for the cases the tool covers?

None of those mention accuracy. A pilot that cannot answer them is funding a build and assuming diffusion is free; it never is. The work that closes the gap is moving a capability from impressive to load-bearing : name the owner, put the adoption number in a standing review, and remove the old step for the cases the new one covers, until the assistant is the route people actually take.

So make those three answerable in calm, before the next bad week instead of during it. Who is a named owner per production system with an explicit halt path, not a committee that assembles after the damage. How fast is the elapsed time from the first bad signal to the system actually pulled, and that only shrinks if the halt is rehearsed rather than improvised. At what cost is the incident threshold agreed in advance: which incidents reach the room, and what the firm is willing to forgo to pull the cord. Wire that into the cadence you already run, a short standing report and an owner who shows up, and you have governance without bureaucracy . It is the lever a board can actually pull.

The full apparatus has four parts: a named owner per production system, an explicit halt path, a rule for which incidents reach the room, and a failure rate measured the same way every quarter. The first three are easy to recite. The failure rate is genuinely hard, and it is exactly where boards get fooled.

The fooling arrives on a slide: the AI system’s error rate fell from 2.1% to 1.7%. Heads nod, the program looks healthy, the meeting moves on. Both figures are closer to fiction than measurement, and a board that cannot say why has not overseen anything. It has been shown a chart.

Why “the same way every quarter” is the hard part

A non-deterministic system has no error rate to read off a gauge. The same input yields different outputs. The model version changes under you, the traffic mix shifts, and the humans grading “wrong” quietly revise what wrong means. So 1.7% is the product of a dozen choices: which outputs were sampled, how many, against what rubric, judged by whom. A defensible number pins all of them down.

• A frozen definition of failure, written as a rubric a grader applies, with inter-rater agreement tracked so the bar does not drift loose over time.
• A fixed sampling rule: N items drawn fresh from live traffic each quarter, never a static test set. The moment engineers know which prompts are scored, they teach to the test and the rate detaches from reality.
• A confidence interval next to the point estimate. On a few hundred samples, 2.1% to 1.7% sits inside the noise band, and presenting it as progress is the lie the slide tells.
• A re-baseline rule: when the rubric or the sample changes, run old and new on one overlap quarter and report both, so the trend is not an artifact of moving the goalposts.

One trap catches the diligent. A frozen golden set goes stale ; as the world drifts it stops resembling live traffic and starts flattering you. The defense is to watch the gap between your scored sample and a fresh live sample, and treat divergence as a signal the metric is lying before the system is. A board does not run this machinery; that is the IC’s standard to meet. The board asks the questions that prove someone did, and refuses a number that cannot answer them.

Which is why the usual oversight advice underwhelms. Get an AI expert on the board, run a literacy seminar, issue a principles memo: none of that tells a director whether 1.7% is real, and none of it shortens the halt. Education is a fine supplement and a dangerous substitute. The failure it breeds is specific, a roomful of directors who can define the risk fluently and still cannot intervene when it walks in.

What the machines give back is not room to ship more. It is the chance to attempt work that used to need a company, to serve people the old cost floor priced out, and to spend a working life on the part of the work that is worth a life. A company that spends the surplus on volume has been handed a decade and bought a quarter with it.

Everything here turns on one thing. The work is how people get made. People are not how the work gets made.

What I value

Verifying over producing.

Earned autonomy over granted autonomy.

Enforced limits over declared intent.

Doing the work over approving it.

Judgment that compounds over output that repeats.

Apprenticeship over throughput.

Problems surfaced over progress reported.

Independent sources that can disagree over one that cannot be wrong.

I want the right column too. What moved is where the scarcity sits.

How I work

A process nobody can check is not automated. It is unsupervised. The check comes before the thing it protects: the test before the pipeline, the alarm before the deploy, the dry run before the announcement.

Verification rises with the consequence of being wrong. Produce enough to learn from someone real, verify enough to trust an act that repeats or cannot be taken back, and where the work decides nothing, do neither.

Autonomy is earned with evidence and taken back the same way. For machines it attaches to a step. For people it widens across a domain as their judgment earns it, and narrows at the smallest place the evidence indicts. Nobody should live permanently on probation. And evidence expires: what earned trust last year describes last year’s system, and nothing announces the change.

Nothing is done when it works. It is done when something checks it, an owner carries the outcome, and the way back has been walked at least once. A rollback nobody has rehearsed is a rumour.

Some work has no decisive check at a price anyone will pay. Mark it, keep people on it, and never let a number stand in for what cannot be measured.

Nobody is the only source of evidence that they are doing the thing, and that includes the machine that did it. You cannot feel whether the machine helped: work goes faster in the hand and slower on the clock, and nobody has trained that out of anyone.

Producing the work can be handed to a machine. Answering for it cannot. The machine wrote it in a second and somebody carries it for a year.

Deciding to kill something is not killing it. It is alive for exactly as long as its permissions still work.

Measure the system in public. Measure the person in private, and publish who did the measuring, on what evidence, and who can overturn it. Pay and promote for judgment under uncertainty, for spreading what works, and for carrying what does not.

What people are for

Every time a machine takes the making from someone, they are owed a harder question and not a smaller job. If the harder question does not come with more standing, it was a smaller job with better words.

Beginner’s work is what made the expert, and it is disappearing. Give that work to beginners anyway, because a trade that admits nobody has stopped being a trade. A company that ships more this year and can make fewer experts than last year has eaten capital and called it margin. No dashboard you already have will show it, so count the people you took from beginner to independent and publish that beside what you shipped.

Refuse work whose value depends on weakening the agency of the people it touches. Such work can be profitable and perfectly controlled. Whether its success is worth causing is the question, and it is asked before the controls and not after. Between two things you could build and defend, build the one that leaves people more able to act without you.

Anyone a decision lands on can reach a person who can explain it and change it. Not because the machine is often wrong, but because being processed by something that cannot be asked is a harm at any error rate.

If the work is handed to you rather than by you, all of that is what somebody owes you: work that can go wrong, a harder question when a machine takes the making, a name and a route when a decision goes against you. Ask for them by name. Asking is not insubordination, and if it is treated as insubordination where you are, you have your answer on your first day instead of in your third year.

Where to start

None of this needs agreeing with first. Four things are doable this week, and each hands back its own evidence.

Ship one change only after a check you did not write.

Before you let anything run on its own, walk the way back once, by hand. You will find a rollback or you will find a rumour.

Find something you declared dead last year and try its permissions. Whatever still answers was never killed.

Put a name and a route on one automated decision that lands on people, and ask the ones it went against whether they were told anything they could use.

Then stop doing them as an audit, because an audit is a thing you pass. Each one is fastened to a moment in the work and comes back when the moment does: a check you did not write, every time something ships whose failure would cost you; the way back walked, every time something is trusted to run alone; the permissions tried, every time something is retired; a name and a route, every time a decision lands on a person.

How you would know I am wrong

Every line above should be a bet, and a bet that cannot lose is not a bet. A test has to be losable by the line being wrong rather than by the world moving, so a clause that fires when the machine improves is a timer and not a bet. These five are mine. Where a line here has no test yet, that is a debt I owe and not a privilege I am claiming.

Verifying is misplaced when the work you checked went wrong as often as the work you let through.

Earning is theatre when what you trusted on sight held up as well as what you made climb for it.

Apprenticeship is sentiment when people who were never given work that could go wrong turn out able to make the same calls unaided as the people who were.

Refusing is posturing when the work you came closest to turning down, and built anyway, left the people it touched more able to act than your safer work did.

The reachable person is a courtesy when the people who had a decision go against them used it and said the wait was not worth it.

When one of these arrives, the failure counts against the line and not against you for having believed it. Drop it and say so.

How this dies

The last manifesto did not die. It won, and was hollowed out, which is worse. It spread as vocabulary while behaviour stayed home, and its heirs made it immune, so no failure could count against it. A method that explains every failure as incomplete adoption has arranged never to learn.

So if these words arrive and no decision changes, they failed there. And if most of this does not survive contact with your organization, it was wrong about your organization. A manifesto that cannot be wrong is not a manifesto. It is a liturgy.

Correct me rather than quote me.

That is the output a senior engineer now owns: something a model produced that the owner cannot fully explain. The management question is no longer “did you write good code.” It is “how do you know the thing you didn’t write is safe to turn on.” The owner ships when four things are true, in writing, and each carries a number they can defend.

It clears an owned eval on the unhappy paths. Not a vibe check but 200 cases the owner curated by hand: refund requests phrased as threats, tickets in the wrong language, prompt-injection pasted from a customer email, accounts with conflicting prior promises. The bar is 95% on that adversarial set, not 99%. Above 95% on a set this small you are usually overfitting: the cases have leaked into prompts, or the team has tuned to the test. Set it where the residual failures are ones the reviewer reliably catches. And the set rots on purpose: every production escalation becomes a new case, a tenth rotate out monthly, the owner holding back cases never tuned against. A frozen eval is a demo with a number on it; closing that gap is evaluation maturity .

Its top failure mode is named, with a detection signal. Here the mode is “confidently drafts a refund the policy forbids.” The signal is specific: a sampled audit comparing drafted amount against the policy ceiling, plus a flag whenever the draft cites a policy section that does not exist. If the owner cannot say what it most often gets wrong and how a dashboard would surface it, they have not found the failure mode. They have hoped there isn’t one.

Rollback has been exercised, not documented. Someone flipped the flag back to human-only handling in production last week, watched the queue drain, and confirmed nothing leaked. A rollback that has only ever lived in a runbook is a guess, and you discover it is wrong during the incident , which is the worst possible time to learn.

The escalation threshold is a number you can measure. Edit rate is easy: page if the reviewer rewrites more than 50% of drafts, because past half the assistant manufactures review work instead of removing it, and the unit economics have inverted. Stale context, the opening refund, is the hard one, so you instrument it rather than assert it. Every draft logs the version of each source it pulled: the policy revision, the read-time of the account record. At audit you label a draft stale when a source it relied on had already been superseded by the time the human acted: the policy version cited is no longer live. Sample a few hundred a day and you have a rate. Page at 3% over a rolling 1,000, because at a 95% review catch rate, 3% stale drafts put roughly 0.15% in front of a customer: the leak you decided you could afford. Raise the catch rate and you earn the right to raise the threshold.

None of this requires reading code to inspect, which makes it the board’s lever, not the team’s secret. Ask for the written definition-of-done for your single most important AI feature: which pass rate on which cases, which named failure mode, which rollback drill, which paging number, and the one name accountable for it. If what comes back is vague, the vagueness is not a documentation gap. It is the failure mode, still unnamed, and you have located your largest AI risk, which most oversight never does. Leading seniors is now mostly making that document exist, owned by one person, and boring, because every blank still interesting is a place the system can fail with no agreed way to know.

Keeping a provider genuinely warm is a standing cost, not a build. Your eval suite has to pass green against both providers on every prompt change. You maintain two sets of golden outputs. When one provider alters its tool-call encoding or its structured-output mode, you eat the fix to keep the boundary honest. Budget it as a fixed slice of the boundary team’s capacity, indefinitely, plus the inference spend of the shadow runs. If that line item lives in no one’s plan, you do not have a fallback. You have an aspiration and a grep result.

The boundary also leaks exactly where the value is. Constrained JSON-schema output on one provider becomes “ask for JSON and parse defensively” on another. Parallel tool calls on one go sequential on the other. Context limits, safety-filter behavior, and per-token economics differ enough that the same prompt yields a different product. A boundary that hides all of this can only promise the intersection, which means the price of portability is the provider-specific capability you surrendered to get it. That is a real trade, and it has a rule rather than a vibe: the critical path stays portable and dumb and carries a green fallback; a differentiating feature is allowed to depend on one provider, and in place of a fallback it carries a written number for what re-homing it would cost. Decide it per feature, on purpose, not by default.

Then the shock arrives. A vendor doubles the price effective next cycle. Three weeks of runway. You will not build a clean adapter across forty call sites in three weeks with a price gun to your head, and any plan that assumes otherwise is the fragile response in disguise. What three weeks actually buys is narrower and worth more: wrap the one critical path, get its fallback eval green, flip a slice of traffic, and write down the leaks you punted and what the other thirty-nine sites would cost. You solved the price problem. You also keep a swap that is now an afternoon on that path and a costed map of the rest, and the next path is cheaper because the scaffolding exists. That is the difference between robust and anti-fragile: surviving versus walking away holding a capability the shock paid for.

That capability never accumulates if the work sits in one team, and the reason is structural, not a lack of will. One group owns the model integration, the eval harness, the prompt registry, and the pager . A shock arrives, the same five people absorb it, restore service, close the ticket. That is not an organization. That is a single point of failure the org chart happens to call a department. Restoring service and changing the architecture so the next shock is cheaper are two different jobs, and the second needs the slack the on-call team just spent surviving the first. The conversion never happens, because the people who could do it are holding the pager.

So split the jobs. On-call restores service. The conversion is a tracked deliverable owned by someone off the pager that week, with the fallback’s carrying cost funded in their plan, not scavenged from spare time. Then push the portability decision down: the boundary team owns the shared interface and harness, but each product team owns its path’s portability budget and pays to keep that path’s fallback green. The work spreads to the people who own the paths instead of bottlenecking on five, and the authority to flip the switch sits with the team that owns the consequence.

The morning after any shock, that machinery has either left something behind or it has not. You are holding a warm path you can split traffic onto, an eval that catches the failure class that just bit you, a renegotiated contract with an exit clause : concrete things that were not there the week before. Or you are holding none of them. “We got through it and went back to normal” is the second case: service restored, full freight paid, not one green eval or warm path added that lowers the price of the next hit.

Why the prototype phase hides the real problem

In the early phase, AI teams often succeed because everyone is close to the work. Decisions are informal, context is shared, and the whole system fits in a few people’s heads. That stops scaling almost immediately.

As soon as the team grows, the same strengths turn into liabilities:

• knowledge becomes hidden
• approvals multiply
• handoffs slow down
• nobody owns the interface boundaries

What worked when the team was small no longer works when the company needs predictability.

The operating model should be explicit

A post-prototype AI org needs to define how work moves.

The model should answer:

• who owns the user problem?
• who owns the runtime?
• who owns the quality signal?
• who owns the risk boundary ?
• who can stop the release?

Without those answers, the team is improvising around gaps that will eventually become incidents or delays.

Handoffs are the hidden bottleneck

Most AI roadmaps do not fail because the team lacks ideas. They fail because each handoff adds ambiguity.

The problem shows up in predictable places:

• product asks for speed, platform asks for safety
• applied AI wants more freedom, compliance wants more proof
• leadership wants output, the system wants more control

That tension is normal. What is not normal is leaving it unresolved.

A good operating model turns tension into a documented interface, not a recurring crisis.

Scale requires fewer heroics

The post-prototype org has to depend less on heroic behavior and more on repeatable behavior.

That usually means:

• clearer ownership
• smaller decision surfaces
• stronger eval gates
• visible rollback paths
• fewer ambiguous exceptions

This can feel slower at first, but it is the only way the org gets faster at scale.

A simple test

Ask whether the AI system can survive a senior person going on vacation for two weeks.

If the answer is “not really,” the organization is still running on hidden tribal knowledge.

If the answer is “yes, with documented ownership and a stable operating model,” the company is moving from prototype to production.

That is the real year-two test.

Interfaces Without Cadence Degrade

When a team documents who owns what, the clarity is real for a few weeks. Then the pace picks up, the weekly sync gets skipped once, and the product owner starts resolving platform questions directly because it is faster. The interface is still on paper. It is no longer operational.

This is the failure mode that connects a well-designed bench to a year-two org that is back to improvising. Nobody dismantled the system. They just stopped running it.

Formal coordination loses to informal coordination every time informal coordination has lower friction. The only fix is making the formal cadence the path of least resistance: keep it short, metric-anchored, and non-negotiable.

The Three Cadences That Compound

Three rhythms cover the full operating surface of a scaling AI program.

Weekly operating cadence: 30 minutes, same metrics every cycle. Latency, error rate, eval scores , blocked work. The point is signal, not status. Any metric outside its threshold triggers an owner, not a discussion. If nothing is outside threshold, the meeting ends early.

Monthly outcome review: 90 minutes, owners present against targets set the previous month. What moved, what did not, what is at risk next month. This is where product and platform tradeoffs surface before they become incidents. Governance owner attends. Decisions are recorded with the owner and the date.

Quarterly architecture audit: half day, forward-looking. Where is the system accumulating hidden cost? What capability investment is being deferred? What would break first if the load doubled? The audit produces a short list of bets for the next quarter, not a roadmap deck.

Each cadence locks in a different time horizon. Weekly locks in operational latency. Monthly locks in outcome reliability. Quarterly locks in capability investment. Together they cover the full range from “is anything on fire today” to “are we building toward where the load is going.”

What Each Cadence Prevents

The weekly cadence prevents alert fatigue from becoming normalized degradation. Teams that skip it tend to discover the same problems later, at higher cost, under more pressure.

The monthly review prevents the gap between product ambition and platform reality from widening silently. That gap is where most AI roadmap slippage hides. By the time it is visible to leadership, it is already a quarter behind.

Cadence does not eliminate incidents. It shortens the distance between a signal and a decision .

The quarterly audit prevents incident-driven re-architecture . The single most expensive pattern in scaling AI programs is emergency redesign under production pressure. Orgs that run a quarterly audit tend to make the same architectural changes earlier, cheaper, and with less organizational disruption. The audit guarantees nothing. It forces the conversation that should happen before the crisis.

The Predictability Test

A cadence is working when the team can answer one question before the quarter ends: what is the most likely bottleneck next quarter, and who owns the intervention?

It is a structural test. If nobody can answer it, the cadence is collecting status but not producing foresight. The monthly reviews are not surfacing risk early enough, or the quarterly audit is not connected to the weekly signal.

If the team can answer it, even roughly, the cadence is compounding. The interfaces are being exercised on a predictable rhythm, and that rhythm is generating the kind of organizational memory that makes year-two scale possible without heroics.

A Bench Is an Interface Map

Many companies think “strong bench” means “we hired senior people.” That is necessary, but not sufficient.

A working bench answers four questions without debate:

• who owns product tradeoffs
• who owns platform reliability
• who owns model governance and risk boundaries
• who owns escalation when those priorities collide

If the answers depend on who is online that day, the bench is not operational.

Core Roles and Decision Rights

The exact titles vary. The interfaces should not.

Product owner: accountable for business outcome and adoption targets.

Platform owner: accountable for safe defaults, observability , and deployment reliability.

Applied AI owner: accountable for workflow behavior, routing, and evaluation quality .

Governance owner: accountable for explicit, reviewable risk boundaries.

The goal is unambiguous ownership when tradeoffs are real.

Failure Boundaries Beat Hero Culture

Healthy leadership systems plan for predictable stress cases instead of hoping for heroic response.

Define boundary behavior for events like:

• model quality degradation
• vendor policy or terms changes
• quiet workflow failure that evades basic monitoring
• loss of a key operator

If those handoffs are documented and rehearsed, incidents stay technical. If not, incidents become political.

One reliable warning sign: one person is expected to explain the full system from memory. That is not a bench. That is a single point of organizational failure.

How to Build the Bench in Practice

Make interfaces concrete and testable:

• document what each owner can decide without escalation
• define escalation thresholds for speed vs reliability vs governance conflicts
• map core metrics to the leader who can actually move them
• rehearse incident handoffs before live incidents force improvisation

This is operational hygiene.

Design boundaries before you design org charts.

Why Decision Latency Matters

A team can look productive and still be dragging the business down if every meaningful decision takes too long.

Decision latency shows up as:

• stalled launches
• expired opportunities
• duplicated work
• growing frustration in the teams closest to the customer

When leaders do not measure this, they blame execution when the real problem is delay. The work may be moving. The organization is not.

What Decision Latency Looks Like in Practice

You can usually find it by asking a few questions:

• How long does a high-signal issue sit before someone decides?
• How many people need to weigh in before the first answer exists?
• How often do decisions get reopened because no one owned the original call?
• How much work is blocked waiting for alignment that never arrives?

They sound soft. Each one has an economic answer.

If a release, hiring decision , vendor decision , or architecture decision sits for weeks, the business is paying rent on uncertainty.

Ambiguous ownership is the most expensive architecture in your company.

Make It Visible

If you want leaders to care, make the metric visible.

Track:

• time from issue raised to decision made
• time from decision made to action taken
• number of escalations per decision class
• number of decisions reopened after approval

Once those numbers are in the open, patterns become hard to deny. You can see which teams move fast, which questions keep getting rerouted, and where the organization is burning time on decisions that should have been routine.

How to Reduce It

Decision latency drops when teams do four things well:

1. Define who owns each decision class .
2. Set decision boundaries before the crisis.
3. Reduce the number of people required for routine calls.
4. Make escalation fast when the decision is truly material.

None of this means making every decision unilateral. Routine decisions should be quick, and risky ones explicit.

If the call is small, the system should move. If the call is material, the system should know exactly who has to weigh in.

The Point of an Incident Review

An incident review exists to answer four questions, and “who is to blame” is not one of them:

• what failed
• why it failed
• how we knew
• what should change so it fails differently next time

If that last step is missing, the review is incomplete.

What Good Reviews Produce

A strong incident review should produce concrete outputs:

• a change to architecture
• a change to evaluation coverage
• a change to alerting or observability
• a change to access or fallback policy
• a change to ownership or escalation rules

If the only output is a slide deck, the organization is optimizing for closure.

The cleanest signal is whether the same class of incident can happen again. If it can, the review was not done.

How AI Incidents Are Different

AI incidents often degrade quietly long before they trigger a loud outage.

The symptoms may be:

• degraded answer quality
• increased retries
• hallucinated outputs that look plausible
• cost spikes hiding inside normal traffic
• users losing trust before the team notices

That means incident reviews need to look at both user impact and system behavior. You cannot fix what you did not measure.

Incidents tell you where the system was more fragile than the architecture review admitted .

A Useful Review Template

A practical review should cover:

1. the triggering event
2. the timeline
3. the technical failure mode
4. the business impact
5. the monitoring gap
6. the architectural fix
7. the owner of the fix
8. the follow-up verification date

That is enough to keep the review grounded and actionable.

A postmortem without system change is paperwork.

The template is simple on purpose. If the review cannot name the control that changes, the meeting was too abstract.

A survivable roadmap is not a prettier Gantt chart. It is a dependency-aware budget for uncertainty.

Roadmaps Fail at the Edges

The core mistake is treating the roadmap like a statement of intent instead of a statement of sequencing.

AI work fails at the edges:

• data access is slower than expected
• model behavior is less stable than expected
• review cycles take longer than expected
• vendor changes arrive earlier than expected

If your roadmap does not account for those edges, it is not a plan. It is a confidence exercise.

The fix is to move the hidden work into the plan before the promise is made.

Budget the Dependency Chain

Every AI feature has a dependency chain:

• data availability
• context assembly
• model routing
• evaluation
• deployment
• fallback

If any one of those links is not ready, the feature will not survive real use.

If the chain is incomplete, the roadmap is lying by omission.

The most honest roadmap is the one that writes the chain down first. That slows the conversation, but it also keeps the team from selling a feature that depends on work nobody has budgeted.

Slower conversations are cheaper than broken launches.

Make Rollback a First-Class Requirement

Good roadmaps assume the first version will be wrong.

That means every AI initiative should answer four questions:

• How do we turn this off?
• How do we know it is hurting us?
• How fast can we revert?
• What manual path exists if the model degrades?

If those answers are fuzzy, the roadmap is overconfident.

If you cannot turn it off quickly, you have shipped a liability with a product label .

Roadmaps should not only describe the happy path. They should budget for the probability that the first version is wrong, the vendor changes terms, or the model regresses under load.

WIP Limits Matter More Than Hope

A roadmap that promises too many parallel AI experiments is usually a roadmap that does not respect WIP.

The more novel the work, the lower the WIP should be.

Concurrency feels productive until it multiplies rework.

Strong teams set rules like:

• no more than one high-risk AI launch per squad at a time
• no feature ships without evaluation coverage
• no vendor migration without a fallback path
• no roadmap item enters “done” until the operational notes exist

That may sound strict. It is. Novel work punishes loose concurrency.

What a Survivable Roadmap Looks Like

Survivable roadmaps are dependency-explicit, rollback-aware, and honest about capacity.

A roadmap is not a promise. It is a bet with visible failure modes.

If the failure modes are invisible, the roadmap is pretending.

You do not need a roadmap that impresses the room. You need one the organization can execute without pretending the hard parts are somebody else’s problem.

That is why judgment matters more than hype. Teams that hire for excitement get enthusiastic meetings. Teams that hire for operator discipline get leverage.

The Operator Profile

Strong AI operators usually have four traits:

• they can turn a vague brief into a tractable plan without waiting for perfect inputs
• they know enough about systems tradeoffs to challenge weak assumptions early
• they care about verification as much as output
• they can move between engineering, product, and executive language without flattening the nuance

Model trivia is cheap. Operator judgment is what survives contact with production.

The market is full of people who can name the newest framework. The shortage is people who can keep a system healthy when the workload changes, the vendor shifts, or the first release misbehaves.

What Most Teams Hire Wrong

AI hiring goes off the rails when teams reward signals that are easy to notice but hard to run with.

Teams over-index on:

• prompt fluency without operational discipline
• research taste without delivery habits
• architecture opinions without incident literacy
• product instinct without measurement rigor

None of those traits is bad. The problem is imbalance.

A strong AI team needs people who will own the boring parts: evals , fallback logic, access boundaries, cost control, and documentation precise enough that someone else can operate the system later.

If a candidate can talk fluently about models but cannot explain how they would debug a bad release, they are not ready to own production AI.

The Interview Questions That Matter

You do not need a clever hiring process . You need questions that force real evidence.

Ask candidates to walk through:

1. A system they had to stabilize. What was broken, how did they know, and what changed after they touched it?

2. A decision they reversed. Strong operators do not defend bad ideas forever. They update when the evidence changes.

3. A workflow they measured. If they cannot show how they connected work to metrics, they probably did not own the outcome.

4. A failure they made safer. In AI, good operators do not eliminate failure. They bound it.

A useful answer is concrete, a little messy, and grounded in actual work. The worst answer sounds polished and empty.

Hire for the Shape of the System

AI teams do not need the same operator profile in every context. Research-heavy, production-heavy, and regulated enterprise teams all demand different instincts.

If you want a research-heavy team, hire for exploration and rigor. If you want a production-heavy team, hire for stability and operational discipline. If you want a regulated enterprise team, the bar is not “exciting.” The bar is whether this person can help you ship safely, repeatedly, and without heroics.

That is the real operator profile:

• can handle uncertainty without freezing
• can make tradeoffs explicit
• can leave behind a system other people can run
• can keep pace without turning every launch into a performance

The mandate is throughput. More noise and more experimentation theater work against it.

The Leadership Pivot: Focus on Throughput

Organizations do not pay technical leaders to keep up with model releases. They pay them to improve organizational throughput .

That means reducing cognitive overhead, tightening verification, and making deployment paths boring enough that teams can move without drama. If you cannot measure what an AI workflow produced, or what it cost to produce it, you do not have an operating system yet. You have a prototype with invoices.

The leadership question is simple: are we removing blockers faster than we are adding complexity?

Decision-Making in Practice

AI work gets messy when teams debate tools before they define the outcome.

Good leaders force the conversation back to first principles:

• What business metric should change if we ship this?
• What latency budget do we actually have?
• What happens when the model is wrong?

Those questions cut through a lot of noise. They keep the team from turning architecture meetings into opinion contests about vector databases , prompt styles, or the latest agent framework.

If the answer to any of those questions is fuzzy, the work is not ready for serious implementation.

Define “Good Enough” and Measure It

Reliability covers more than accuracy: consistency, cost, and the ability to catch degradation before customers do .

Sometimes a smaller, cheaper model is the right answer. Sometimes the frontier model is worth the price. Don’t be religious about either option. Define the bar, test against it, and choose the system that meets it with the least operational pain.

Perfection isn’t the goal. Build a system where failure is bounded, expected, and visible.

The Cultural Shift

Technical leadership still has a change-management problem. Engineers will worry about ownership, safety, and the volatility of the ecosystem. Those concerns are real.

The right response is instrumentation. Debate for its own sake settles nothing.

Stop arguing in design docs about whether a model will work. Build the telemetry that shows whether it works. Stop treating every new framework like a strategy reset. Run small, contained experiments that either produce evidence or die cheaply.

The strongest teams can absorb change without losing control. Sprinting toward the newest beta API doesn’t build that. If the team can move quickly, measure clearly, and recover cleanly, AI becomes leverage. If not, it becomes another source of drag.

Six weeks later, the channel had five messages in it, four of them automated. The procurement leads were still pulling PDFs manually and copying terms into a shared spreadsheet. One support engineer, who had quietly championed the project from the beginning, had reverted to her old database query because “the tool doesn’t know about the amendments.” The tool was still running. Nobody had officially abandoned it. It had simply become invisible.

This pattern is not unusual. It is almost the default.

What Actually Failed

The postmortem conversation usually centers on the wrong things: model choice, interface design, rollout timing. Those are symptoms. The root causes are structural.

The contract tool was built around a narrow slice of the negotiation workflow: surfacing base terms. But procurement work is not base terms. It is base terms plus amendments plus prior history plus the relationship context the lead carries in her head. The tool knew one layer of a five-layer problem. It looked complete in a demo because demos are controlled. Real work is not controlled.

The output trust problem arrived fast. In week two, the tool surfaced an incorrect payment term: technically correct in the original contract, but superseded by a signed amendment it had not been given access to. The lead caught it before it caused damage, but she stopped relying on it after that. One unexplained wrong answer is enough to demote a tool from co-worker to footnote. The team had not built evaluation into the system , so there was no way to know how often this happened, which made the uncertainty worse.

Nobody owned adoption after the launch. The engineer who built it moved to a different priority. The VP who celebrated it never checked sustained usage . When procurement leads developed workarounds, there was no one watching the signal and no one with a mandate to respond. The tool drifted.

When It Works

A different team at a professional services firm built something structurally simpler: a tool that drafted the engagement summary section of a client report, pulling from structured notes the consultant had already entered into their project management system. Narrow scope. No novel context required. One predictable output format, reviewed every time before it went anywhere.

The tool stuck, and it was considerably less impressive technically. It stuck because it removed a specific, recurring task that consultants genuinely disliked, it used context they were already maintaining anyway, and the output was always human-reviewed before it mattered. The failure mode was visible and safe. The value was obvious the first time you used it and every time after.

The team lead reviewed usage weekly for the first two months and made three small adjustments based on what she saw. That unglamorous, persistent, post-launch ownership is what made the difference.

The Structural Difference

Both companies built AI tools for internal workflows . One failed quietly, one became a habit. The model and the interface didn’t decide it. What decided it was whether the tool was designed around how work actually moves or around what would look good in a demo .

Tools that survive are ones that fit a narrow, complete slice of a workflow, produce output that is either verifiable or bounded enough to trust, require no context the user does not already have, and have someone whose job it is to watch whether people are actually using them.

That last part is the one most teams skip. Usage is not a launch outcome. It is an operating responsibility.

Shrinking the team and hoping demand goes away won’t fix it. Move decisions out of the queue and into the platform.

A Platform Team Is a Product with a Queue

A healthy platform team exists to make repeated decisions disappear.

If every experiment needs a ticket, a Slack ping, and a weekly exception review, the platform is no longer a platform. It is a gate with a service catalog.

The warning signs show up fast:

• request backlogs that never get smaller
• the same exception coming back under a new name
• engineers building shadow infrastructure because the official path is too slow
• work that should have been standardized long ago still handled by hand

Once teams start routing around the platform, the default path has already lost.

What Bottleneck Behavior Looks Like

Bottlenecks rarely announce themselves. They sound like process.

You hear it in the same lines over and over:

• “We are waiting on the platform team.”
• “Can we make this an exception?”
• “We built a small internal workaround.”
• “The platform is a few weeks behind us.”

None of those lines is fatal on its own. The pattern becomes a problem when they turn into the normal way work gets done.

A platform team becomes a bottleneck when it centralizes decisions that should have been made once, written down, and pushed into the default path.

Redesign the Team Around Capabilities, Not Control

Good platform teams build paved roads .

They own the hard parts once:

• identity and access patterns
• model routing defaults
• evaluation harnesses
• logging and traceability
• safe deployment templates
• fallback behavior

Then they get out of the way.

The wrong shape is a team that has to bless every new use case. The right shape is a team that makes the safe path easier than the unsafe one.

A good test: a platform team should remove waiting, not become a waiting room .

Metrics That Expose a Platform Bottleneck

Most platform dashboards avoid the real question. You need blunt metrics.

Measure:

• time from request to usable platform support
• exceptions granted per month
• shadow systems discovered in production
• hours spent waiting on platform review
• AI workflows shipped without platform involvement

Those metrics tell you whether the platform is compounding or constraining.

If exceptions keep rising and the team calls that “flexibility,” the default path is still too hard to use.

What Good Looks Like

The best AI platform teams I have seen share three habits:

1. They bias toward self-service.
2. They make safe defaults boring.
3. They track the cost of waiting as carefully as the cost of infrastructure.

That last one matters. Waiting is not free. Every hour a product team spends blocked on the platform is an hour not spent learning from users.

An AI-native company is not a company that uses AI. It is a company whose operating model (decisions, ownership, interfaces, capital, and failure boundaries) has been built so AI compounds inside it instead of evaporating around it.

The model will change. The system around it should not.

This is a manifesto. It is opinionated, deliberately. Twelve tenets, four movements, one test. Borrow what works. Argue with the rest.

Movement I: Strategy

1. The operating model is the strategy

The model is the most expensive dependency in your stack. It is not the brain. The brain is everything you build around it: context assembly, retrieval, validation, retries, telemetry, fallback, escalation.

Two companies buy the same frontier model on the same Tuesday. One ships in six weeks with a deterministic fallback, a typed validator, and an eval gate on every PR. The other ships in six months with a notebook of “good prompts” and a Slack channel for incidents. Same model. Different company.

If your AI plan begins with “which model should we buy,” you are solving the easiest problem in the room. The moat is everything around the model.

2. Capital allocation is the first product decision

Great AI teams do not start with a roadmap. They start with a kill list . Capital is finite. Attention is finite. Support burden is finite.

Three questions before any AI initiative gets funded:

1. Does this increase margin, reduce risk, or improve speed?
2. Can we measure that effect within one to three quarters?
3. Do we own the fallback if the model or vendor changes?

If the answer to all three is not yes, the default is no.

A common pattern in Series B to D companies that quietly stalled in 2024 and 2025: serious engineering and infra budget burned on internal copilots that never crossed adoption threshold, plus a duplicate prompt orchestration layer because two teams built one in parallel. Neither project had a measurable failure mode. Both had a sponsor.

A four-dimension scorecard makes the next budget meeting honest:

• Adoption: are real users using it in a real workflow?
• Reliability: does it fail in bounded, observable ways?
• Margin: does it reduce cost or improve unit economics?
• Speed: does it shorten a real business cycle time?

If you cannot defend it with numbers, the project is not innovative. It is unpriced.

3. Decision latency is a P&L variable

Slow decisions look like caution. In practice, they are hidden expense. Every day a real decision sits unresolved, the business pays in delay, rework, and attention.

Headcount is an input. Throughput is an outcome . Adding the tenth engineer to a system that takes nine days to approve a deploy adds nine more days of waiting, not 10% more output.

Track four numbers with the same seriousness as revenue:

• time from issue raised to decision made
• time from decision made to action taken
• escalations per decision class
• decisions reopened after approval

Ambiguous ownership is the most expensive architecture in your company.

Movement II: Architecture

4. Build firewalls, not masterpieces

A statistical engine cannot be expected to behave like deterministic infrastructure. If your architecture only works when the model is correct 100% of the time, it is not architecture. It is wishful thinking with a demo budget.

Three failure modes, three firewalls. They are not the same thing and they are not solved by the same code:

• Inbound sanitization. What data is permitted into the prompt context. PII strippers, schema enforcers, retrieved-document trust scoring. This is also where indirect prompt injection (instructions hidden in a vendor PDF, a customer message, or a tool output) gets caught before it reaches the model.
• Outbound validation. A typed schema checker stands between the model and the operational database. Malformed JSON, out-of-range values, and policy-violating outputs are rejected at the boundary, not absorbed by downstream services.
• Operational fallback. Circuit breakers for vendor outages and rate limits. If the model returns invalid output three times in a row, the system degrades to a deterministic path instead of a stack trace in front of the user.

Each of these is a separate piece of code with a separate owner, a separate test surface, and a separate failure mode. A “kill switch” that catches all three is a slide, not a system.

You cannot prompt your way out of entropy. You have to architect your way out of it.

5. Evaluation is the spine

If you cannot define an eval suite before shipping a feature, you do not understand the system well enough to ship it.

A five-level maturity ladder :

1. Vibes-based. Someone eyeballs prompts before release.
2. Spreadsheet. Suite exists, runs occasionally, blocks nothing.
3. CI/CD-integrated. Evals run on every PR. A failed gate stays failed.
4. Continuous telemetry. Production samples scored asynchronously. Incidents become regression tests.
5. Governance as moat. Evaluation shapes architecture before code. Margin, latency, and sovereignty tradeoffs are quantified, not asserted.

Below Level 3 is not a production system. It is a demo with a pager.

Level 4 is where most organizations get stuck, and the reason is rarely effort. Judge models drift, ground truth ages, sampling bias creeps in, and your asynchronous scoring quietly stops tracking the failure mode you cared about. Mature teams hold a small, hand-labeled golden set as the anchor, treat the judge model as a versioned dependency, and re-calibrate when either changes.

Eval portability is a year-two survival trait. If your eval suite is hand-tuned to one model’s tokenizer and one vendor’s output quirks, you have not built an eval suite. You have built a benchmark for the model you are about to be unable to leave.

6. Agentic systems run on a reliability contract

Agents are not magical workers. They are autonomous systems with more ways to fail. The reliability discipline gets stricter, not looser.

Every production agent answers five questions in one meeting, without hand-waving:

• what is it allowed to do?
• what is it explicitly not allowed to do?
• what metrics prove it is healthy?
• what happens when the model degrades?
• who can stop it, and how fast?

But the five questions are a meeting checklist. The contract is a published artifact with SLOs, blast-radius caps in dollars or rows or API calls, rollback latency targets, and a named owner per failure mode. Blast radius is the real design variable: data scope, action scope, time scope, permission scope, fallback scope.

Kill switches are not weakness. They are governance that can move faster than the failure. A useful test of any AI control: could an engineer follow this rule at 2 a.m. without calling a committee?

A roadmap that ships an agent without answers to these questions is a roadmap that has shipped a liability with a product label. Every initiative names how it turns off, how it knows it is hurting, how fast it reverts, and what manual path exists when the model degrades.

Companion: Agent Reliability Contract template . Rollback document template .

Autonomy without a reliability contract is just an incident waiting for a timeline.

Movement III: Economics & Externals

7. Unit economics live at the workflow, not the model call

Teams fixate on tokens because tokens are visible. The real bill sits around the model: retries, context assembly, human correction, support escalation, and the work of proving the output is acceptable.

Route by value and by risk. Trivial work stays cheap and local. High-stakes work earns expensive inference and stronger checks. A finance-aware leader can answer, without hand-waving:

• what each class of request costs to serve, end to end
• where the rework happens
• what failure costs when the model is wrong
• which parts of the workflow justify premium inference

The cost question nobody owns until it explodes: when product ships a feature that 10x’s tokens, who pays? If the answer is “we’ll figure it out,” you have not designed an operating model. You have deferred a fight.

Compute placement is part of this calculation, not a separate one. For high-frequency agentic workloads, a chain of round-trips across regions and vendors compounds into real latency tax and real egress cost. Local-first, hardware-aware patterns earn their place where the workload mix justifies them, and create a worse outcome where it does not. Measure first, place compute second.

A cheaper model that fails gracefully beats an expensive model that fails silently.

8. Sovereignty is an architecture constraint

Privacy is not a feature you bolt on before an enterprise contract closes. It is the shape of the system.

A sovereign system controls the full lifecycle of every piece of data: where it lives, who can access it, how long it persists, and what happens when someone asks you to delete it. In practice, four concrete patterns:

• Customer-managed keys. BYOK or hold-your-own-key. If your cloud provider holds the only copy of the encryption key, “we cannot access your data” is a policy promise, not a verifiable claim.
• Regional routing with storage isolation. EU data does not leave EU infrastructure. The application layer handles the routing. The deployment pipeline ships multi-region.
• Scoped, short-lived access. No ambient credentials. Service-to-service tokens with explicit grants and automatic expiry.
• Immutable audit trails. Append-only, tamper-evident logging of every access, transformation, and movement.

“We use AWS” is not an answer to “where does my data live.” Sovereignty is about specificity.

The compounding bill arrives when you try to add this later. The discount arrives when you build it in early and close enterprise contracts without an architectural retrofit.

9. The threat model is the manifesto

An AI manifesto without a threat model is marketing copy. Four risks every operator names explicitly:

• Indirect prompt injection. Instructions hidden in retrieved documents, tool outputs, and user uploads, not just in the user’s direct prompt. Treat every retrieved string as potentially adversarial. Validate before it reaches the model. Strip before it reaches the agent.
• Silent quality drift. The model returns slightly worse reasoning. The tone shifts. The retrieval starts ignoring critical documents. There is no stack trace. Only asynchronous production scoring, anchored to a golden set, catches this before customers do.
• Vendor and model lock-in by accident. Fine-tunes, preference data calibrated to one model family, and prompts hand-tuned to a specific tokenizer compound. By year two, your “swappable” model is a six-month migration. Discipline preserves optionality: prompt abstraction, eval portability, vendor-neutral preference data, and a quarterly review of what would break if the vendor changed terms tomorrow.
• Agent blast radius creep. Permissions accumulate. The agent that summarizes documents quietly gains write access to your billing API because someone needed it once. Audit scope quarterly. Treat agent permissions like database credentials, not like configuration.

Threat modeling is not a one-time exercise. It is the bill of materials your system runs on.

Movement IV: People & Failure

10. Interfaces beat titles

Most AI hiring plans try to fix an interface problem with resumes. They rarely work.

A working leadership system is not a roster of senior titles. It is a decision map. Four owners with explicit decision rights and explicit escalation paths:

• Product: user outcomes, adoption, business tradeoffs.
• Platform: safe defaults, deployment paths, observability, paved roads.
• Applied AI: workflow behavior, routing, prompting, retrieval, evaluation quality.
• Governance: risk boundaries, sovereignty controls, escalation thresholds.

The titles can be anything. The interfaces cannot be ambiguous. If the answers depend on who is online that day, the system is not operational.

The same logic governs platform teams. A platform exists to make repeated decisions disappear into the default path: identity, routing, eval harnesses, logging, safe deployment, fallback behavior. The moment platform becomes a queue that has to bless every use case, the queue is the product and waiting is the cost. A platform should remove waiting, not become a waiting room.

Hiring works after the operating contract is clear, not before. New hires scale the current operating model, good or bad. Org debt is interface debt with better branding.

11. Anti-fragility requires portability discipline

Resilience is surviving the shock. Anti-fragility is using the shock to remove the next one.

Fragility hides in the org chart and in the stack. One engineer who knows the routing. One vendor whose terms changed last week. One fine-tune that took six months to train and would take six months to migrate. That is not an organization or a system. That is a single point of failure wearing a department badge or a model card.

Four design choices build strength:

• Modular ownership. No critical function depends on one person’s memory. Deputies are named.
• Resettable interfaces. A model, vendor, or workflow can be swapped without a rewrite. This is not free. It requires prompt abstraction, eval portability, vendor-neutral preference data, and a regular drill where the team actually proves a swap is possible.
• Fast learning loops. Every failure produces a tighter eval, a better fallback, or a clearer operating boundary.
• Cross-training on the boring parts. Alerts, evals, fallback logic, access boundaries. The unglamorous work is what keeps the organization elastic.

A short anti-fragility check:

• Can you swap a model without rewriting the product?
• Can you lose a key engineer without losing the system?
• Can you absorb a vendor price increase without panic?
• Can you turn a production incident into an improved control?

If any answer is no, the organization is more brittle than it thinks. The most expensive lie an AI organization tells itself is that the model is swappable when nobody has tried.

12. The year-two test

A lot of AI organizations look healthy in month three and brittle by year two. The model did not fail. The operating model did. Prototype energy is easy to create. Durable coordination is not.

The single question that separates the two:

Can the AI system survive a senior person going on vacation for two weeks?

If the answer is “not really,” the organization is still running on hidden tribal knowledge.

If the answer is “yes, with documented ownership, a published reliability contract, an eval suite that blocks releases, and a fallback path the on-call engineer can execute at 2 a.m.,” the company is moving from prototype to production.

That is the only year-two test that matters. Everything else in this manifesto is in service of passing it.

What this manifesto is not

It is not a prediction about which model wins. It is not a framework for replacing engineers with agents. It is not a defense of any vendor, any cloud, or any stack.

It is a statement about how serious companies organize for AI when the easy money, the demo budgets, and the hype cycles are done, and only the operating model is left to do the work.

The model will change.

The system around it should not.

Law Zava writes about the operating model behind serious AI execution. Companion artifacts: Agent Reliability Contract template · Rollback document template · Eval Suite starter kit . The canonical reading path is at /blog .

The Alignment Problem

Every layer in a company listens for a different failure.

Engineers ask: can we make it reliable without turning the stack into a science project?

Executives ask: can it matter this quarter, not someday?

Investors ask: can it scale without becoming a support burden, a security problem, or a margin leak ?

If those questions are not coordinated, the organization drifts into avoidable conflict. Product thinks it shipped success. Engineering thinks it shipped risk. Finance thinks it shipped cost. The AI program becomes a political object instead of an operating system.

What Each Layer Needs to Hear

A good communication protocol gives each audience the right level of detail and nothing more.

Engineers need constraints, failure modes, ownership, and the exact conditions under which they should stop or escalate.

Executives need the business outcome, the tradeoffs, the cost of delay, and the risk of waiting for a perfect answer.

Investors or board members need the thesis, the numbers, the confidence interval around those numbers, and the reason the company believes the numbers are real.

The common mistake is predictable: over-share implementation detail upward and under-share operational reality downward. Leaders either talk past each other or sand off the complexity to keep the room calm. Neither habit helps. Clarity is kinder than politeness when the system is expensive.

Build a Communication Rhythm

Strong CTOs do not improvise every update. They set a rhythm that forces the same narrative to appear at predictable intervals, so the organization can spot drift before it becomes a surprise.

A practical cadence looks like this:

• weekly: operational progress, blockers, decisions made, decisions deferred
• monthly: outcome metrics , risk posture, and what changed in the operating assumptions
• quarterly: strategy shifts, tradeoffs, roadmap changes, and what the board should expect next

That structure gives the organization memory and gives the board a clean way to compare this quarter with the last one.

More slides won’t help. Keep the story consistent enough that people can challenge it on the merits.

Misaligned narratives are delayed incidents.

Use the Same Three Questions Everywhere

Keep asking the same three questions in every forum: what changed, what did it affect, and what happens next? Those questions work at the team level, the executive level, and the board level because they force the same discipline: outcome, consequence, next move. If a layer cannot answer them, the communication is not yet useful.

Alignment is not consensus. It is a shared operating picture.

The Governance Mistake

Most organizations confuse governance with oversight theater.

They create committees, review boards, and approval layers, then act surprised when teams route around them. The result is predictable: slow delivery, hidden risk, and a false sense of control.

AI governance should answer a simpler question: what is allowed by default, what requires review, and what is forbidden?

If those boundaries are clear, teams can move. If they are not, every decision becomes a negotiation.

Tight Defaults Beat Loose Rules

Good governance systems do not ask engineers to remember every policy. They make the safe path the easy path.

That means:

• default data access is scoped, not ambient
• model use is tied to approved workflows
• logs retain enough context to investigate failures
• high-risk actions require explicit escalation
• evals run before release, not after incident review

Governance works when it compresses uncertainty. It fails when it only adds paperwork.

A useful test: could an engineer follow the rule at 2 a.m. without calling a committee? If not, the rule is too vague or too heavy.

Ownership Matters More Than Policy

The fastest way to break governance is to make it everyone’s job.

Real governance needs named owners for:

• data classification
• model approval
• evaluation coverage
• exception handling
• incident response

Without ownership, governance becomes a shared belief system. Shared belief systems feel flexible until something breaks.

The people who matter most can answer three questions: who decides, who reviews, and how fast can we change course? The author of the longest policy often can’t.

Build the Smallest Control Stack That Works

You do not need 30 controls to govern AI well. You need the smallest control stack that actually changes behavior.

Start with:

1. a short list of approved data classes
2. a clear model use policy by workflow
3. required evals for release
4. a lightweight exception path
5. an incident review process that changes architecture, not just slides

If you can keep that stack small, understandable, and enforced, you will get more compliance and less resistance.

A line worth keeping: the best control is the one engineers can still use at 2 a.m.

Why Three Numbers Are Enough

Leaders overcomplicate AI strategy because they do not want to choose.

But every AI decision eventually lands in one of three buckets :

• Margin: does it improve unit economics?
• Risk: does it make the system safer or more controllable?
• Speed: does it shorten the path from decision to outcome?

That is the executive frame. Everything else supports it.

If a project cannot clearly improve at least one of those numbers, it does not belong near the top of the roadmap.

The Trap of Novelty Metrics

AI teams love the wrong metrics because the wrong metrics are easy to count.

Number of models tested. Number of pilots launched. Number of prompts written. Number of demos shown. Number of meetings held.

Those numbers can tell you whether work is happening. They do not tell you whether the company is getting more profitable, less exposed, or faster to act.

Build a Scorecard Around Outcomes

A serious AI scorecard is short.

1. Did margin improve?
2. Did risk go down?
3. Did cycle time shorten?

Everything else is instrumentation that helps answer those questions.

That does not mean you ignore adoption, reliability, or cost. It means you use them as inputs to the three executive numbers, not as substitutes for them.

The strongest boards and founders do not need twenty metrics. They need a few numbers that are hard to fake.

Make the Three Numbers Operational

The framework only works if the numbers are real.

For each AI initiative, define:

• the baseline
• the target
• the measurement cadence
• the owner
• the rollback path if the numbers move the wrong way

That keeps the conversation concrete and makes the project accountable.

A line worth keeping: if a strategy cannot change one of the three numbers, it is probably theater.

The Governance Maturity Model

Level 1: “Vibes-Based” Deployment

Evaluation is manual, episodic, and easy to ignore. Someone checks the prompts when there is time, ships the change, and waits for users to find the regression.

You can tell you are at Level 1 when the answer to “How do you know yesterday’s model swap was safe?” is a shrug, a few sample prompts, or “it looked fine.” There is no baseline. There is no history. There is only whatever the latest person happened to test.

The failure mode is silent degradation. The model changes, behavior drifts, and the team learns about it weeks later from an angry customer or a support escalation that should never have reached production.

Level 2: The “Spreadsheet” Era

There is an eval suite , but it lives beside the delivery process instead of inside it. Someone runs a small Python script over a fixed list of cases before a big release and calls that “testing.”

Level 2 teams understand that evaluation matters, but they still treat it like a chore. The suite covers happy-path prompts and misses the things that actually break systems: adversarial inputs, schema violations, prompt injection, PII leakage. And because the results are not wired into release decisions, a bad run usually gets waved through anyway.

The failure mode is false confidence. The team trusts a narrow test set because it exists, not because it is representative. Then a multi-turn attack, a bad schema shift, or a quiet regression makes the gap obvious in production.

Level 3: CI/CD Integration (The Minimum Operational Bar)

Evaluation is part of the delivery pipeline. The suite is broad enough to cover core capabilities and common failure modes, and the results block release candidates when they miss the bar.

At Level 3, every PR or deployment candidate runs the eval suite automatically. The checks include latency, cost per token, output schema validity, and the core reasoning path your product depends on. Results show up in CI next to unit tests. A failed gate stays failed until someone writes the exception and owns the risk.

This is the minimum bar for an enterprise team. A vendor can release an “improved” model on Tuesday, and a Level 3 team can run the suite on Wednesday morning and decide, with evidence, whether the new model actually helps their workload.

Level 4: Continuous Production Telemetry

Evaluation does not stop when code ships. The system keeps watching in production and turns incidents into future tests.

At Level 4, an asynchronous sampling job pulls 5% of production responses, scores them with a cheaper model or other fast evaluator, and flags anomalies. When something goes wrong, the exact input/output pair that caused it becomes a regression test. The system assumes drift is normal, because with LLMs, it is.

Level 5: Governance as a Strategic Moat

Evaluation shapes architecture before code is written. Quality and privacy are constraints that drive the design from the start.

At Level 5, the team knows how much reasoning quality they give up if they move traffic from a large cloud API to a quantized local 8B model, because they have the metrics to prove it. That gives the CTO real room to choose between margin, latency, and data sovereignty. It also lets the company close larger enterprise deals because it can show, in operational terms, where customer data lives and where it does not.

How to Force Maturity

If you are leading a team stuck at Level 1 or 2, you will not buy your way out with a new tool. You have to change how releases work.

1. Stop accepting demos. Do not ship the next feature unless it includes a 20-case eval suite attached to the PR.
2. Wire it to CI. If evaluation does not block the deploy, it is a suggestion, not a control.
3. Build circuit breakers. Treat the model like a flaky dependency . If it fails to return valid JSON three times, fall back to a deterministic system or fail safely. Do not hand hallucinations to the user and call that progress.

Most companies treat AI spend as a separate class of spend. It competes with product work, platform work, hiring, and operational debt like everything else. If you cannot explain why an AI initiative deserves scarce capital, you are not allocating capital. You are subsidizing hope.

Capital Allocation Is the First Product Decision

Capital allocation is not a finance problem that happens to engineering. It is a technical leadership problem with finance consequences.

Every AI project consumes three things:

• engineering time
• infrastructure budget
• organizational attention

If the project does not improve one of three board-level outcomes (margin expansion, risk compression, or execution speed), it is likely a vanity project wearing a product costume.

That does not mean the project has to be immediately profitable. It does mean you should be able to state what gets better if the project works and what gets worse if it does not.

What Should Die First

The easiest place to make mistakes is the demo room. The second easiest is the budget meeting.

Stop funding these first:

1. Thin demos that do not survive workflow reality. If the user needs three manual edits after every response, you have built a presentation layer, not a product.

2. Duplicate platform work. If two teams are building separate prompt orchestration, evaluation, or routing layers, one of them should stop. Duplication feels like speed until the maintenance bill lands.

3. Ambiguous experiments with no owner. “We should explore AI” is not a strategy. It is a permission slip for drift.

4. Projects with no measurable failure mode. If nobody can say what counts as bad output, bad latency, bad cost, or bad adoption, the project cannot be managed.

There is a simple reason these projects linger: they are emotionally easy to defend. Nobody wants to kill a project that sounds innovative. But if you cannot defend it with numbers, the project is not innovative. It is unpriced.

The Kill-List Rubric

A good kill list is a decision system. Personal dislikes don’t belong on it.

Before funding a new AI initiative, ask three questions:

• Does this increase margin, reduce risk, or improve speed?
• Can we measure that effect within one quarter?
• Do we own the fallback if the model or vendor changes?

If the answer to all three is not yes, the default should be no.

This is where a lot of teams get sentimental. They continue funding because the project has a sponsor, or because it already consumed sunk cost, or because it looks good in a board deck. Those are weak reasons to keep a system alive.

Strong reasons to keep funding an AI initiative usually look like this:

• it replaces high-volume manual work
• it improves decision quality in a regulated workflow
• it reduces customer wait time
• it protects a revenue stream that depends on fast, accurate responses

Notice that none of those reasons mention hype.

What to Keep Funding Instead

The highest-return AI investments are boring in the best way.

Fund the parts that make the system measurable and durable:

• retrieval and context quality
• evaluation harnesses
• fallback logic
• routing by task class
• observability around bad outputs and retries
• workflow-specific data collection

Chasing the smartest model is a poor use of that money. Build a system that can absorb model churn without forcing a rewrite every six months.

A useful line to keep in mind: if a system cannot be measured under load, it is still a pilot. Pilots are fine. Pilots just should not keep consuming production budget forever.

The Hard Part Is Saying No

The best operators are not famous for being aggressive spenders. They are famous for being disciplined about what they do not fund.

That discipline becomes a reputation asset. The founder who sees you delete a weak AI project starts trusting your judgment. The board member who sees you cut duplicate work starts trusting your signal. The engineering team that sees you protect their time starts trusting your priorities.

Capital allocation is how you tell the truth about what matters. If a project cannot defend margin, risk, or speed, it should not survive by momentum alone. Fund the systems that make AI measurable, recoverable, and cheap to operate. Cut the rest.

The Strategy Is the Infrastructure

The single biggest mistake engineering organizations make is treating the model as the brain. It is not. It is the most expensive dependency in the stack.

The brain is everything you build around it: context assembly, retrieval, validation, retries, telemetry, and rollback.

A CTO must focus ruthlessly on three pillars:

1. The Context Pipeline

The model is only as intelligent as the context you feed it. If Postgres, Cassandra, or Scylla takes five seconds to assemble structured context, encode it, and hand it to the orchestrator, your feature is already late before inference begins.

Strategy means architecting data replication, embedding generation, and caching so the latency budget stays intact for the inference layer. If your data infrastructure is not close to real time, your AI will not be either.

2. The Evaluation Framework

If your organization is still eyeballing model outputs before deployment, you are running a pilot, not a production system.

Leadership means demanding continuous evaluation. Every PR that touches an orchestration layer must be blocked by a CI pipeline that runs 500 deterministic evals against the new reasoning flow. Building that telemetry is the AI strategy.

3. Graceful Degradation and Fallbacks

LLMs fail. APIs throttle. Endpoints rotate. If a model hallucinates malformed JSON and your core application crashes, that is an architectural failure. The model only exposed it.

A mature strategy wraps every AI interaction in circuit breakers . If the model fails three times, what is the deterministic fallback? If the cloud provider rate-limits you, where is the local, quantized 8B-parameter fallback model running in your own cluster?

Stop Chasing the Frontier

The frontier-model conversation is a distraction. Unless you are OpenAI, Anthropic, or Google, you do not win by having the smartest model. You win by having the tightest feedback loop, the cleanest data access, and the lowest cost per transaction.

A strong CTO designs for swapability : a single configuration commit, zero downtime, and telemetry that proves the new model performs 4% better on the exact workload that matters.

That is the strategy. Everything else is theater.

The Metric Everyone Tracks and Nobody Questions

Every quarterly planning cycle, the same conversation happens. The roadmap is too ambitious for the team. The proposed solution is more headcount. The exec team approves some fraction of the ask. Six months later, the team is bigger but the roadmap is still slipping.

This pattern persists because headcount is easy to measure and feels actionable. You can put a number on a slide. You can point to it in a board meeting and say “we’re investing in engineering.”

But headcount measures capacity the way adding lanes measures highway throughput. It works up to a point, then coordination overhead offsets the capacity gain. The tenth engineer doesn’t add 10% more output. They add nine new communication paths (36 becomes 45, a 25% jump), more code review load, and another person who needs context on every architectural decision.

The organizations getting this right have shifted to outcome metrics. They ask how fast decisions move from identification to resolution, where they used to ask how many people they have. They ask about change failure rate and recovery time, where they used to count merged PRs.

Staff Growth Versus Constraint Removal

Adding staff is an additive intervention. It puts more resources into the system. Constraint removal is a multiplicative intervention. It makes every existing resource more effective.

Consider a team of eight engineers where the average PR sits in review for 18 hours. Hiring two more engineers does nothing to fix the review bottleneck. It makes it worse because there are now more PRs competing for the same review bandwidth. But changing the review process, setting a 4-hour SLA, pairing reviewers with authors, and shrinking PR scope, can cut that 18 hours to 4 without adding a single person.

The same principle applies at every level. Slow deploys, unclear ownership, meetings that could be async documents, long approval chains. Each costs every engineer on the team hours per week. Multiply by team size and the waste adds up fast.

If 20 engineers each lose 5 hours per week to process friction, that’s 100 engineer-hours, equivalent to 2.5 full-time engineers doing nothing but waiting. Removing the friction is cheaper than hiring, faster to implement, and doesn’t increase coordination costs.

AI tooling has made this dynamic sharper. A well-structured team with good tooling and clear ownership regularly outships teams twice its size. But a poorly structured team with AI tooling just generates more half-finished work faster. AI amplifies the system it operates in, good or bad.

The Operating System of a High-Throughput Team

High-throughput teams share three operational patterns that have nothing to do with individual talent.

Clear intent over detailed instructions. When an engineer picks up a task, they should know the outcome that matters, not the exact steps to get there. “Reduce P95 latency on the search endpoint below 200ms” is clear intent. “Refactor the search query builder to use connection pooling” is a solution masquerading as a task. The first lets the engineer use judgment. The second removes it.

Teams that operate on intent move faster because decisions happen at the point of most information, the engineer doing the work, rather than being routed through a manager who has less context. This requires trust, and trust requires that the intent is genuinely clear and that the engineer has the authority to make reasonable tradeoffs.

Delegated authority with explicit boundaries. Every recurring decision type should have a documented owner and a decision boundary. “The on-call engineer can roll back any deploy without approval” is a delegation. “Database schema changes require review from the data team” is a boundary. When these are written down and understood, decisions happen in minutes instead of hours.

The failure mode is implicit authority. Nobody knows who can make the call, so everyone escalates. The escalation chain adds latency to every decision. In a team of 15, this can mean that a simple operational decision takes a day instead of an hour because it bounces between three people who each assume someone else owns it.

Async-first communication . Synchronous communication, meetings, Slack pings expecting immediate response, tap-on-the-shoulder interruptions, is the most expensive coordination mechanism. It requires everyone to be available simultaneously and context-switch away from focused work.

Async-first doesn’t mean no meetings. It means meetings are for decisions that genuinely require real-time discussion. Everything else is a written document, a recorded decision in a ticket, or a code review comment.

A Weekly Operating Cadence

Decision tempo separates high-throughput teams from slow ones. A lightweight weekly cadence keeps the system self-correcting without drowning in noise.

Weekly: review leading metrics. Cycle time from commit to production, change failure rate, time to recover from incidents, review queue depth, and decision latency on open questions. Don’t track vanity metrics like lines of code or number of PRs.

Biweekly: connect signals to causes. Is cycle time creeping up? Is one team’s change failure rate spiking? Are the same types of decisions getting stuck repeatedly? The goal is systemic diagnosis, not individual blame.

Biweekly: pick one constraint to remove. “This sprint, we’re going to cut our deploy time from 45 minutes to under 10” is a decision. “We’re going to improve developer experience” is not. One thing, not five.

Continuous: execute, measure, repeat. Act on the decision, measure the result, and feed it back into the next weekly review. If cutting deploy time didn’t improve cycle time, the constraint was elsewhere. Move to the next one.

Incentives That Reward Impact Over Activity

Most engineering organizations accidentally incentivize busyness. The engineer who closes the most tickets gets praised. The team that ships the most features gets the biggest headcount allocation. The manager who runs the most meetings looks the most engaged.

Throughput-oriented incentives look different.

Reward engineers who eliminate recurring work, not just complete it. The engineer who automates away a manual process that costs the team 10 hours per week has created more value than the engineer who ships a new feature used by 50 people.

Reward teams that improve their own throughput metrics, not just output volume. A team that cuts its change failure rate from 15% to 3% has freed up enormous capacity that was previously spent on rollbacks, hotfixes, and incident response. That’s worth more than two new features.

Reward leaders who make themselves less necessary. The manager whose team operates smoothly when they’re on vacation has built a better system than the manager who’s cc’d on every decision.

A 12-Week Operating Reset

For teams experiencing delivery drag, a structured reset works better than a reorg.

Weeks 1-3: Measure. Instrument cycle time, change failure rate, review latency, and decision latency. Don’t change anything yet. Establish a baseline that everyone agrees on.

Weeks 4-6: Remove one constraint. Pick the biggest bottleneck revealed by the data. If review latency is the worst, fix the review process. If deploy time is the worst, fix the pipeline. One constraint at a time.

Weeks 7-9: Delegate and document. Write down the top 10 recurring decision types and who owns each one. Set decision boundaries. Remove one layer of approval from the most common workflow.

Weeks 10-12: Sustain. Establish the weekly review cadence. Compare throughput metrics to the week-1 baseline. Identify the next constraint. Make the cycle self-reinforcing.

Teams that complete this reset usually see cycle time drop without adding staff. The improvement comes from removing friction that was invisible because everyone had adapted to it.

Board-Facing Metrics That Map Engineering to Business Risk

Boards understand risk and return. Translate engineering throughput into those terms.

Cycle time maps to market responsiveness. “We can respond to a competitor move in days, not months” is a strategic capability that boards care about.

Change failure rate maps to operational risk. “5% of our changes cause incidents” is a risk number a board can evaluate, especially when paired with the cost of those incidents.

Recovery time maps to resilience. “When something breaks, we fix it in under an hour” is a durability statement that affects customer trust and revenue protection.

Decision latency maps to organizational agility. “Strategic decisions take 2 days to reach execution, not 2 weeks” tells the board that the organization can adapt.

None of these metrics mention headcount. That’s the point. Headcount funds capacity. These metrics measure whether that capacity produces results.

The right choice still depends on maturity, product criticality, and how much shared infrastructure is needed. The structure also changes how teams manage AI inference cost , AI-native architecture , and governance. This post covers structures that stay stable under real delivery pressure.

Team models that hold up

Central platform team

A central platform team builds and operates shared AI infrastructure, evaluation tooling, and common components. This model fits organizations that need consistency, strong governance, and shared reliability across many teams. It works particularly well in regulated industries where auditability and compliance require one view across all AI usage.

Where it breaks down is speed. When every product team routes requests through a central group, the platform team becomes a bottleneck. This is common in organizations with ten or more product teams sharing a three-person AI platform group. The queue grows, the platform team triages by business priority, and lower-priority teams either wait or build workarounds. If you choose this model, staff it generously or accept that iteration speed will be gated.

Embedded in product teams

AI engineers live inside product teams and ship features end to end. This model fits products where AI is core to user experience and iteration speed matters. A team building a search product or a conversational interface benefits from having the AI engineer sit in the same standup, hear the same customer feedback, and own the same on-call rotation as the rest of the squad.

The risk is fragmentation. When several product teams solve the same problems independently, you end up with three prompt evaluation frameworks, two model routing strategies, and no shared understanding of cost. This model works best when you have a small number of product teams, or when AI use cases are different enough that shared infrastructure would not save much effort.

Hybrid model

A small platform team provides shared foundations while product teams embed AI engineers for delivery. This is the most common model because it balances infrastructure consistency with product-team autonomy.

The platform team in a hybrid model typically owns inference infrastructure, model selection and routing, shared evaluation tooling, and cost observability. Product-team AI engineers own feature-level prompts, domain-specific evaluation datasets, and production behavior for their use case. The boundary between these layers matters more than the org chart. Writing down the interface contract, what the platform provides and what the product team owns, prevents most of the friction that kills hybrid models.

The hybrid model fails when the platform team behaves like an internal vendor rather than an enabling function. If product teams have to file tickets and wait for releases to get basic capabilities, you’re back to the central bottleneck problem with extra steps. The platform team should ship self-serve tooling and stay close to the product engineers who use it.

Decision criteria

Use the structure that matches the work, not the other way around. Three factors tend to dominate the decision.

First, how many teams need the same AI capabilities and standards. If the answer is two, embedded is fine. If it’s eight, you need a platform function or you will drown in duplication.

Second, how frequently AI features ship and change. High iteration velocity favors embedded engineers who can move with the product team’s sprint rhythm. Slower, more deliberate releases are easier to route through a central group.

Third, how much operational risk and compliance pressure exists. Regulated environments benefit from centralized governance and audit trails. Lower-risk consumer products can afford more distributed ownership.

Add one more that teams often forget: how expensive mistakes are. If the blast radius is high, you want tighter standards, stronger review, and explicit gating.

Roles and responsibilities in 2026

AI engineer

Builds AI features inside product flows, owns evaluation in production, and partners with design and data for quality. The role blends software engineering with systematic testing and monitoring. In 2026, the AI engineer is distinct from the ML engineer or data scientist. An ML engineer typically focuses on model training, fine-tuning, and training infrastructure. A data scientist focuses on analysis, experiment design, and statistical rigor. The AI engineer works downstream of both: integrating models into products, building evaluation harnesses that catch regressions, and owning production behavior. Think of it as the difference between building the engine and building the car.

AI platform engineer

Owns shared systems like inference services, evaluation pipelines, and model routing. The focus is reliability, scale, and cost control for many teams at once. This role requires strong infrastructure engineering skills and an understanding of how product teams consume AI capabilities. Strong platform engineers pair with product-team AI engineers to understand real usage patterns rather than building abstractions in isolation.

AI product manager

Defines the use case scope, success metrics, and rollout plan. The role emphasizes rigorous tradeoffs between quality, latency, and cost, with clear ownership of user outcomes. An AI PM needs to be comfortable with probabilistic behavior and must resist the urge to promise deterministic results. They own the decision of when a feature is good enough to ship and when it needs more evaluation investment.

Team size and scaling

Most teams start too large. A single AI engineer embedded in a product team, supported by a lightweight shared toolkit, is enough to validate whether AI adds value to a workflow. Scaling up before validation leads to expensive teams that optimize solutions to the wrong problems.

For the platform function, two to three engineers can support four or five product teams if the scope is well-defined. Once you pass that ratio, the platform team needs to grow or the scope needs to shrink. A common mistake is building a platform team of six that tries to serve fifteen product teams and ends up serving none of them well.

When hiring, prioritize engineers who have shipped AI features into production over those with impressive research backgrounds but no operational experience. The gap between a working prototype and a reliable production system is where most AI projects stall, and that gap is an engineering problem, not a research problem.

AI security / governance partner

Whether this is a dedicated role or a shared function, someone must own policy: data handling rules, permission models, logging requirements, and review gates. Teams that skip this role tend to slow down later under audit pressure.

Common failure modes

These patterns show up across teams. Platform teams that ship abstractions without enabling product speed often build elaborate internal APIs nobody asked for while product teams work around them. Product teams that skip evaluation and discover quality issues late usually treat AI features like deterministic code, then get surprised when behavior drifts after a model update. Ambiguous ownership for model behavior in production creates incidents where nobody knows whether the platform team or the product team should respond. Usually it is both, but the escalation path was never defined.

What This Looks Like At Different Sizes

• Small startup (1 to 2 AI engineers): embed in the product, keep tooling lightweight, and use strict output validation plus a small eval set. Avoid platform work that nobody will maintain.
• Mid-size company (multiple product teams): introduce a small platform function to own routing, eval tooling, and shared guardrails, while keeping delivery embedded in product teams.
• Large org (regulated, many teams): platform + governance becomes non-negotiable. Embedded teams still ship features, but standards, audit trails, and permissions need central ownership.

Operating practices that matter

Evaluation is a first-class deliverable. Teams that ship reliably treat test sets, error analysis, and monitoring as part of every release. Evaluation datasets are versioned alongside code, and regressions in evaluation scores block releases the same way failing tests would.

Clear service ownership and on-call rotations prevent AI incidents from becoming orphaned problems. Every AI feature in production should have a named owner who is paged when it degrades. Cost management belongs in planning, not just finance review after launch. Model inference costs can surprise you, and the time to catch a cost spike is before it compounds for a month.

A pragmatic starting point

If the organization is early, start embedded with a lightweight shared toolkit and a small platform function. As adoption grows, formalize the platform team and tighten standards. Revisit the structure every six months, because the problem shifts as AI moves from pilot to core workflow. The structure that got you to your first production feature is rarely the structure that will support your tenth.

FAQ

What is the best AI team structure in 2026?

For most companies, the best default is hybrid: a small platform group owns shared infrastructure, routing, evaluation, and governance, while product teams own delivery and workflow quality.

When should AI engineers be embedded in product teams?

Embed AI engineers when iteration speed and workflow context matter more than central consistency. This works best when use cases are distinct or when the company is still validating where AI creates value.

When does a central AI platform team make sense?

A central platform team makes sense when many product teams need the same model access, evaluation tooling, governance, and cost controls. It fails when it becomes a ticket queue.

Who owns AI quality in production?

The product team should own user-facing behavior. The platform team should own shared reliability, model access, routing, observability, and guardrails. The interface between those teams must be explicit.

If the answer is no, you aren’t scaling. You’re doing pilots.

I see this constantly. The technology isn’t the bottleneck. Models are good enough. The tooling exists. What’s missing is the operating model: the boring work that turns a demo into something that runs in production for years, with clear ownership, predictable costs, and a way to handle failures.

The pilot trap

Every large organization I’ve worked with has successful AI pilots : impressive demos, enthusiastic teams. Then the question comes: “How do we do this across 50 teams?”

The answer is never “give everyone API keys and let them figure it out.” That path leads to duplicated effort, inconsistent security practices, and a support burden that lands on the same three experts who built the original pilot. I’ve watched this happen more than once, including at a large telecom company I worked with. The pattern is remarkably consistent.

What an AI operating model looks like

Separate shared capabilities from local execution. It’s no more complicated than that.

Shared capabilities are the things every team shouldn’t have to reinvent: platform services , security guardrails, eval frameworks, model access, and policy. A small central group owns these. Their job is to make it easy to build safely.

Local execution belongs to the business teams who own use cases and outcomes. They pick the problems. They ship the features. They own the quality.

The balance matters. Too centralized, and you create a bottleneck where every AI idea has to go through a committee. Too distributed, and you get security gaps, wasted spend, and inconsistent quality. The sweet spot is a lightweight forum that resolves cross-team issues and keeps standards current without becoming a gate.

Governance as a lane, not a wall

The word “governance” makes engineers groan. I get it. But governance done right makes you faster, not slower.

The practical version is simple: data access is intentional and documented, model behavior is testable, audit trails exist, incident response has an owner, and rollback is a button, not a project.

If governance is a checklist that lives in a SharePoint nobody reads, teams will work around it. If it’s embedded into the build process (eval gates in CI, prompt versioning in the repo, monitoring that ships with the feature), teams will rely on it because it makes their lives easier.

Enablement, not evangelism

Scaling fails when enablement is treated like a training event. A two-hour workshop on “prompt engineering” doesn’t help a product team ship a reliable feature. What helps: repeatable patterns, starter templates, and a support path that doesn’t depend on cornering the same overworked ML engineer.

Extend the practices you already have. Your teams already know how to run CI pipelines, do code reviews, and deploy behind feature flags . Add eval suites to the pipeline. Add prompt reviews to the PR process. Make AI features fit into the existing delivery workflow instead of inventing a parallel one.

What to measure

Not tool adoption. Not number of pilots. Not “AI maturity scores.”

Track what’s in production and whether it’s maintained. Track support burden. Track which use cases are paused or retired. These signals tell leaders where to invest and what to stop. Everything else is decoration.

The sequence that works

Establish the platform and guardrails first. Prove the model with a small set of high-leverage use cases. Expand to more teams with consistent support. Review outcomes and simplify anything that causes friction.

The order matters. Each step creates the preconditions for the next. Skip ahead and you’re scaling demand faster than capability, which is how you end up with 50 broken pilots instead of 5 working ones.

This is a management problem. Treat it like one.

That sounds harsh. It’s also true.

The Ownership Gap

Here’s how it usually goes. A company decides to “do AI.” They hire an ML engineer, maybe two. Those engineers build a demo. Leadership is impressed. Then someone asks, “Who owns this in production?” and the room goes quiet.

The ML engineer built the model. The product team didn’t spec the success criteria. The data engineer wasn’t involved. The designer has no idea what happens when the model gets it wrong. And nobody defined what “getting it wrong” even means.

I’ve seen this exact pattern at large enterprises and small startups. The blocker is structure.

Three Models That Work

Every successful team I’ve seen fits one of three structures, and the core tradeoff has not changed.

Embedded. AI engineers sit inside product teams. They ship features directly, own the evaluation, and live with the consequences of their choices. This works when AI is a feature, not a platform. The downside: practices drift across teams because there’s no central coordination.

Platform. A central team builds shared infrastructure: model serving, evaluation harnesses, prompt management, observability. Product teams consume that platform. This works when multiple products need AI. The downside: the platform team gets pulled in every direction and loses focus on any single product.

Hybrid. A platform team builds the core. Embedded engineers in product teams customize it. This is the most common pattern at companies that have scaled this successfully. It also requires the most coordination. Without clear ownership boundaries, it degenerates into blame-passing between platform and product.

Pick the model that matches your current scale, not the one you hope to need in two years.

Who to Hire

The best AI engineers I’ve worked with share a few traits that don’t show up on resumes.

They can explain how their system fails. Not just how it works, but how it breaks and what happens when it does. This is the best interview signal I’ve found.

They think in systems, not models. The model is one component. The retrieval layer, validation step, fallback path, and monitoring are just as important. A candidate who talks only about model architecture is missing the point.

They build evaluations before they build features. If you can’t measure whether the thing works, you’re guessing. The best engineers treat eval sets like test suites. They version them, maintain them, and refuse to ship without them.

They’ve shipped something to real users. Not a notebook. Not a demo. Something people used, complained about, and forced them to iterate on. Production experience changes how you think about every design choice.

The Operating Loop

Fancy process frameworks aren’t necessary. A tight loop between four phases covers it:

Discovery. Define success in measurable terms. What does “good” look like? What are the edge cases? Is the data available? A clear definition of success is worth more than a long list of ideas.

Prototyping. Run small experiments with real examples. Document the failures, not just the successes. Bring domain experts in early. They know the edge cases you’ll miss.

Development. Build the evaluation suite first. Version prompts and retrieval logic as code. Test against known failure cases whenever models or data change.

Production. Roll out gradually. Monitor quality and cost in the same dashboard. Treat regressions as product issues with named owners, not vague “the model changed” explanations.

What Goes Wrong

The problems I see most often aren’t technical:

• Nobody owns evaluation for a specific feature. There’s a shared checklist but no named person.
• Success criteria are undefined, so feedback becomes opinion. “This doesn’t feel right” isn’t actionable.
• The pipeline is too complex for the use case. Someone built a multi-agent system for what should have been a single prompt.
• Knowledge stays in people’s heads. When someone leaves, the team loses context that took months to build.

Fix these four problems and you’re ahead of most AI teams. No new tools required. No new hires. Just clarity about who owns what and how you know it’s working.

I see this pattern across telecom and fintech organizations, large and small. The demo-to-production gap is an organizational problem far more than a technical one.

The demo was the easy part

A POC can skip everything that makes enterprise software hard. It runs on a developer’s laptop with test data. It doesn’t need to handle real user volumes. During a demo, nobody asks about audit trails or data retention policies.

Then the project moves toward production and reality hits. Security wants a threat model. Legal wants to know where the data goes. The platform team wants to know who pays for compute. The data science team discovers the training data is messier than expected. None of this is surprising. These are the same problems every enterprise system faces, plus a few new AI-specific ones: model drift, prompt management, and probabilistic outputs.

The teams that get stuck are the ones that treated the POC as the starting line instead of a feasibility check.

Start boring, stay boring

The single best predictor of success I’ve seen is picking a first use case that’s low-risk and internal. Something where a human reviews the output before anything happens. Document summarization for internal teams. Draft generation for support responses that get edited before sending. Classification of inbound requests to route them to the right queue.

These aren’t exciting. That’s the point. You want a use case where a bad output is an inconvenience, not a liability. One where you can iterate on prompts and evaluate quality without a customer ever seeing an unpolished result.

I keep telling teams the same thing: your first AI feature should be invisible to customers. Ship it internally, prove it works, build the muscle memory for operating AI in production, then expand.

Build the platform before the pilots multiply

Here’s what happens when you don’t have a shared platform: every team builds its own integration. They pick different models, prompt patterns, and logging approaches. Six months later, you have eight AI features and no way to compare quality, manage costs, or enforce policies across them.

The fix is unglamorous. Build a thin shared layer early. It needs three things:

1. Centralized model access with authentication, rate limiting, and cost tracking.
2. A prompt registry so prompts are versioned, reviewable, and not buried in application code.
3. Evaluation tooling that every team can use to measure output quality against a golden set.

This doesn’t need to be perfect or fully featured. It needs to exist before the third team starts building their own AI integration. I’ve watched organizations try to consolidate after the fact. It’s painful and expensive.

Governance that enables instead of blocks

The worst governance models I see are designed by committee without input from the engineering teams that have to live with them. They produce a 40-page policy document, a six-week review cycle, and a strong incentive for teams to quietly build things without telling anyone.

Good governance is lightweight and fast, and it treats responsible AI as risk management . A one-page use case template. A clear risk-tier system: low risk gets self-service approval, high risk gets review. A standing meeting where legal, security, and engineering are in the same room instead of a months-long email chain.

One organization I worked with reduced its AI approval cycle from eight weeks to five days by switching from a document-based review to a 30-minute live walkthrough with all stakeholders. Same rigor. Fraction of the time.

The organization is the bottleneck

When enterprise AI projects fail, the organization is usually less ready than the technology. The AI works fine in the demo. The procurement process takes four months. The data team can’t provide clean training data. The legal review has no precedent to follow, so it defaults to “no” until someone escalates.

If you want to ship AI in an enterprise, spend less time evaluating models and more time clearing organizational roadblocks. Get a budget owner. Get a security sponsor. Get data access sorted before you write the first prompt.

Process beats talent. Every time.

It usually doesn’t. Not because reorgs are bad, but because they’re solving the wrong problem. If your reorg is a PowerPoint exercise to make the reduced headcount look intentional, stop. Fix ownership gaps, not org charts. The people who survived the layoffs already know what’s broken. Ask them.

What actually happened

Here’s the real situation at most of these companies. They cut 20-30% of engineering. The layoffs weren’t surgical. They hit across teams, sometimes based on recency bias or cost rather than capability. The survivors are demoralized, overloaded, and wondering if they’re next.

Then someone proposes a reorg. New team names, new reporting lines, maybe a shift from project teams to product teams. The slide deck looks clean. The reality is chaos.

What these orgs need is three things: clear ownership of the systems that still matter, explicit decisions about what to stop doing, and honest communication that doesn’t insult people’s intelligence.

When a reorg is actually justified

Sometimes the layoffs genuinely changed the shape of the work enough that the old structure doesn’t make sense. Real signals:

• Two teams were merged but nobody decided which team’s approach wins, so both codebases rot.
• A critical system lost its entire owning team and it’s being maintained by whoever has time, which is nobody.
• The product strategy changed alongside the layoffs, and the old team boundaries don’t align to the new priorities.
• Dependencies between teams have become the primary blocker because the connecting-tissue people were let go.

These are structural problems that structural changes can help with.

When it’s not

And sometimes the reorg is cover. I’ve seen all of these:

• A new VP wants to “put their stamp” on things. The org was fine. The VP needed to justify their hire.
• Conflict between two directors is being “solved” by separating their teams instead of addressing the conflict.
• Leadership wants to signal activity to the board. “We restructured” sounds better than “we’re still figuring it out.”
• Someone read the Team Topologies book on a flight and now every conversation includes the phrase “stream-aligned.”

If the root problem is people, process, or strategy, moving boxes around won’t help. It’ll just add a transition tax to an already exhausted org.

What I actually recommend

Based on what’s worked across these situations, the playbook is unsexy. Which is why it works.

Step 1: Map what’s actually broken. Not theoretically broken. Actually broken. Talk to the ICs. They know which systems are unowned, which dependencies are blocked, and which meetings are pointless. I usually spend the first week just listening. The engineers are relieved someone is asking.

Step 2: Make ownership explicit. Write down, for every critical system: who owns it, who’s on-call for it, and what the plan is. “Shared ownership” is a euphemism for “no ownership.” If a system matters, one team owns it. Full stop.

Step 3: Kill things. This is the hard one. After layoffs, you have fewer people. You can’t do the same amount of work. Something has to stop. The reorg should make it clear what’s being stopped, not just what’s being reorganized. At one company, the single most impactful change was killing two internal tools that each had one user. That freed up enough capacity to actually staff the important systems.

Step 4: Communicate like adults . The worst thing I’ve seen is the “exciting restructuring” email that uses words like “streamlined” and “focused” to describe what everyone knows was a layoff aftermath. Don’t do that. Be direct: “We lost good people. Here’s how we’re adjusting. Here’s what we’re stopping. Here’s what we’re doubling down on. Questions welcome.”

At a mobility startup, we went through a version of this during a pivot. Smaller scale, but the same dynamics. The team that handled it best was the one where the lead said “I don’t have all the answers yet, but here’s what I know and here’s when I’ll know more.” Trust went up. Attrition went down.

The transition matters as much as the design

Even when the new structure is right, the transition can kill it. A few things that consistently matter:

• In-flight work needs a home. Every project that’s mid-stream needs an explicit owner in the new structure. Not “we’ll figure it out.” A name, by the end of the week.
• New teams need a charter. Not a manifesto. A one-pager: what you own, what you don’t, what your first quarter looks like. Teams that don’t get this spend months figuring out their boundaries through conflict.
• Give it six months. The urge to tweak the new structure after four weeks is strong. Resist it. Reorgs take a full quarter to settle and another quarter to show results. Constant adjustment destroys any chance of stability.

How to know if it worked

Short-term (first month): are the ownership questions answered? Do people know who to go to? Has the “who owns this?” Slack question frequency dropped?

Medium-term (one quarter): is delivery predictability improving? Are cross-team dependencies less painful? Are the right things getting built?

Long-term (two quarters): retention. If you’re losing the people you wanted to keep, the reorg failed regardless of what the delivery metrics say. The engineers who stayed through layoffs and a reorg have a very low tolerance for more disruption. Respect that.

What the survivors are watching

Reorgs after layoffs are emotional events disguised as structural ones. The people in those boxes are tired, uncertain, and watching closely to see if leadership actually has a plan or is just rearranging furniture.

The best restructuring I’ve seen this year was at a company where the CTO stood up and said: “This is hard. We’re going to get some of it wrong. But here’s the logic, and here’s how we’ll adjust.” No spin. No excitement. Just honesty.

That org stabilized in eight weeks. The one that did the polished all-hands with the aspirational vision? They’re still losing people.

At a mobility startup, we ran out of runway while the product was still finding its footing. At a startup I founded, I built for a market that was still finding its legs. In a founder program, half the cohort pivoted their entire thesis in the first month. Uncertainty isn’t a 2023 thing. It’s a startup thing that finally hit big companies too.

The layoffs , budget cuts, and strategic pivots of early 2023 feel familiar to anyone who has founded something. The difference is scale. When it’s your five-person startup, you talk it through over coffee. When it’s a 200-person engineering org, the communication problem compounds fast.

What Your Team Actually Needs

When things get uncertain, engineers ask the same four questions no matter the company:

What matters right now? How stable is the direction? Do I have any say in this? And does my daily work actually connect to something real?

These aren’t complicated needs. They just become urgent when the floor is shifting. You don’t need perfect answers. You need consistent signals.

At a fintech startup, when we had to make hard prioritization calls, the single most useful thing I did was be direct about what we weren’t going to build. People can handle “we aren’t doing X and here is why.” They can’t handle silence followed by a surprise reorg.

Communication Is the Whole Job

When I was working with larger organizations, I noticed something: the engineering leaders who struggled most were the ones who communicated least. Not because they were hiding things, but because they were waiting for certainty before saying anything.

That’s backwards. In uncertain times, the absence of communication is the communication. And what it communicates is “nobody knows and nobody is in charge.”

A simple pattern that works: here is what we know and why it matters, here is what we don’t know and when we’ll revisit it, here are the decisions that flow from this context.

Say it every week. Even if nothing changed. Especially if nothing changed. That consistency is what creates trust.

Stop Starting, Start Stopping

When budgets tighten, the instinct is to do more with less. That’s wrong. The correct move is to do less, better.

Ask three questions about every active project: Does it protect or grow the core business? What happens if we ship it versus if we delay it? Is there a smaller version that delivers the essential outcome?

If the answers are weak, pause the project. Explicitly. Say “we’re stopping this because we need to focus” instead of letting it die quietly of resource starvation. Teams respect that. They don’t respect the slow fade where a project is technically alive but has no one working on it.

The Standards That Can’t Flex

Pressure invites shortcuts. Some shortcuts are fine. Ship with less documentation. Defer the refactor. Reduce scope on a feature.

But some things are non-negotiable: security practices, code review on critical paths, and operational ownership for anything in production. When you cut those, you create compounding debt that hits you exactly when you can least afford it.

The job is to be explicit about where quality is required and where flexibility exists.

Resilience Isn’t a Motivational Poster

Resilience is operational . Cross-train key responsibilities so a single absence doesn’t stall the team. Keep critical knowledge written down, not just in someone’s head. Maintain a pace that doesn’t depend on perpetual urgency.

I learned this the hard way at the mobility startup. We had one person who understood the payment integration end to end. When they were out for a week, we couldn’t debug a billing issue that was actively losing us users. Never again.

Not boring in the sense of uninspired. Boring in the sense of predictable. When something breaks, they know who handles it. When someone leaves, the work continues. When priorities shift, they adapt without a crisis meeting. Boring means the system works without heroics.

This year put that theory to the test. Layoffs , budget cuts, reorgs, shifting priorities: 2022 threw a lot at engineering teams. The ones that stayed productive through it all shared some common traits. None of them were flashy.

Heroics Are a Smell

When you hear “Sarah stayed up until 3am and saved the release,” that isn’t a success story. That’s a failure story with a happy ending. It means the system depended on one person being awake and willing to sacrifice sleep. That works once. It doesn’t work twice.

At a mobility startup, we had a period where our deployment process was held together by one engineer’s knowledge and willpower. It felt fine until that engineer took a vacation and nobody knew how to handle a rollback. We fixed it by making the process boring: documented, automated, executable by anyone on the team.

Resilience is the opposite of heroics. It spreads capability so that no single failure, human or technical, creates a crisis.

Psychological Safety Isn’t a Buzzword

I know “psychological safety” sounds like something from an HR slideshow. But it’s the most practical thing I can recommend for team resilience.

If people on your team can’t say “I don’t understand this,” “I made a mistake,” or “I think this plan is wrong,” you have a team that hides problems until they become incidents. I’ve seen this play out at multiple organizations this year. The teams that recovered fastest from shocks were the ones where bad news traveled quickly because people felt safe delivering it.

How to tell if your team has it:

• People ask questions in meetings instead of nodding along.
• Risks get raised before they become outages.
• Postmortems discuss systems and processes, not blame.

Leaders set this tone through small repeated actions, not speeches. How you react to the first mistake someone reports to you determines whether they will report the next one.

Kill Single Points of Failure (In Your Org Chart)

Every team has them. The person who’s the only one who understands the billing system. The engineer who always handles the deploys. The manager who’s the only one with context on why the architecture looks the way it does.

These aren’t star performers. They’re organizational risks.

Rotate on-call. Pair on critical systems. Document the “why” behind decisions, not just the “what.” Make sure at least two people can deploy, debug, and recover every service that matters. This isn’t exciting work. It’s the work that keeps the team functional when someone is sick, leaves, or gets pulled onto a different project.

At a large consumer platform, the infrastructure team made a deliberate effort to rotate ownership of critical services every quarter. It was slower in the short term. It made the team dramatically more resilient in the medium term.

On-Call That Doesn’t Burn People Out

On-call is where team resilience gets stress-tested, and incidents are where it shows. A sustainable rotation has a few non-negotiable properties:

Alert quality matters. If your pager fires for things that aren’t actually urgent, people stop taking it seriously. Tune your alerts. Remove the noise. Every false alarm erodes the team’s willingness to respond.

Runbooks must work under stress. A runbook that requires calm reading comprehension and background knowledge isn’t a runbook. It’s documentation. Real runbooks work at 2am when you’re tired and anxious: clear steps, decision trees, escalation paths.

Recovery time is real time. If someone gets paged at 3am, they shouldn’t be expected to perform at full capacity the next morning. Build recovery time into the rotation. Burnout is a team problem, not an individual weakness.

Two Habits That Compound

After working with a lot of teams, I think two practices matter more than most:

Retrospectives that produce action items. Not retrospectives that produce feelings. Not retrospectives that produce a long list of complaints. Short, focused retrospectives that produce two or three concrete follow-ups, with owners and deadlines. Then actually do them.

Celebrating progress. Teams under pressure tend to only talk about what’s wrong. Acknowledging what went well, even small things, keeps momentum and morale from decaying. This sounds soft. It works.

Built Before the Crisis

Resilient teams aren’t built during a crisis. They’re built in the quiet periods before one. Shared knowledge, clear processes, honest communication, sustainable pace: none of it is exciting. All of it compounds.

The teams that came through 2022 in good shape didn’t have a secret. They had discipline. And discipline, unlike heroics, scales.

This isn’t a framework post. It’s what I’ve seen and what I think matters.

The Shift Nobody Planned For

Eighteen months ago, every company I talked to was hiring aggressively. “We can’t find enough engineers” was the universal complaint. Now the complaint is “we hired too fast and the math doesn’t work.”

The market shifted from rewarding growth to rewarding efficiency. That’s a legitimate economic correction. But the speed of the pivot is brutal. Teams that were told to scale fast are now being told to do more with less, sometimes by the same leadership that set the original targets.

What I’ve Seen Go Wrong

The worst layoffs I’ve watched (and I’ve watched a few this year) share common traits.

Multiple waves. Nothing destroys trust faster than a “one-time reduction” followed by another one six weeks later. If leadership doesn’t know the full scope of cuts, they should say so honestly rather than promise stability they can’t guarantee.

Silence from above. At one organization I worked with, the engineering org learned about layoffs from Twitter before they heard from their own leadership. That isn’t a communication problem. That’s a respect problem.

Pretending the plan didn’t change. After cutting 20% of engineering, one organization kept the same roadmap and the same deadlines. The remaining team burned out within two months. Three more people left voluntarily. The original cost savings evaporated.

Knowledge walking out the door. I saw a team lose the only person who understood their payment processing pipeline. No documentation , no pairing history, no runbooks. Three months later they were still reverse-engineering their own system.

What I’ve Seen Go Right

The organizations that handled this well did a few things consistently.

They were honest about the business reason. Not corporate-speak, not “rightsizing for the future.” Honest: “Revenue is down, burn rate is too high, and we need to cut costs to survive.” People can handle hard truths. They can’t handle feeling manipulated.

They treated departing people with real dignity. Generous severance where possible. Genuine references. Time to say goodbye. The remaining team watches how you treat the people who leave. It tells them everything about what they can expect.

They immediately rescoped. Smaller team means smaller roadmap. Full stop. The best leader I watched through this process cancelled three initiatives within a week of the layoff, told the team “we’re doing these two things well, nothing else,” and stuck to it. That team stabilized faster than any other I saw.

For the People Who Remain

Survivor guilt is real and poorly understood. You kept your job, so you should be grateful, right? Except your friend got walked out, your workload doubled, and nobody has told you whether more cuts are coming. “Grateful” isn’t the word that comes to mind.

What actually helps:

Acknowledge the loss. Don’t skip past it. The people who left were colleagues, mentors, friends. Pretending everything is normal is insulting and counterproductive.

Reset expectations explicitly. What are we building? What are we not building? Who owns what now? If these questions aren’t answered within a week, anxiety fills the vacuum.

Protect sustainable pace. A smaller team carrying a larger roadmap is a team in the process of losing more people. Voluntary attrition after layoffs is the hidden second wave that leadership never budgets for.

Distribute Knowledge Before You Have To

The best insurance against knowledge loss is rotation, even more than documentation. Pair on critical systems. Rotate on-call. Make sure at least two people can deploy, debug, and recover every service that matters.

I keep coming back to this: resilience means building systems, human systems included, that can absorb shocks without collapsing. That means shared ownership, documented decisions, and deliberately avoiding single points of failure in your org chart.

For Leaders

You can’t control the macro environment. You can control how clearly you communicate, how honestly you scope, and how consistently you protect your team’s focus.

Watch for burnout signals: declining code quality, slower response times, people going quiet in meetings who used to speak up. These are leading indicators of the next round of attrition: the voluntary kind that hurts even more because it’s your best people who leave first.

Advocate upward for realistic expectations. If leadership expects the same output from a smaller team, push back with data. “We can deliver A and B by Q1, or A, B, and C by Q2. Pick one.” That isn’t defiance. That’s responsible leadership.

A Personal Note

Having founded a company through a founder program, I know what it’s like to make hard calls about scope when the money is running out. It’s never clean. But the difference between organizations that recover and organizations that spiral comes down to honesty and scope discipline.

Heroics don’t scale. Discipline does. The teams that will come out of this cycle stronger are the ones that cut scope honestly, protected their people’s energy, and resisted the temptation to pretend nothing changed.

I’ve watched teams drown in dashboards. At one company I walked into a weekly review where the VP proudly scrolled through forty-seven metrics. Nobody in the room could tell me which three mattered most. That isn’t measurement. That’s decoration.

The goal is simple: a small set of numbers that tell you whether the system (the whole system of people, code, and process) is getting healthier or sicker. Everything else is noise.

Why Most Metrics Backfire

Metrics fail when they measure motion instead of progress. Lines of code reward verbosity. Story points inflate the moment managers tie them to performance reviews. Ticket counts incentivize splitting work into trivial pieces. Time-in-seat confuses presence with output.

Goodhart’s Law isn’t a thought experiment. I watched it play out at a company where a “PRs merged per sprint” target led to engineers opening tiny, low-value PRs just to hit the number. The charts looked great. The product didn’t move.

If a metric can be gamed without improving outcomes, it will be gamed. That isn’t cynicism. It’s human nature meeting bad incentive design.

The DORA Four: Still the Best Starting Point

The four DORA metrics have held up across every team shape and stack I’ve worked with, as long as nobody puts them on a performance review . They connect speed to stability without prescribing a specific process.

• Deployment frequency: how often you ship to production.
• Lead time for changes: from commit to running in prod.
• Time to restore service: how fast you recover from incidents.
• Change failure rate: how often a deployment causes a problem.

These work because they measure the path from idea to production and what happens when that path breaks. Collect them at the team or service level. Never use them to rank individuals. The moment you turn DORA into a leaderboard, the numbers become meaningless.

At a large consumer platform, we tracked deployment frequency per service as a health signal, not a target. When a team’s frequency dropped, it was usually a sign of flaky tests or a painful merge process. System problems, not people problems.

Reliability: Measure What Users Feel

Availability percentages are fine, but they hide a lot. A service can be “99.9% available” and still have p99 latency so bad that the checkout flow feels broken.

Track what customers actually experience:

• Latency at a meaningful percentile (p95 or p99, not averages)
• Error rates on critical paths
• Throughput trends

Error budgets are the best policy tool I’ve seen for balancing reliability with feature velocity. Agree on how much unreliability is acceptable for a service in a given period. When the budget burns too fast, slow down feature work and fix the foundations. When there’s budget left, ship faster. Simple.

The key is treating error budgets as a decision framework, not a spreadsheet exercise. If nobody changes behavior when the budget burns, you don’t have an error budget. You have a dashboard.

Developer Experience Is a Leading Indicator

By the time delivery metrics go red, the developer experience problems that caused them are months old. Slow feedback loops, painful CI, confusing onboarding: these drag on quality and morale long before they show up in DORA numbers.

A few signals that capture friction without turning into surveillance:

• Time to first meaningful change for a new engineer. If onboarding takes three weeks before someone ships anything real, that’s a system problem.
• End-to-end build and test duration. If CI takes forty minutes, developers batch changes and context-switch. Both hurt quality.
• Time to first review on a PR. Review latency is one of the most underrated bottlenecks. A PR sitting for two days is two days of context decay.
• Time from merge to production. If this is hours instead of minutes, your deployment pipeline needs work.

These are system health checks. Improvements here compound into better delivery and reliability outcomes downstream.

Connect to Business Outcomes

Engineering metrics should relate to things the business cares about. Not everything needs a revenue number attached, but there should be a clear line between what you measure and why it matters.

Three signals that bridge the gap:

• Feature adoption or usage change after launch
• Customer-reported issues (trending down is good; zero is suspicious)
• Time from idea approval to customer availability

At a real-time messaging platform I worked with, connecting deployment lead time to customer feature requests was eye-opening. We could show exactly how much faster a customer got value when the pipeline was healthy versus when it was degraded. That made infrastructure investment easy to justify.

How to Start Without Creating Overhead

Pick four to six metrics. Automate collection. Review monthly with a trend line, not a snapshot. That’s it.

The pitfalls are predictable:

• Using metrics to punish. This kills psychological safety and data quality simultaneously.
• Expanding the list. Every quarter someone wants to add “just one more.” Resist. If something new goes in, something old comes out.
• Reporting numbers without narrative. A chart without context is an inkblot test. Everyone sees what they want to see.

If a metric drives unhelpful behavior, change it or kill it. Metrics exist to guide decisions, not to prove a point. The best set is small enough to remember, stable enough to trend, and connected enough to tell a coherent story about how your engineering system is actually performing.

At a mobility startup, we got this down to day two for most new hires. Not because we had some elaborate onboarding program. Because we had a checklist, a buddy system, and a backlog of small tasks tagged “good first issue.” The new engineer’s first PR was reviewed and merged before they finished reading the architecture docs. That’s the order it should happen in. Ship first, context second.

Why most onboarding stalls

Most onboarding programs are designed around what the company wants to communicate, not around what the new hire needs to be productive. Day one becomes a parade of slides: company history, org chart, values, benefits, security training. The engineer sits through hours of content they won’t remember, and by the end of the day they still can’t push to the repo because their access request is pending.

Every hour spent in orientation that could have been spent writing code is a signal that the company values process over output. New hires pick up on that fast.

Week one: access, a real task, a buddy

Access on day one. Laptop, accounts, repo access, dev environment: all of it should be working before the engineer opens Slack for the first time. If access provisioning takes more than a day, your onboarding is already behind. Automate it. Test the automation quarterly by running it against a clean machine.

A real first task. Not a tutorial. Not “read the docs.” A real bug fix or small feature that touches the production codebase. It should be small enough to finish in a day, scoped enough to not need deep context, and assigned to a specific reviewer who will prioritize the review.

The first merge matters more than any presentation. It proves the workflow works, the environment is set up correctly, and the engineer can contribute. Everything after that is momentum.

A buddy, not a babysitter. The buddy answers the dumb questions. “Where do I find the staging URL?” “Who reviews changes to this service?” “How do I get a test database?” The buddy isn’t responsible for the new hire’s career development or performance evaluation. That’s the manager’s job. Keep the roles separate.

Stop over-documenting, start pairing

I’ve seen teams spend months building elaborate onboarding wikis that nobody maintains. They go stale within a quarter. A 30-minute pairing session where the buddy walks through the deploy pipeline is worth more than a 20-page document about the deploy pipeline.

Keep documentation focused on what changes slowly: architecture overview, service map, on-call runbook. For everything else, pair. New hires should be encouraged to update docs when they find gaps. Fresh eyes catch stale content better than any scheduled review.

The 30-day check

By the end of month one, a new engineer should be able to pick up a ticket, implement it, get it reviewed, and deploy it without asking how. If they can’t, something in the onboarding failed. Treat it as a systems problem, not a people problem. Did they get enough context on the codebase? Was the first month’s work well-scoped? Did the buddy actually check in?

Measure this with two signals: time to first solo PR (without buddy assistance on the workflow) and the new hire’s own confidence level. Ask them directly. “Do you feel productive? What’s still blocking you?” The answers will tell you more than any dashboard.

Onboarding compounds. Every new hire who has a good first week becomes someone who can onboard the next person. Every broken onboarding creates someone who spends their first month confused and frustrated, and that frustration echoes through their entire tenure.

SRE is fundamentally about incentives and ownership. Not tooling. Not Prometheus dashboards. The org structure you choose determines whether reliability work gets prioritized or gets dumped on a small group of people who burn out.

The Three Models That Actually Exist

Centralized SRE is one team supporting many services. It works early on when you’re establishing standards and building your first incident response muscle. I recommend it for companies under 200 engineers with shared infrastructure.

The failure mode is predictable. The SRE team becomes a ticket queue. Product teams throw things over the wall. SREs lose context on individual services. On-call burden grows faster than headcount. I’ve seen centralized SRE teams where every member was on call every other week. That isn’t sustainable. That’s a resignation factory.

Embedded SRE puts reliability engineers inside product teams. Strong domain knowledge. Clear ownership. I like this model for complex services where the operational profile is unique: payment processing, real-time data pipelines, anything where the SRE needs to understand the business logic to debug production.

The failure mode here is fragmentation. Every team invents their own monitoring stack. Incident learnings don’t spread. SREs get treated as “the person who does the ops stuff” instead of a partner. And career growth gets weird because the SRE reports to a product manager who doesn’t understand their work.

Platform/Enablement SRE is the model I push most organizations toward, eventually. A central team builds reliability tooling, templates, and automation. Product teams own their own operations. The SRE team makes reliability easy instead of doing reliability for everyone.

This only works if the platform is good. If your self-service tooling is bad, product teams can’t actually own their operations and everything escalates back to the same five experts. I’ve watched this fail spectacularly at companies that tried to jump straight here without building the self-service layer first.

What I Actually Recommend

Most organizations over 300 engineers should run a hybrid. Central platform work for the shared layer. Embedded support for the three to five most critical services. Everything else gets the self-service platform and advisory engagement.

The key is having explicit engagement levels. Not every service deserves dedicated SRE attention. I use three tiers:

• Advisory: Architecture reviews and SLO guidance. Minimal operational involvement. This is for most services.
• Partner: Joint SLOs, shared incident response, regular reliability reviews. This is for important services with active reliability investment.
• Full support: Dedicated SRE ownership of production and on-call. This is for your revenue-critical, customer-facing, “if this breaks the CEO calls someone” services.

Scale engagement up as criticality increases. Scale it back as the product team matures. The goal is always to make the SRE team less needed, not more.

The Entry Criteria Nobody Wants to Set

Here is where I get unpopular. I tell organizations to require teams to meet a baseline before they get dedicated SRE support. Defined SLOs . Monitoring that reflects user impact. Up-to-date runbooks. Automated deployments with rollback. Participation in postmortems.

If a product team can’t be bothered to define an SLO, they aren’t ready for an SRE partner. They want someone to carry their pager. That’s a different thing.

Sizing

The “1 SRE per 10 developers” ratio gets thrown around a lot. It’s a fine starting point but it means nothing without context. A team of 10 developers running a single stateless API needs less SRE support than a team of 10 running a distributed database cluster.

What matters more: can you sustain your on-call rotations? You need at least 5-6 people per rotation to avoid burnout. If you can’t staff that, you either have too many services or too few SREs. Probably both.

The Anti-Patterns I See Everywhere

Renaming ops to SRE. Same people, same work, new title. Nobody adopted error budgets . Nobody does blameless postmortems. Nobody is writing automation to replace toil. Just a title change and a conference talk about “our SRE journey.”

SRE as deployment gatekeeper. If every deploy needs SRE approval, you’ve built a bottleneck and called it reliability. Deployments should be automated and safe by default. SRE shouldn’t be in the approval chain for routine changes.

SRE as permanent firefighter. If your SRE team spends 80% of their time on incident response and 20% on prevention, the math never gets better. Google’s original guidance was a 50% cap on operational work. I’ve never seen an enterprise hit exactly 50%, but the principle is right. If there’s no time for prevention, you’re just managing decline.

The best SRE team I’ve worked with was at a mid-sized fintech. Six people. They supported the whole company not by owning every service, but by building such good tooling and templates that product teams could own their own reliability. The SRE team’s backlog was mostly platform improvements. Incidents were handled by the teams that owned the services. SREs showed up for the big ones and ran the postmortems.

That’s what good looks like. SRE as a leverage point, not a fire department.

Not the concept. The concept is real and useful. I’m tired of how it’s used. Every codebase I inherit, someone pulls me aside and says “we have a lot of technical debt.” What they mean is: there’s code they don’t like. There are decisions they didn’t make. There’s a system that was designed for a different stage of the company.

That’s not debt. That’s software aging. And calling everything “debt” makes it impossible to prioritize the things that actually need fixing.

What technical debt actually is

Ward Cunningham’s original 1992 metaphor was specific: shipping first-time code is like going into debt. A little debt speeds development, as long as it’s paid back promptly with a rewrite. The danger is debt that never gets repaid, where every minute spent on not-quite-right code counts as interest.

That’s useful framing. It implies intent and a plan to repay.

What most people call “tech debt” is something else entirely:

• Code written by someone who left, in a style nobody likes anymore
• An architecture that was right for 10 users but not for 10,000
• A framework choice that fell out of fashion
• A service that works but is hard to understand
• An API that’s ugly but functional

None of that’s debt in the Cunningham sense. It’s just… code that aged. Software entropy. The natural consequence of building something over years with changing teams, changing requirements, and changing fashions.

The distinction matters because debt implies you should pay it back. And a lot of the stuff people label as “tech debt” doesn’t need fixing. It needs acceptance.

When it actually matters

Real debt, the kind worth tracking and paying down, has measurable costs:

It causes incidents. If the same component is behind repeated production issues, that’s not aesthetic displeasure. That’s a reliability risk with a price tag.

It blocks delivery. If adding a feature to a specific area takes 3x longer than it should because of tangled dependencies or missing tests, you’re paying interest on every sprint.

It creates security risk. Outdated dependencies with known vulnerabilities. Auth systems with gaps. Unencrypted data stores. This is debt with existential consequences.

It prevents hiring from working. If new engineers can’t contribute meaningfully for months because the codebase is impenetrable, that’s a real cost.

If none of those apply, you probably don’t have a debt problem. You have a preference problem. And that’s fine. But don’t burn engineering capacity rewriting a working system because someone doesn’t like the coding style.

The “rewrite it” trap

The most expensive form of fake debt management is the rewrite. I’ve seen it at three different companies. The pitch is always the same: “The current system is unmaintainable. We need to rewrite it from scratch. It’ll take 6 months.”

It never takes 6 months. It takes 18. The new system ships with half the features of the old one. The old system keeps running in parallel because the migration is never complete. Now you have two systems to maintain.

At my infrastructure startup, I almost fell into this with my own billing system. It was ugly. It was a monolith. I hated working on it. But it worked. It processed payments correctly. It handled every edge case I had hit so far.

Instead of rewriting, I strangled it . Extracted one capability at a time into new services. Kept the old system running for the parts I hadn’t migrated yet. It took longer than a rewrite would have, but there was never a period where billing was half-working.

How to actually manage it

If you have real debt (the kind that causes incidents, blocks delivery, or creates security risk), track it explicitly.

I keep a simple registry . Each entry has: what the debt is, who owns it, what the impact is, and what the decision is (fix now, fix later, accept permanently).

The key is that last field. Some debt you accept. Permanently. The system works. The cost of fixing it exceeds the cost of living with it. That’s a valid decision. Write it down and move on.

For debt you do want to fix, allocate a steady percentage of capacity. I recommend 15-20%. Not in a dedicated “debt sprint” once a quarter; that never works because it gets deprioritized. Bake it into every sprint. Every team, every sprint, some debt work alongside feature work.

Make the business case

The worst thing you can do is use “tech debt” as a catch-all complaint. When everything is debt, nothing is. When you bring a list of 50 items labeled “tech debt” to a planning meeting, leadership tunes out. Reasonably.

Instead: “This component caused 3 incidents last quarter and adding the subscription feature will take 4 extra weeks because of its coupling to the payment module. Fixing the coupling first saves net time and reduces incident risk.”

That’s a business case. That gets funded.

“The auth service is old and ugly” isn’t a business case. If it works, it works. Spend your credibility on the things that actually hurt.

Why I care about this topic

I’ve been working remotely in some form for most of my career. That was no accident: I kept building teams that were distributed by default. When you’re hiring engineers across multiple countries, “remote-first” stops being a philosophy and starts being a logistics problem you solve every week.

So when the pandemic hit and every company suddenly discovered remote work, I watched the discourse with a mix of amusement and frustration. Amusement because most of the “tips” being shared were things distributed teams had figured out years ago. Frustration because the loudest voices were often people who had been remote for six months and were already writing definitive guides about it.

This is what I’ve learned from doing it for years, including the parts that nobody puts in their LinkedIn posts.

The benefits

Deep work actually happens. This is the biggest one and it isn’t even close. In an office, your calendar gets colonized by meetings, drive-by questions, and the guy who wants to tell you about his weekend every Monday at 9:15. At home, I can put on headphones, close Slack, and write code or review architecture for three hours straight. That kind of focus is rare in an open office. It’s the default when you work remotely.

You hire from everywhere. When I stopped requiring people to live near an office, the talent pool didn’t just grow. It changed completely. Some of the best engineers I’ve worked with lived in cities I had never heard of. When you’re a smaller company that can’t compete with FAANG salaries, being remote-friendly is one of the most powerful recruiting advantages you can have.

No commute is life-changing. I know this sounds obvious but people underestimate it. Getting back one to two hours per day isn’t a minor convenience. It’s the difference between exercising or not, cooking a real meal or ordering delivery, spending time with family or showing up already exhausted. Over a year, that’s hundreds of hours. I’ve never met anyone who went back to commuting and said they were happier.

Autonomy breeds better engineers. Remote work forces people to be more self-directed. You can’t tap someone on the shoulder to ask a question, so you learn to read the docs, check the logs, and form a hypothesis before escalating. Teams I’ve managed remotely tend to develop stronger individual problem-solving habits over time. Not everyone thrives in that environment, but the ones who do become significantly better engineers.

The dangers

Loneliness isn’t a joke. I’m not going to sugarcoat this. Working from home alone, day after day, can be isolating. The casual human interactions that happen in an office (grabbing coffee, complaining about the build system, eating lunch together) disappear. You don’t notice it at first because you’re enjoying the quiet. Then six months in you realize you haven’t had a real conversation with a colleague that wasn’t about a Jira ticket. This hits people harder than they expect.

Work never ends unless you end it. When your office is your living room, there’s no physical act of “leaving work.” The laptop is right there. The PR review can happen after dinner. The Slack message at 10pm gets a reply because you saw the notification. I’ve caught myself multiple times checking deployment dashboards at midnight not because anything was on fire, but because the boundary between “on” and “off” had completely dissolved. This is the fastest path to burnout I’ve seen in remote teams.

Trust erodes silently. In an office, you see people working. You see them stuck on a problem, you see them helping a colleague, you see them at their desk deep in thought. Remotely, you see none of that. What you see is Slack status, commit history, and meeting attendance. Managers who don’t trust their teams start tracking mouse movements and requiring cameras on. Engineers who feel watched start performing visibility instead of doing actual work. This dynamic is toxic and it happens gradually.

Junior engineers suffer the most. This one took me a while to fully appreciate. Senior engineers have the context, the network, and the confidence to thrive remotely. Junior engineers need to absorb how a team thinks, how decisions get made, how to ask for help without feeling stupid. In an office, a lot of that happens through osmosis. Remotely, you have to build explicit systems to replace what used to happen naturally, and most teams don’t bother.

What works

Have a shutdown ritual. “Set boundaries” is useless advice. I mean a specific, repeatable action that signals “work is done.” For me, it’s closing the laptop lid, putting it in a drawer, and going for a walk. It sounds silly, but your brain needs a physical transition when there’s no commute to provide one. Find yours and do it every day.

Write everything down. This is non-negotiable for remote teams. Decisions made in a call that aren’t documented didn’t happen. Use written proposals for anything important. Record the outcome of every meeting. Make your team’s memory searchable. I’ve written about async communication before and I stand by it: writing-first culture is the single most important habit for distributed teams.

Create space for non-work interaction. Not forced fun, not mandatory virtual happy hours. Just space. A Slack channel for random conversation. Occasional calls with no agenda. Optional video coffee chats. The key word is optional. The moment you mandate socializing, it stops being social and starts being another meeting.

Over-invest in onboarding. When a new engineer joins a remote team, their first two weeks determine whether they will thrive or quietly disengage. Onboarding is the stress test for the whole system. Pair them with someone. Give them a small, completable task on day one. Have their manager check in daily, not weekly. Write an onboarding guide that actually reflects how the team works, not the aspirational version.

Default to async, escalate to sync. Start with a written message or document. If the thread is going in circles, jump on a call. After the call, write down what was decided. This flow protects focus time while still allowing real-time collaboration when it’s actually needed.

Intentionality is the difference

What separates teams that make remote work stick from teams that suffer through it is intentionality: about communication, about culture, about the human side of staring at a screen alone for eight hours a day. Hybrid setups make that harder, not easier.

I’m still a strong believer in remote-first teams. But I’m a much more clear-eyed one than I was five years ago.

After the call, one of the remote engineers messaged me privately: “I have no idea what we decided.”

That’s hybrid work in one sentence.

The worst of both worlds

I’ve been fully remote for years. I’ve led distributed teams . I worked with remote engineers at the fintech startup. Remote works because everyone operates under the same constraints. Nobody has hallway access. Nobody has a whiteboard advantage. All context lives in written artifacts because it has to.

Hybrid breaks that symmetry. Some people are in the room. Some aren’t. And the people in the room have massive advantages they don’t even notice.

Decisions happen in hallway conversations after the meeting ends. Context gets shared over lunch. Feedback happens in passing (“hey, nice work on that PR”), which sounds trivial until you realize the remote people never hear it.

The office people aren’t doing this maliciously. It’s just how humans work when they share physical space. Information flows through proximity. Hybrid means some people get that flow and some don’t.

Remote-first is the only fix

If you’re going hybrid, you have to operate as remote-first. Not “remote-friendly.” Not “we have good video conferencing.” Remote-first.

That means: if one person in a meeting is remote, everyone joins from their own device. Even the five people sitting in the same conference room. Yes, it feels awkward. Yes, it works. Because now everyone has the same audio quality, the same view, and the same ability to participate.

That means: decisions are documented in writing. Not “we’ll share notes later.” The notes are the decision. If it’s not written down, it didn’t happen. This was already true for remote teams. Hybrid teams need to adopt it explicitly because the temptation to rely on in-person context is strong.

That means: async communication is the default for status updates, progress sharing, and non-urgent questions. Sync time is reserved for things that genuinely benefit from real-time interaction: architecture discussions, debugging sessions, retrospectives.

What the office is actually good for

I’m not anti-office. The office is great for specific things. Onboarding new engineers who need face time to build relationships. Design workshops where you need a whiteboard and rapid iteration. Team retrospectives where emotional nuance matters. Pairing sessions on hard problems.

The office is terrible for status meetings. It’s terrible for solo focus work. It’s terrible for anything that could be a written update but instead becomes a 30-minute calendar block because someone wanted “face time.”

If your team’s office days are filled with meetings that could have been documents, you’re using the office wrong.

The meeting problem

Meetings are where hybrid equity dies. I have a strict rule for the teams I advise:

Every meeting needs a written agenda shared before the meeting starts. If there’s no agenda, there’s no meeting. Every meeting gets notes published within an hour of ending. Action items have names and dates. Follow-up conversations that happen in the hallway get summarized in the notes channel.

This is annoying. It’s also the minimum viable process for making hybrid fair. Without it, the remote engineers are always operating on incomplete information and always a step behind.

Performance management by green dot

What makes me angry about how some organizations do hybrid is that they evaluate performance by presence. Who is in the office. Who responds fastest on Slack. Who is “always available.”

That’s not measuring performance. That’s measuring proximity. And it systematically disadvantages remote engineers, parents with caregiving responsibilities, anyone in a different time zone, and anyone who does their best work in focused blocks without interruption.

Measure outcomes. Code shipped. Problems solved. Systems improved. Incidents handled. If the work is good, I don’t care where the person was sitting when they did it.

Why this is harder than full remote

Full remote forces discipline. You have to write things down because there’s no alternative. You have to make meetings inclusive because everyone is remote. You have to trust people to manage their time because you can’t see them.

Hybrid lets you be lazy. The in-office group gets context through osmosis and assumes everyone else has it too. Meetings are “inclusive” because there’s a camera in the conference room. The written documentation is “good enough” because the office people fill in the gaps verbally.

That laziness creates a two-tier system. And it compounds over months. The remote engineers gradually lose context. They get passed over for projects that start with in-person conversations. They burn out from constantly feeling behind.

I’ve seen this happen at three different organizations this year alone.

If you’re going hybrid, commit to remote-first practices. Or go full remote and skip the hardest coordination problem in engineering management. For most teams, that’s the better call.

We’re in 2020. Half the industry just went remote overnight and managers are panicking. I get it. You can’t see people at their desks anymore. So now there’s this desperate scramble to measure something to prove people are working. And the tools are happy to sell you that something.

Lines of code is the worst offender but it’s far from the only one. Commits per day. Tickets closed. Story points completed. Velocity. All garbage when used to evaluate individual developer performance. Every single one.

Why these metrics are garbage

I once mass-deleted 12,000 lines of dead code from a Rails monolith in a single afternoon. Most productive day I’d had in months. By a lines-of-code metric, I went negative. Fire me, I guess.

Commits per day? I know devs who commit every time they save. I know devs who work on a complex problem for three days and push one beautiful, well-tested commit. The second developer is almost always doing better work.

Story points are the sneakiest one. They were invented as a planning tool. A way for teams to forecast how much they could take on. Somewhere along the way, managers started treating velocity as a performance metric. “Your velocity dropped this sprint, what happened?” What happened is Goodhart’s Law. The moment you use velocity to judge people, teams inflate their estimates. Suddenly a two-pointer becomes a five-pointer. Velocity goes up. Actual output stays the same. Everyone pretends not to notice.

I’ve watched this play out at three different companies now. Same story every time.

The only metrics I actually care about

DORA metrics. That’s it. Four numbers, from the research behind Accelerate and the State of DevOps reports. Boring, validated, and hard to game.

Deployment frequency. How often are you shipping to production? Not “how often are you merging PRs.” Actually shipping. If your team deploys once a month, you have a delivery problem. Fix it before you measure anything else.

Lead time for changes. From commit to production. This tells you how much friction is in your pipeline. Long lead times mean slow code review, flaky CI, painful deployments, or all three. Every one of those is worth fixing.

Change failure rate. What percentage of deployments cause a failure? This is the quality counterweight. You can’t just deploy fast and break everything. Well, you can. But this number will catch you.

Time to restore service. When something breaks, how fast do you fix it? This is the one that actually matters at 3am. And it tells you more about your team’s operational maturity than any sprint dashboard ever will.

These four together give you a real picture. Speed and stability. You can’t game them easily because they pull in opposite directions. Ship faster but break things? Your failure rate goes up. Over-index on stability? Your deployment frequency drops.

What I actually do

On my teams, I track DORA metrics at the team level. Not individual. Never individual. I don’t care which developer deployed what. I care whether the system is getting better or worse.

We look at the numbers monthly. Trend lines, not snapshots. If lead time is creeping up, we dig into why. Usually it’s a CI problem or a review bottleneck. Fix the system, not the people.

I also ask one question in retros: “What slowed you down this week?” The answers are always more useful than any dashboard. Flaky tests. Unclear requirements. Waiting two days for a review. That’s where the real productivity wins are hiding.

Stop measuring people, fix the system

The entire premise of individual developer productivity metrics is broken. Software is collaborative. The best developer on your team might spend half their time unblocking others, reviewing code , and mentoring juniors. By any activity metric, they look “less productive” than the person grinding out solo features. But remove them and watch the whole team slow down.

If your response to remote work is to install monitoring software or build LOC dashboards, what you have is a trust problem, and no metric is going to fix that.

Measure the system. Use DORA. Fix the bottlenecks. Talk to your team. Everything else is theater.

I’ve worked remote-first for a while now, and my infrastructure startup has been remote since day one. When the pandemic hit, I watched every company around me scramble to “go remote” and immediately do it wrong. Their playbook was simple: take every in-person meeting, slap it on a video call, and declare victory. Then wonder why everyone is exhausted by 3pm.

That’s not remote work. That’s the office with worse lighting.

The point is async

The bigger advantage of remote work is time flexibility, more than location. Your engineers can do deep work when their brain is on fire instead of when the calendar says so. But that only works if your default communication mode is async.

Async means I write something clear enough that you can read it, understand it, and act on it without needing me online at the same time. I’ve argued for this before . Not complicated in theory. Apparently very complicated in practice.

Why most teams get this wrong

Because writing is harder than talking. In a meeting, you can ramble for ten minutes and people nod along. In async, you actually have to think before you communicate. You have to structure your thoughts. You have to anticipate questions.

Most people have never been asked to do this at work. So they default to what’s easy: “Hey, got a minute for a quick call?”

No. I don’t. And neither does any engineer in the middle of debugging a production issue.

The async rules I work by

A few rules keep async working:

Write complete thoughts. Don’t send “hey” and wait. Don’t drip-feed context across fifteen messages. One message. Full context. Clear ask. Done.

Decisions go in writing. If it happened in a call and nobody wrote it down, it didn’t happen. We write short decision docs: what we decided, why, what we considered and rejected. Takes five minutes. Saves weeks of “wait, I thought we agreed to…”

Response times are explicit. Chat gets same-day responses. PR reviews within 24 hours. Decision docs get a couple of days. On-call stuff is immediate. No ambiguity.

Meetings are the exception. We use sync time for things that are hard to resolve in text: conflict, brainstorming, incident response. Not for status updates. Never for status updates. Write those down and give people their mornings back.

The hard part

Async requires trust. You have to trust that someone not responding immediately is working, not slacking. You have to judge people by what they ship, not by their green dot in Slack.

Most managers aren’t ready for that. They’ve spent their careers managing by presence. Seeing butts in seats. Remote forces a reckoning with that, and a lot of them are responding by demanding cameras-on all day. Which is somehow worse than the office.

If you’re a leader and your reaction to remote work was “more meetings,” you missed the point entirely. The unlock is fewer interruptions, better writing, and trusting your team to be adults.

Stop recreating the office on Zoom. Start writing things down.

I ended up as tech lead at that company, and the first thing I fixed was onboarding.

Not because it was the sexiest problem. Because it was the most expensive one nobody was measuring. Stop treating onboarding as “show them the wiki and hope for the best.” Script the dev setup to three commands, pair new hires with a buddy who has fresh context, give them real work that touches production in week one, then ask them what was broken and fix it.

The Real Cost Nobody Tracks

Building my infrastructure startup in my founder-program cohort this year has reminded me how little time a startup has to waste. At a startup, a slow ramp-up isn’t an inconvenience. It’s an existential threat. But even at larger places, the math is brutal: a senior engineer who takes eight weeks to ship independently instead of three just cost you five weeks of salary for zero output. Multiply that by every hire per year.

The usual excuse is “our codebase is complex.” No. Your onboarding is lazy. Complexity is a reason to invest more in onboarding, not less.

What Good Onboarding Looks Like

I’ve onboarded engineers at the fintech startup and at a mobility startup. Different products, different stacks, different countries. The pattern that works is boringly consistent.

Day one: the new engineer opens a PR. Not a meaningful one. Not a feature. A typo fix, a config tweak, a test improvement. The point is they’ve touched the full cycle (clone, build, branch, change, test, review, merge, deploy) before they go home. If your setup takes longer than a morning, it’s broken.

Week one: they own a real bug fix. Something with a clear repro, a limited blast radius, and enough context that they learn the codebase by reading the code that matters, not by reading a stale architecture doc.

Month one: they’re independently picking up work. They know who to ask, where the bodies are buried, and how deploys actually work (not how the wiki says they work).

That’s it. No elaborate 90-day plans. No onboarding “program” with a PowerPoint deck. Just a tight loop of ship, learn, ship.

make setup Or Go Home

At the mobility startup, we ran Go services talking to a handful of microservices. When I joined (before eventually leading the engineering), the local dev setup involved seventeen manual steps spread across a README that contradicted itself in three places. I rewrote it as a Makefile, the kind of ad-hoc tooling that beats a platform at that size.

git clone git@github.com:company/app.git
make setup
make dev

Three commands. If it takes more than three commands to go from zero to a running local environment, you have a setup problem, not a complexity problem. Script it, containerize the dependencies, seed the database automatically. The new hire’s laptop is a test of your infrastructure’s maturity. If you can’t reproduce your dev environment reliably, production probably isn’t any better.

When I set up the dev environment at my infrastructure startup, I literally timed it. Fifteen minutes from git clone to running tests. If it crept past that, I treated it as a bug.

The Buddy System (Done Right)

Every new engineer gets a buddy. Not their manager. Not the tech lead. Someone close enough to the codebase to answer “where does this thing live?” questions but not so senior that the new hire feels stupid asking.

The buddy’s job is simple: be interruptible for the first two weeks. That’s the whole job description. They don’t need to teach. They need to unblock.

At the fintech startup, I paired each new hire with whoever had last touched the area of code they’d be working in. Not because that person was the best teacher, but because they had the freshest context. Onboarding is a transfer of context, not knowledge. The knowledge is in the code. The context (why this weird pattern exists, which service is actually deprecated but still running, where the real config lives) is in people’s heads.

Starter Tasks That Aren’t Insulting

The worst onboarding pattern is the “starter project” that’s actually a garbage task nobody else wanted to do. New engineers can smell it. It tells them their time isn’t valued.

Good starter work has three properties:

1. It touches production. The whole point is building confidence that they can ship safely.
2. It has a clear definition of done. Not “explore the payment service and propose improvements.” That’s a research project disguised as onboarding.
3. It teaches something specific about your system. A bug in the notification service teaches them about the event pipeline. An error message improvement teaches them about the API contract.

Keep a backlog of tagged issues specifically for this. Not fake work. Real bugs and improvements that were scoped to one or two days and came with enough context that someone new could pick them up without a forty-minute walkthrough.

Documentation: Less Is More

I’ve seen onboarding wikis with fifty pages of architecture history, org charts, and “philosophy” documents. Nobody reads them. The new hire skims the first two, gets overwhelmed, and asks their buddy anyway.

What new engineers need written down:

• How to set up their machine (the Makefile)
• How to deploy and how to roll back
• How to ask for help and who reviews what
• A one-page system overview with a data flow diagram

That’s four documents. Keep them short. Update them every time someone joins and finds something wrong. The onboarding docs should be the most maintained docs in your entire company, because they’re the only ones that get tested regularly by people who have no prior context.

The Feedback Loop Most Teams Skip

What separates decent onboarding from great onboarding: you ask the new hire what was broken.

Every new engineer who joins should file at least one issue against the onboarding process itself. Not as a suggestion. As a requirement. “What was confusing? What was wrong? What did you have to ask someone that should have been written down?”

At the fintech startup, we turned this into a standing item in the 30-day check-in. Every single round of onboarding made the next one better. By the time I left, the setup was tight enough that contractors could be productive on day two.

Every engineering team I’ve worked with has some version of the same conversation. Someone mentions a gnarly part of the codebase. Everyone nods. Someone says “we should really clean that up.” Nobody does.

At the fintech startup, we hit a point where this was hurting us. Our data pipeline had accumulated enough shortcuts and half-finished migrations that feature work was getting slower every quarter. Not dramatically. Just enough friction that estimates kept creeping up and nobody could point to exactly why.

So I built a system for it. Nothing fancy. But it changed how we think about debt.

What tech debt is

Tech debt is a future cost you created with a present decision. Sometimes that decision was smart: you shipped faster and the tradeoff was worth it. Sometimes it was accidental: the design was fine until requirements shifted. Either way, the cost is real.

The forms we see most often:

• Deliberate shortcuts. You knew it was a hack. You shipped anyway. Fair enough.
• Accidental debt. Looked fine at the time. Scale or new requirements proved otherwise.
• Environmental shifts. A dependency gets deprecated. A compliance rule changes. Not your fault, still your problem.
• Operational gaps. Missing monitoring, thin tests, no runbook. The kind of thing that bites you at 2am.

Our debt registry

We created a debt registry: a shared list of known liabilities that lives right in our issue tracker. Not a separate doc. Not a wiki page nobody reads. Same board, same sprint planning, same visibility as feature work.

Each entry looks roughly like this:

id: TD-021
title: Legacy auth flow lacks rate limiting
area: auth-service
impact: Security, reliability
risk: High
effort: 3-4 weeks
owner: Platform
status: Proposed

The key insight was treating debt entries as first-class work items. When debt lives in a separate spreadsheet, it gets ignored. When it sits next to feature tickets in the same planning session, it gets discussed.

We review the registry every two weeks during sprint planning. Takes ten minutes. That alone changed how we worked.

Scoring: keep it dead simple

We tried complex scoring matrices. They didn’t survive contact with reality. What stuck was three dimensions and a formula you can do in your head:

• Impact. How much does this slow us down or degrade the product?
• Risk. What happens if it gets worse or fails outright?
• Effort. How much work to fix it?

priority = (impact * 2) + risk - effort

Each on a 1-5 scale. Is it perfect? No. But it forces you to compare things that otherwise feel impossible to rank. “The auth system is scary” versus “the build is slow” suddenly becomes a conversation with numbers instead of gut feelings.

When to act now versus later

Some things can’t wait:

• Security exposure. Full stop.
• The same root cause behind repeated incidents.
• A dependency about to hit end-of-life.
• Workarounds that tax every single release.

Everything else goes into the prioritized backlog. High impact, low effort items get picked up opportunistically. Large refactors get scheduled as dedicated work with clear milestones.

How we schedule paydown

We tried three approaches before settling on a hybrid:

Capacity allocation. We reserve roughly 20% of each sprint for maintenance and debt work. Non-negotiable. Product knows about it. This is the baseline.

Debt sprints. Every six weeks, we run a focused sprint on the highest-priority debt items. Engineers pick from the top of the registry. These sprints have been some of the most satisfying work the team does.

Opportunistic paydown. If you’re already in the code, improve it. Boy scout rule. We just ask people to tag the cleanup commits so we can track the effort.

Incremental migration over big rewrites

We learned this the hard way. Big-bang rewrites fail. They just do. Every large debt item at the fintech startup now follows the same pattern:

• Run old and new paths in parallel.
• Migrate the highest-traffic paths first.
• Set a cutover date. Remove old code on that date. No exceptions.

Feature flags make this safe:

if flags.new_auth_flow:
    return new_auth.authenticate(user)
return legacy_auth.authenticate(user)

The flag gives you a kill switch. Sleep better at night.

Selling debt work to non-engineers

This is where most teams fail. You can’t walk into a planning meeting and say “the auth code is messy.” Nobody cares.

What works: translate debt into business language. “Feature X takes twice as long to ship because every change requires manual regression testing in the auth module.” Now it’s a delivery speed conversation. Product managers understand delivery speed.

At the fintech startup, we started including debt impact in our sprint velocity reports. When the team could show that velocity dropped 15% quarter-over-quarter and tie it to specific debt items, getting time allocated stopped being a fight.

Prevention

A few guardrails go further than any cleanup sprint:

• Lightweight design reviews for anything touching critical paths.
• Code review checklists that ask about maintainability, not just correctness.
• Quarterly dependency upgrades so you never face a multi-year jump.
• Documentation expectations for anything another team will touch.

Why the registry worked

The registry wasn’t sophisticated. It was a handful of fields in Jira. It worked because it made invisible costs visible, and once everyone can see the cost, the conversation about paying it down gets a lot easier. You took a loan; now you have a repayment plan.

Then we started growing.

By the time we hit fifteen engineers, things that used to happen naturally (knowledge sharing, aligning on priorities, knowing who owned what) stopped happening on their own. Nobody did anything wrong. The team just outgrew its own communication patterns. I remember one week where two engineers independently built overlapping caching layers because neither knew the other was working on it. That was the moment I realized: scaling a team is a fundamentally different problem than building a product.

The stages nobody warns you about

There’s no smooth curve from small team to big team. It’s a series of phase transitions, and each one breaks something that was working fine before.

Around 10 engineers, everything runs on shared context. You all know the codebase, you all know each other, decisions are fast. Feels great. Savor it.

At 25 to 30, you wake up one morning and realize you have actual teams now. Dependencies show up. Duplication shows up. That thing where you just shout across the room to coordinate? Gone. You need to be intentional about who talks to whom about what.

At 40 to 60, you need real structure. Managers. Defined roles. Onboarding that goes beyond “ask anyone.” I saw this at a startup accelerator this year: founders hitting this wall where the informal culture that made them fast was now making them slow. Every single one of them resisted adding structure. Every single one eventually had to.

At 80 to 100, you’re doing organizational design whether you like it or not. Cross-team alignment becomes someone’s actual job. Architecture decisions need governance. Career paths matter because people will leave if they can’t see a future.

Ownership has to be explicit

This was the hardest lesson for me. At a small startup, ownership is fluid. Whoever cares most picks it up. That works well until it stops working.

At the fintech startup we moved to small, mission-focused teams. Each team owned a clear slice of the product: the domain, the code, the on-call rotation, the technical direction. We wrote it down. A simple team charter: here’s what we own, here are our interfaces, here’s who’s on-call. Nothing fancy.

The effect was immediate. Fewer “who should I ask about this?” questions. Faster decisions. Less duplicated work. Turns out people move quickly when they know their boundaries.

Four team shapes held up well for us:

• Product teams delivering customer value end to end
• Platform teams providing shared infrastructure
• Temporary expert teams that unblock others and then move on
• Specialist teams for the genuinely hard subsystems

Communication doesn’t scale by accident

At 10 people, context spreads by osmosis. You overhear things. You absorb the state of the project just by sitting in the same room.

At 50, that’s completely gone. If you don’t write it down, it didn’t happen.

We learned it at fifteen, the hard way. The practices that helped, most of them async and written :

• Short written updates after decisions. Not meeting notes. Actual “here’s what we decided and why.”
• Weekly demos. Not polished presentations. Just “here’s what shipped, here’s what’s stuck.”
• Lightweight architecture decision records for anything that changes a shared interface.
• Clear escalation paths. When something is on fire, people need to know who to call without digging through a wiki.

The goal is fewer surprises, not more meetings.

Process should follow pain

I’ve seen teams add process preemptively: policies for problems they haven’t hit yet. It rarely works. Process should show up when the pain of not having it outweighs the overhead of maintaining it.

At the fintech startup, our process grew roughly like this:

• Early days: Code review. A deployment checklist. Basic on-call.
• Growing pains: Incident response runbooks. A planning cadence. Team charters.
• Later: Engineering levels. Hiring rubrics. Decision records for cross-cutting changes.

One thing that helped a lot: tiered decision authority. Small decisions stay inside the team. Medium decisions involve peer teams. Big decisions get a written proposal and a review window. This kept us from bottlenecking everything through a single approval chain.

Hiring is the long game

Scaling headcount without scaling hiring quality will hurt you for years. We put rubrics in place before we ramped hiring. Trained interviewers. Calibrated scoring across panels. It slowed us down initially but the consistency paid off.

Onboarding was the other half. A 30/60/90 day plan with real milestones. A buddy for every new hire. A living checklist that we actually updated when things changed. The faster someone ships their first meaningful change, the faster they feel like they belong.

Invest in the platform early

Every team rebuilding the same deployment pipeline or logging setup is a team not shipping product features. We stood up a small platform team earlier than most people would recommend, and I’d do it again.

Standardize the expensive stuff: languages, infrastructure patterns, observability tooling, security practices. Leave room for teams to make their own choices where it doesn’t create systemic risk. That balance is never perfect. You just keep adjusting.

Technical debt compounds with team size. The more people writing code, the faster it accumulates. Give it an owner. Give it time. If nobody is responsible for paying it down, nobody will.

Culture doesn’t transmit itself

This one hit me at the accelerator. Talking to founders from all over Asia, the pattern was the same. They had a strong culture at 10 people. At 40, new hires didn’t absorb it. The founders were frustrated because they thought culture was something you just had, not something you built and maintained.

Culture scales when values are written down, repeated constantly, and, most importantly, modeled by leaders. Recognize behaviors, not just outcomes. Document expectations in an engineering handbook instead of relying on tribal knowledge. Celebrate progress. Do blameless postmortems and actually mean it.

Organizational design is the hard part

The technical work is the easy part of scaling a team. The hard part is making ownership, decisions, and communication explicit enough that dozens of people can move fast without stepping on each other. Get that right and growth is a multiplier. Get it wrong and every new hire makes you slower.

He’s one of our best hires.

That experience broke something in how I thought about interviewing. At the fintech startup we were growing the engineering team fast, and I kept seeing the same pattern: candidates who crushed whiteboard problems but couldn’t debug a real issue, and candidates who struggled with algorithmic puzzles but wrote clean, thoughtful code every day.

Something was deeply wrong with how our industry interviews people.

The stuff that doesn’t work

Whiteboard algorithms. I get why they’re popular. They feel rigorous. But think about what you’re actually testing. You’re testing whether someone recently crammed LeetCode. You’ve stripped away their IDE, their docs, their ability to Google something. You’ve removed every tool they’d use on the job and then judged them on the result. That’s not an interview. That’s hazing.

Brain teasers. “How many golf balls fit in a school bus?” If you’re still asking these in 2018, please stop. Google’s head of people operations, Laszlo Bock, told the New York Times back in 2013 that brainteasers are “a complete waste of time” and “don’t predict anything.”

Trivia questions. “What’s the time complexity of HashMap.get() in Java?” Cool, they memorized it. Or they didn’t. Either way you’ve learned nothing about whether they can build software.

Massive take-home projects. I’ve seen companies send 8-hour assignments and call it “a small exercise.” You’re not testing skill. You’re filtering for people with no life outside work. Single parents, people with side commitments, anyone who values their free time: they just opt out. And you never even know what you missed.

What predicts performance

I’ve been iterating on our process at the fintech startup for a while now. This is what’s worked.

Give them a laptop and a real problem

This is the single biggest improvement we made. Instead of a whiteboard, we hand candidates a laptop with an IDE, internet access, and a small codebase. The task is something close to what they’d actually do on the job. Add a feature. Fix a bug. Review a pull request.

You learn so much more this way. How do they read unfamiliar code? Do they check edge cases? How do they use their tools? Do they ask good questions when stuck?

One of our best interview tasks is a broken API endpoint with a failing test. The candidate gets logs, the codebase, and 45 minutes. We’re not looking for a perfect fix. We’re watching how they think.

Pair with them

Pair programming sessions are gold. You pick a small problem, sit next to the candidate, and work on it together. As a collaborator, not an examiner.

This tells you things no other format can. How do they handle suggestions? Do they explain their thinking? Can they take feedback without getting defensive? These are the things that actually matter when you’re shipping code with a team.

Talk about what they’ve already built

For senior roles especially, I’ve started spending more time on deep dives into past work. Pick a system they built. Ask them to walk you through the architecture. Then start pulling threads. Why this database? What would you change? What broke in production?

Good engineers light up during these conversations. They remember the tradeoffs. They’ll tell you about the decision they regret. The ones who padded their resume get vague fast.

Use rubrics, not vibes

Early on at the fintech startup, our debriefs were a mess. “I liked her.” “He seemed smart.” “I don’t know, something felt off.” That’s not a hiring decision. That’s a gut check, and guts are biased.

Now every interviewer fills out a rubric before the debrief. Same questions, same scale. You write down specific evidence, not impressions. It’s not glamorous, but it’s the difference between a process and a coin flip.

Designing the loop

Keep it tight. Nobody needs a six-round interview for a backend role.

Here’s roughly what we do:

• Phone screen (30-45 min): Can this person communicate? Do they have the baseline?
• Work sample (60-90 min): Laptop, real problem, real tools.
• Deep dive (45 min): Walk me through something you built.
• Team fit (45 min): Values, collaboration style, how they handle disagreement.

For senior roles, swap the deep dive for a system design conversation. Let them drive. Ask about tradeoffs, not trivia.

Train your interviewers

This one’s overlooked constantly. Most engineers are terrible interviewers. Not because they’re bad people, but because nobody taught them. They default to whatever they experienced as a candidate, which was probably also bad.

At the fintech startup we started having new interviewers shadow experienced ones. We review rubrics together. We debrief on the debrief. It takes time, but the signal quality goes way up.

Candidate experience is your reputation

I can’t count how many times a candidate told me about a horrible interview experience at some other company. Ghosted after three rounds. Left waiting in a lobby for 40 minutes. Given a problem that had nothing to do with the role.

Every candidate who walks out of your office talks about it. To their friends, to their colleagues, sometimes on Glassdoor. At a startup where we’re competing with bigger names for talent , that reputation matters enormously.

Be clear about the process upfront. Respect their time. If you’re not making an offer, tell them why. It costs you nothing and it’s the right thing to do.

Watch out for these traps

Hiring for similarity. If your whole team went to the same three schools and thinks the same way, you don’t have a team. You have an echo chamber. Diverse panels, evidence-based decisions, focus on complementary strengths.

Credential worship. A degree from a top university tells you someone got into a top university. It doesn’t tell you they can debug a production outage at 2am or write code their teammates can actually read.

Letting one bad interview tank a candidate. Single data points are noisy. If four interviews went great and one was mediocre, look at the full picture. Maybe the interviewer had an off day. Maybe the question was bad. Aggregate the signal.

Most companies copy what everyone else does without asking whether it works. The bar isn’t that high, and most of our industry still can’t clear it.

At the fintech startup, we figured this out the hard way. We had engineers spread across time zones, a product moving fast, and a calendar that looked like a game of Tetris nobody was winning. Something had to give.

The real cost of “let’s just sync up”

A meeting at 10am and another at 2pm doesn’t give you a four-hour block in the middle. It gives you two useless slices where you can’t get into anything deep. You sit down, start loading the problem into your head, glance at the clock, realize you’ve got 40 minutes before the next call, and end up on Slack or email instead. The hard problems don’t get touched.

I watched this happen at the fintech startup. Smart engineers shipping shallow work because they never had the uninterrupted time to do the real thing.

The other cost is memory. Verbal decisions vanish. Someone says “we agreed on X” and three people remember it differently. New hires ask why something was built a certain way and the answer is “I think we discussed it in a meeting last March.” That’s oral tradition.

Writing changes everything

We shifted to async by default. Questions, proposals, decisions: write them down first. If the thread stalls or things get heated, jump on a call. But always come back and capture what was decided in writing.

The results were immediate. Engineers got their mornings back. People in different time zones stopped being second-class citizens. And decisions actually stuck because you could point to the thread where the trade-offs were discussed.

I also noticed something I didn’t expect: the quality of decisions went up. When you force someone to write a proposal instead of pitching it verbally in a meeting, they think harder. They check the code. They pull up the docs. Writing is thinking, and thinking is what we’re paying engineers to do.

How we did it

We kept it simple. For any meaningful decision, someone writes up a short doc:

# Decision: [Title]

## Context

## Decision

## Consequences

## Owner and date

Nothing fancy. Took five minutes to fill out. Saved hours of re-litigation later.

We set response time expectations so nobody felt anxious. Urgent stuff: respond within a couple hours. Normal threads: by end of day. Low priority: a couple days is fine. Once people knew the rules, the pressure to be “always on” disappeared.

Status updates went into public channels. Short, async, scannable. We killed the weekly status meeting entirely. Nobody missed it.

Sync still matters (sometimes)

I’m not anti-meeting. I’m anti-default-meeting. There are times when you absolutely should get on a call:

Building trust. Onboarding a new engineer, one-on-ones, team bonding: these need face time. Text doesn’t build relationships the same way.

Gnarly debugging sessions. When you’re staring at a production issue with six moving parts, a live whiteboard session beats a 47-message Slack thread.

Conflict. If two people disagree and the thread is getting tense, get on a call. Tone matters and text is terrible at conveying it.

Incidents. When the site is down, you don’t write a proposal. You get on a call and run the incident .

The key is making sync the exception, not the rule.

The discipline of good async

Bad async is worse than meetings. I’ll admit that. If people write vague messages, bury the ask in paragraph four, or never specify deadlines, async becomes a graveyard of unanswered threads.

So we had rules. State what you need in the first sentence. Give just enough context to answer. Be specific about when you need a response. Batch your reading instead of living in Slack all day. And for the love of god, don’t put long-term decisions in ephemeral chat. Use a doc, a wiki, a PR description, something searchable.

What I learned

Switching to async-first was a cultural statement as much as a process change: we trust our engineers to manage their own time, and we value output over presence. The engineers who thrived were the ones who could write clearly, think independently, and reach out when they were actually stuck.

The calendar got quieter. The code got better. And when we did have meetings, they were short, focused, and worth everyone’s time. That’s the trade-off I’ll take every single time.

The fork nobody prepares you for

Every strong engineer eventually faces this question. Do you go into management, or do you stay technical and lead from there?

I’ve watched this fork up close at the fintech startup. When we were small, the two jobs blurred together: architecture decisions, hiring, 1:1s, code review. It was unsustainable. Once we grew past a handful of engineers, the roles had to split. And more importantly, we had to figure out what each role actually demanded so we could hire and promote into them properly.

Here’s what I learned.

Side-by-side breakdown

That table is the short version. Let me expand on the parts that aren’t obvious.

What an engineering manager does

Most of the job is invisible. You’re clearing the path so your team can build. Hiring the right people , onboarding them fast, giving honest feedback, shielding the team from organizational noise. None of that shows up in a commit log.

A rule I’d give any new manager: if you’re writing production code, something is wrong. Either you haven’t hired well enough, or you’re clinging to the IC identity. Both are problems.

The trap is thinking management is a promotion from engineering. It’s a career change. You stop building things and start building an environment. Completely different skill set. If you hate ambiguity, dislike repetitive conversations, or need the dopamine of shipping code daily, you will be miserable. I’ve seen good engineers become terrible managers because nobody told them this upfront.

What makes a great EM: you actually care about people’s careers. Not performatively. You enjoy the puzzle of team dynamics. You can sit in a room full of competing priorities and walk out with a plan everyone tolerates.

What a tech lead does

The tech lead owns the “how.” You decide the architecture, set coding standards, break ties on technical debates, and make sure the system doesn’t rot while the team ships features.

You still write code. That’s non-negotiable. A tech lead who stops coding loses credibility fast. But you also spend a surprising amount of time communicating. Explaining tradeoffs to product managers. Writing design documents. Mentoring junior engineers through code review. The ratio shifts to maybe 50% coding, 50% everything else, but the code stays.

The frustrating part: you’re accountable for the system but you don’t control the people building it. You can’t assign tasks or run performance reviews. You lead by influence , by being right often enough that people trust your judgment. If your ideas are bad, or if you can’t communicate why they’re good, you have nothing.

At the fintech startup, our tech leads owned specific domains. One person owned the data pipeline architecture. Another owned the API layer. Clear ownership, clear accountability. No committees.

How to choose

Forget the title. Look at how you spend your energy.

After a day of back-to-back 1:1s, are you energized or drained? After eight hours deep in a codebase, do you feel alive or lonely? Your gut answer points you in the right direction.

Better yet, test it. Before you commit to either track, volunteer for the work. Mentor a junior engineer for a quarter. Run a sprint planning cycle. On the tech side, drive an RFC through to implementation. Own a migration. Lead a postmortem.

The title matters less than the work. If you’re doing the work and it fits, the title will follow.

The hybrid trap

We tried the “tech lead manager” thing at the fintech startup when the team was small, with one person carrying both jobs. It sort of worked until it didn’t. You end up being mediocre at two jobs instead of good at one. Skipping 1:1s because you’re deep in a debugging session. Skimping on code review because you have a hiring pipeline to manage.

If your company is small enough that one person must do both, fine. Just know it’s temporary. Plan the split before you need it.

Two tracks of equal weight

Management isn’t a promotion. Tech lead isn’t a consolation prize. I’ve met directors who would’ve been happier as principal engineers and staff engineers who secretly wanted to run a team. The industry does a bad job of framing these as equal. They are.

You can switch tracks. People do it all the time. But switching costs something: you lose momentum, you rebuild credibility, and skills you don’t use will fade. So pick deliberately, try the work before you commit, and don’t let someone else’s career ladder define yours.

I learned this the hard way at the fintech startup. We needed a serious infrastructure overhaul. I knew it. My team knew it. But our investors didn’t speak in uptime and throughput. They spoke in money. So I had to learn their language.

Talk money or don’t talk

Every infra pitch boils down to one of four things: it makes money, saves money, reduces risk, or lets us ship faster. That’s it. Pick the frame that fits and lead with it. Not with the technology. Not with the architecture diagram. With the business outcome.

At the fintech startup, we were heading into a period where marketing had big traffic projections. Our system couldn’t handle it. I didn’t pitch “we need to re-architect our data pipeline.” I pitched “we’ll lose paying users in Q3 if we don’t act now.” Different sentence. Same project. Completely different reaction in the room.

Risk is the easiest sell

When downside is obvious, risk framing writes itself. Quantify the probability of an outage. Estimate the cost. Multiply. That number gets attention fast because nobody wants to be the one who ignored a preventable disaster.

Growth constraints work too, but you need credible projections. Vague “we might need to scale” doesn’t cut it. Show the wall you’re about to hit and the revenue sitting on the other side.

Velocity framing is underrated. If your deploys take two hours and engineers sit idle waiting, that’s burned salary. Translate it. “We’re losing 40 engineer-hours a week to deployment bottlenecks” hits harder than “our CI/CD pipeline needs work.”

Do the math, even if it’s rough

A proposal without numbers is just an opinion. I’ve seen smart engineers lose budget requests because they couldn’t answer “what does this cost us today?” Document the current state in dollars and hours, the same way you’d price technical debt . Then describe what changes, in the same units.

Keep the ROI dead simple. Investment. Expected annual benefit. Payback period. If your assumptions are honest and explicit, rough math beats no math every single time.

Structure for skimmers

Executives don’t read proposals. They skim them. One paragraph up top: what you want, why, and what it’s worth. Then a short problem statement in business terms. Proposed solution with minimal technical detail. Quantified impact. Cost. Timeline. Risks and mitigations. Alternatives you considered and rejected.

That order matters. Bury the ask on page three and it never gets read.

Where I’ve seen pitches die

Being too technical. Your CFO doesn’t need to understand container orchestration. They need to understand what it changes for the business.

Skipping quantification. “Better reliability” means nothing. “$200K in avoided incident costs per year” means something.

Ignoring tradeoffs. If this delays a feature, say so. Explain why the trade is still worth it. Pretending there’s no cost makes you look naive.

Asking for everything at once. Phase it. Get a win. Use that win to fund the next phase.

And the killer: not following up. If you don’t report results after getting funded, you’ve just burned your credibility for the next ask.

Keep the conversation going

Don’t wait for budget season. Share metrics regularly. When an incident happens, quantify the damage. When delivery speeds up after an investment, show the numbers. Make infrastructure value visible all the time, so the next request feels like an obvious yes instead of a surprise ask.

Infrastructure is a business investment. Treat it like one and it gets funded. Treat it like a technical hobby and it doesn’t.

So I shut up, asked a few questions, and later that afternoon wrote a one-page doc outlining the bottleneck I saw. I included numbers from our existing traffic patterns. I proposed an alternative that reused most of their work. Two days later the team pivoted. I never pulled rank; the problem was clear once it was on paper.

That was the moment I understood what technical leadership without authority looks like. In my experience it’s the only kind of leadership that sticks.

Credibility is earned in the boring moments

You don’t become the person people listen to by giving brilliant speeches. You become that person by being right about the small stuff consistently. Fixing the flaky test nobody wants to touch. Jumping on an incident at 2am and writing up the postmortem the next morning. Reviewing PRs with actual thought instead of rubber-stamping them.

At the fintech startup, I had to build credibility from zero. The team was sharp. They didn’t care about titles. What they cared about was whether you could help them solve hard problems without wasting their time. Fair enough.

I focused on a few areas where I knew my experience was strong: system design, infrastructure, and debugging production issues under pressure. I didn’t pretend to know the financial domain better than people who had been in fintech for years. When I was wrong, I said so. When I was unsure, I said that too. Turns out, admitting uncertainty is one of the fastest ways to build trust. People can smell posturing.

Communication does most of the work

Influence without authority is 80% communication and 20% technical skill. You can be the best engineer in the room and still get nothing done if you can’t frame a problem in a way that makes people care.

I learned to always lead with the problem. Not my solution. The problem. If I walked into a discussion and said “we should switch to Kafka,” people pushed back instinctively. But if I said “we’re dropping 12% of events during peak load because our queue can’t keep up. Here are the numbers from last Tuesday,” suddenly everyone wanted to talk about solutions. Same destination, completely different path.

Writing things down changed everything for me. At the fintech startup we were moving fast, and decisions got lost in Slack threads and hallway conversations. I started writing short proposals, a page or two. Problem, context, recommendation, alternatives, tradeoffs. Nothing fancy. But it forced me to think clearly, and it gave people something to react to on their own time instead of in a high-pressure meeting. Half the arguments I avoided were arguments that never needed to happen in the first place.

Make other people better

The biggest unlock was realizing that my job wasn’t to be the smartest person on the team. My job was to make the team smarter. Pair with someone on a tricky migration. Share the context behind a design decision so the next person doesn’t have to reverse-engineer it. Fix the CI pipeline that wastes 20 minutes of everyone’s day.

These things aren’t glamorous. Nobody gives you a promotion for speeding up the build. But they compound. Every small improvement makes the team a little faster, a little less frustrated. And the people you helped? They remember. When you propose something ambitious later, they are the ones who back you up.

Start small, find allies

When I wanted to push a bigger initiative, say rearchitecting a service that had become a bottleneck, I never started with a grand plan. I started with a focused prototype. Something I could build in a week that demonstrated the idea was viable. Early wins create momentum. A working demo is worth ten slide decks.

Then I found allies. One person pushing for change is easy to dismiss. Three people aligned on the same problem? That’s a movement. I would share early results with engineers I trusted, get their input, fold in their ideas. By the time the proposal reached a wider audience, it wasn’t just my thing. It was our thing.

The traps that get smart engineers

Being right and being effective are two different skills. I’ve watched brilliant engineers lose every argument because they treated disagreements as contests to win instead of problems to solve together. If you burn a relationship to win a technical debate, you won the battle and lost the war. That person won’t support your next idea. Or the one after that.

Pick your battles. Not everything is worth fighting over. Some decisions are reversible and low-stakes, and spending political capital on them is a waste. Save your energy for the things that genuinely matter.

This is the job

I used to think leadership without authority was a stepping stone, something you did while waiting for the “real” leadership role. I was wrong. This is the real thing. The credibility you build, the communication habits you develop, the trust you earn: these are the foundations. If a title shows up later, great. You will be ready. If it doesn’t, you’re still the person who makes things happen. And every team needs that person more than they need another manager.

Some of that understanding came from reading. Most of it came from making mistakes and then paying attention. The short version: small teams with clear ownership, written context, and permission to disagree will outperform larger teams that rely on heroics and tribal knowledge. I learned this by getting it wrong first.

The hire that changed how I think about hiring

Early on I hired someone brilliant. Strong technical skills, great in interviews, impressive background. Within two months the team was slower than before. Not because the person was bad at code. Because they were bad at collaboration. They dismissed questions in reviews. They rewrote other people’s work without discussion. They treated every technical decision as a competition.

I waited too long to address it. I kept telling myself the technical output justified the friction. It didn’t. By the time we parted ways, I had lost one engineer who quit quietly and another who stopped contributing ideas in meetings.

The lesson was simple and painful: a good engineer who makes the people around them worse is a net negative. I don’t care how fast you can ship if the team ships slower because of you.

After that, every interview included a pairing session where I watched how candidates communicated under ambiguity. Not whether they got the answer, but how they handled not knowing it.

Writing things down saved us

The single highest-leverage practice we adopted was writing things down. Architecture decisions, deployment procedures, incident postmortems, onboarding steps. All of it.

This wasn’t natural for us. We were a small startup. Everybody sat in the same room. Writing felt like bureaucracy. Then someone went on holiday for a week and we realized that half of our operational knowledge lived in one person’s head. That isn’t a team. That’s a single point of failure with extra chairs.

We started with a rule: if you make a decision that affects how something works, write a short paragraph explaining what you decided and why. Not a formal document. Not a template. Just the decision and the reasoning. We kept these in a shared repo.

Within a month, arguments about past decisions dropped to near zero. New engineers could read the context instead of guessing. And when we revisited old decisions, we could evaluate them against the original reasoning instead of relying on memory.

Clarity scales better than talent. I believe that more every month.

Small and scoped beats big and versatile

We tried having one team that did everything. Backend, frontend, infrastructure, mobile API work. It worked at three people. At five, it started to crack. Not because people were less capable, but because context switching became the dominant activity. Everybody was halfway through everything and fully done with nothing.

We split into two groups. One owned the rider-facing product and mobile API. The other owned fleet operations, the backend services, and infrastructure. Each group had enough skills to ship without waiting for the other.

The improvement was immediate. Cycle time dropped. Ownership became clear. People stopped asking “who is working on that?” because the answer was obvious from the structure.

I don’t think there’s a magic team size. But I do think the moment coordination overhead starts eating into building time, you have outgrown your current structure. Pay attention to that signal.

Psychological safety isn’t a slogan

I used to think psychological safety meant being nice. It doesn’t. It means people can say “I don’t understand this” or “I think this is the wrong approach” without fear. That’s harder to build than it sounds.

The most useful thing I did was start admitting my own mistakes publicly. When I made a bad architectural call, I said so in standup. When I didn’t know the answer, I said that too. It felt uncomfortable at first. But within a few weeks, other people started doing the same thing. Problems surfaced earlier. Fixes came faster.

The other thing that mattered was how we handled incidents. We ran blameless postmortems for every significant outage. No finger pointing. Just: what happened, why did our systems allow it, and what do we change so it doesn’t happen again. After a few rounds of this, people stopped hiding mistakes and started reporting them immediately. That alone probably saved us from two or three serious production incidents.

Conflict is data

In a small team, disagreements are inevitable. The question is whether you treat them as a threat or as useful information.

We had a multi-week argument about service boundaries . Two engineers had fundamentally different views on where to draw the lines. My instinct was to pick a side and move on. Instead, I made them write down their positions and trade-offs. Once everything was on paper, the disagreement was about specifics, not personalities, and we found a middle path that neither of them had originally proposed.

Now I encourage disagreement, as long as it stays about the work. When it gets personal, I address it immediately. Tolerating that even once sends a signal that undermines everything else.

What I would do differently

I would hire for collaboration earlier and more deliberately. I would start writing decisions down from day one, not after the first crisis. I would split teams sooner. And I would be more honest with myself about when a personnel problem is actually a personnel problem, not a process problem.

None of this is revolutionary. But doing these things consistently, with discipline instead of heroics, made a bigger difference than any technical choice we made all year.

Technical due diligence isn’t a code audit. It’s a risk conversation. Investors want to know if the technology can do what the pitch deck promises, whether the team can sustain it, and what breaks first under growth.

What Investors Actually Care About

Here is what doesn’t matter: whether you use tabs or spaces, whether your code coverage is 80% or 90%, whether your variable names are poetic. I’ve never seen a deal die over formatting.

Here is what does matter: Can the product do what the sales team is promising customers today? Can the team extend it to do what the business plan says it will do in eighteen months? What are the risks that could slow that down or stop it entirely?

That’s really it. Everything else is a detail that feeds into one of those three questions.

Stage changes the lens considerably. When I went through diligence at the mobility startup, we were early. The codebase was scrappy. Nobody cared. The investors wanted to know if we understood our technical risks, if we could ship fast, and if the founding team had the judgment to make sound architecture decisions under pressure. At growth stage, the bar moves. Multiple engineers need to work in the codebase without stepping on each other. Deployments need to be repeatable. Security can’t be an afterthought. But even then, perfection isn’t the standard. The standard is: does this team know what they are doing, and are they making reasonable tradeoffs for their stage.

Preparing When You’re Being Evaluated

I learned this the hard way. The first due diligence session I sat through from the company side was a scramble. An investor’s technical advisor asked for an architecture diagram and we didn’t have one. Not because the architecture was bad, but because nobody had written it down. We spent half the session whiteboarding basics instead of talking about the interesting parts of the system. That was a waste.

Prepare a one-pager: architecture overview showing major components and data flow, stack list with brief rationale for key choices, infrastructure and deployment notes, team structure, and how a feature moves from idea to production. You can write this in an afternoon and it will cover 80% of what reviewers ask for.

Surface your weaknesses before they surface them. Every startup has technical debt . Every startup has areas where security is thinner than it should be. Every startup has a bus factor problem somewhere. If you say “we know our payment integration is fragile and here is our plan to fix it in Q1,” that builds trust. If the reviewer discovers it and you look surprised, that destroys trust. I’ve seen founders try to hide known problems. It never works. Good technical reviewers will find them, and then you have two problems: the weakness itself and the fact that you tried to hide it.

Clean up the obvious things. Remove dead code. Make sure there are no credentials committed to the repo. Fix the broken tests that have been ignored for months. Reviewers will sample, not read every line, but first impressions carry weight. A repo with secrets in the commit history signals carelessness.

Get your IP house in order. Employee IP assignments should be signed. Third-party licenses should be compatible with your business model. If anyone copied code from a previous employer, deal with that now. This is one of the few areas where a due diligence finding can actually kill a deal.

Evaluating Someone Else’s Technology

When I evaluate a company for an investor or acquirer, I follow a specific order that has served me well.

Architecture first. I ask the CTO to walk me through the system on a whiteboard. Not slides. A whiteboard. I want to see if they can explain their own system clearly, where the boundaries are, how data flows, and where the external dependencies live. This conversation tells me more in thirty minutes than reading code for a week. If the CTO can’t explain their architecture clearly, that’s a serious signal regardless of what the code looks like.

Team second. I talk to engineers individually. Not the CTO’s hand-picked representatives, but a cross-section. I ask about the last production incident. How they handle disagreements about technical direction. What they would change if they had a week with no feature pressure. The answers reveal whether the team has real ownership or whether everything flows through one person’s head. Bus factor is a real risk. If one departure would cripple the product, that needs to be in the report.

Code third, and selectively. I look at authentication and payment code because security mistakes there are existential. I look at the core business logic that creates differentiation. I read a few recent commits to understand current engineering standards, and I look at some older code to see how legacy is handled. I’m not grading style. I’m looking for evidence of judgment.

Operations and infrastructure. How often do they deploy? What happens when something breaks at 2 AM? Is there monitoring? Is there alerting? Are there runbooks, or is the incident response plan “call the CTO”? Manual deployments are a yellow flag. No monitoring is a red flag. At the mobility startup, we had invested in Terraform and automated deployments before our due diligence. That came up in the review and signaled operational maturity that investors valued beyond the code itself.

Scalability in context. I don’t care if the system can handle ten million users if the business plan targets ten thousand. I care about whether the team has thought about what changes at 10x their current scale. Honest answers like “our database will need read replicas at 5x and we’ll probably need to shard the activity feed at 20x” are far more reassuring than “we can scale infinitely because we’re on AWS.”

The Signals That Actually Change Outcomes

Red flags, in my experience, cluster around people and process more than technology.

No version control. I’ve seen this exactly once, and it ended the evaluation immediately. Foundational process failure.

The CTO can’t explain the architecture. If the technical leader doesn’t have a clear mental model of the system, nobody does.

Defensive answers. When I ask about a weakness and the response is deflection or minimization, I assume there are more problems I haven’t found yet. Transparency is the single strongest signal of engineering maturity.

Key person dependency with no mitigation plan. One person holding all the context for a critical system isn’t unusual at a startup. But if the team hasn’t acknowledged it as a risk or started documenting, that tells me something about how they think about risk generally.

Yellow flags need context. Technical debt is normal. Outdated dependencies are common. A monolith is fine at early stage. Limited monitoring is fixable. A junior team can work if leadership is strong. These are concerns, not deal breakers. The question is always: does the team know about it, and do they have a credible plan.

Writing a Report That’s Actually Useful

The worst due diligence reports I’ve read are laundry lists of findings with no prioritization. Twelve pages of “this function lacks error handling” tells the investor nothing about whether to write the check.

A useful report answers three questions: First, can the technology deliver on the current business promises? Second, what are the top three risks that could slow or stop progress? Third, what investment in time and money is needed to mitigate those risks? Everything else is appendix material.

Be balanced. If the team built something impressive given their constraints, say so. If the architecture is sound but the deployment process is fragile, say that too. Decision makers need to weigh risk against momentum, and a report that only lists problems is as useless as one that only lists strengths.

Honesty Wins on Both Sides

The best outcomes I’ve seen, on both sides, come from honesty. As a founder, lead with what you know is weak and what you plan to do about it. As an evaluator, focus on architecture, team, and the gap between the plan and reality. The code is the least interesting part.

Security culture isn’t a project

I’ve watched teams try to buy their way into security. They purchase a scanner, run a penetration test once a year, and call it done. Then a junior engineer hardcodes an API key, pushes it to a public repo, and suddenly the scanner doesn’t matter.

Security culture is the habit that prevents that push in the first place.

One team I worked with handled sensitive user data, including payment information. There’s no version of “we’ll fix it later” that regulators or users will accept. Security had to be foundational from the start, not bolted on after the first scare.

What cyber-defense exercises taught me

A principle I carry from cyber-defense exercises: the biggest lesson was organizational. The teams that performed well were the ones where every person understood the threat model and acted on it without waiting for permission. Tooling mattered less than that.

That stuck with me. Security at scale is a culture problem first.

The policies I actually enforce

Theory is cheap. Here are the specific rules I’ve implemented across teams.

No secrets in code. Ever. We use environment variables and a secrets manager. The CI pipeline fails if it detects anything that looks like a key or credential in the codebase. This is automated, not optional, and not overridable without a written justification that I personally review.

Every pull request gets a security question. Not a full threat model. Just one question: “What is the worst thing that happens if this code is exploited?” If the author can’t answer it, the PR doesn’t merge. This forces engineers to think about attack surface as part of their daily work, not as a separate exercise.

Least privilege by default. New services start with zero permissions and add only what they need. New employees get read access to the repositories they work on and nothing else. Escalation requires a request and a reason. I review access quarterly and revoke anything that isn’t actively justified.

Dependency updates aren’t optional. We track dependencies weekly. Known vulnerabilities get patched within 48 hours for critical severity, one week for high. This is a policy, not a suggestion. I’ve delayed feature work to meet these windows.

Incident response is rehearsed. We run a tabletop exercise every quarter. Not a checkbox drill. A real scenario where I throw a curveball halfway through to see how the team adapts. The ones who have done this three or four times respond to real incidents with calm instead of panic.

The hard part is consistency

Any team can write a security policy document. The hard part is enforcing it on the days when you’re behind on a deadline and the shortcut is right there.

I’ve blocked releases. I’ve told product managers that a feature would ship a week late because the authentication flow wasn’t reviewed. Those conversations are uncomfortable. They are also the moments that define whether your culture is real or performative.

Engineers watch what leadership does, not what leadership says. If the CTO merges a PR that skips the security review because “we need to ship,” every engineer on the team learns that security is negotiable. It takes one exception to undo months of habit building.

Security champions scale your coverage

I can’t review every line of code. No security team can. The answer isn’t to hire more security people. It’s to make every engineer a little bit dangerous.

The model I like: one engineer on each team acts as a security champion. Not a full-time role. Maybe 10-15% of their time. They attend a monthly session to review recent vulnerabilities in the stack, discuss attack patterns relevant to the business, and update the threat model.

These champions become the first line of defense in code reviews. They catch the obvious issues before they reach me, and they raise the questions that nobody else on the team would think to ask.

The key is that being a security champion is respected. It counts in performance reviews. It isn’t extra work on top of their real job. It’s part of their real job.

Make the secure path the easy path

If doing the right thing is harder than doing the wrong thing, people will do the wrong thing. That’s ordinary human behavior.

We built internal libraries that handle authentication, input validation, and encryption correctly. When an engineer needs to call an external API, they use our wrapper that handles TLS verification, credential injection, and audit logging automatically. The secure path is also the path with less code to write.

We templated our infrastructure so that new services deploy with network isolation, encrypted storage, and logging enabled by default. An engineer has to go out of their way to deploy something insecure. That friction is intentional.

Incidents are data, not blame

When something goes wrong, and it will, the response determines whether your culture strengthens or collapses.

We run blameless postmortems , because blame destroys information flow. If engineers fear punishment, they hide mistakes. Hidden mistakes compound. The breach that takes down a company is rarely the first failure. It’s the tenth failure that nobody reported because the first person who reported one got burned.

Every postmortem produces exactly two outputs: a timeline of what happened, and a list of specific changes to prevent recurrence. Not “be more careful.” Specific changes. A new automated check. A revised permission. A policy update.

Security is a daily decision

Security culture is discipline. It’s the same decision made correctly a thousand times, even when it’s inconvenient. Especially when it’s inconvenient.

You build it by enforcing the standards you set, including on yourself.

I’ve been hiring for the engineering team at a mobility startup. Shared mobility is still early. The concept is unproven, the funding is modest, and the salary bands reflect that reality.

Every good candidate I talk to has at least one offer from a company that can pay 30-50% more than I can. Some of them have offers with stock grants that look like a second salary. I can’t match that. I learned early to stop pretending I could.

But we’ve still managed to hire well. Here is what actually worked.

Be honest about money on the first call

Nothing kills trust faster than dancing around compensation. I bring it up in the first conversation. “Here is what we can pay. Here is the equity. Here is what the equity is worth today, which isn’t much, and here is what it could be worth if we execute.” No hand-waving. No “competitive salary” language that means nothing.

Most engineers respect directness. The ones who are only optimizing for cash will self-select out, and that’s fine. The ones who stay in the conversation are evaluating the whole picture, and I want to talk to those people.

Show the work, not a pitch deck

At the mobility startup I started doing something that felt risky at first: I gave candidates access to our actual codebase during the interview process. Not all of it, but enough to see how we build. Our code reviews. Our deployment pipeline. Our monitoring setup. The real thing, not a sanitized version.

This did two things. First, it filtered for engineers who cared about craft. If someone looked at our setup and got excited about the problems, that told me more than any whiteboard exercise. Second, it made the job tangible. They weren’t imagining what the work might be. They could see it.

One engineer told me he accepted our offer over a much higher one because, and I’m quoting here, “your codebase looked like people gave a damn.” That stuck with me.

Sell speed, not “startup culture”

I never use the phrase startup culture in interviews. It means nothing. What I do talk about is speed. At the mobility startup, an engineer can go from idea to production in a day . Not because we skip process, but because our process is light and the team is small enough that decisions happen fast.

I tell candidates about specific examples. Last month one of our engineers noticed a pattern in user drop-offs, proposed a fix, built it, shipped it, and we saw the numbers move within 48 hours. At a big company that same change goes through three teams, two planning cycles, and a prioritization meeting. Maybe it ships in a quarter.

Speed isn’t about working more hours. It’s about fewer layers between you and the outcome. That’s genuinely compelling to a certain kind of engineer, and those are exactly the engineers I want.

Autonomy has to be real

Every startup claims to offer autonomy. Most of them mean “we don’t have enough managers yet.” That isn’t autonomy. That’s chaos.

Real autonomy means an engineer picks the approach, owns the tradeoffs, and lives with the consequences. At the mobility startup, our engineers choose their tools. They design their own systems. They are on call for what they build , which means they build things that don’t break at 3 AM.

When I interview, I’m specific about this. I describe a recent technical decision and who made it. Not me. The engineer closest to the problem. If a candidate has been stuck in an environment where every architecture choice needs three sign-offs, that story lands hard.

Hire for the team, not the role

I can’t afford specialists. What I can afford is sharp generalists who get better at everything by doing everything. At our size, an engineer might write a service, set up the monitoring, debug a production issue, and review someone else’s database migration in the same week.

Some people hate that. Others thrive on it. I screen for the second group by asking about the last time they worked outside their comfort zone and what they learned. The answers tell me whether someone wants range or just wants to go deeper on one thing. Neither is wrong, but only one fits where we are right now.

The peer interview matters most

The single best recruiting tool I have is my existing team. When a candidate meets the people they would work with every day and those people are sharp, thoughtful, and honest about the hard parts of the job, that’s more persuasive than anything I can say.

I make sure candidates spend real time with the team. Not a panel interview. A working session or a design conversation. Something that feels like the actual job. If they click with the team, the salary gap shrinks in their mental math. If they don’t click, no amount of money would have made it work anyway.

What I got wrong early on

I wasted time in the beginning trying to compete on perks. Free lunches, flexible hours, the usual startup bingo card. None of it moved the needle. Engineers saw through it immediately.

What moved the needle was being specific and being honest. Specific about the problems we’re solving, the systems we’re building, and where we’re going. Honest about what is hard, what is broken, and what we haven’t figured out yet.

The best hires we’ve made came from conversations where I said something like, “Our deployment process isn’t great yet and you would own fixing it.” That kind of honesty attracts builders. Glossy pitches attract people who want to be at a company that sounds good, not people who want to do the work.

You will lose candidates to money

You will lose candidates to higher offers. It will happen regularly. Some of those candidates would have been great, and it will sting.

But the engineers who join you despite the lower salary are making a deliberate choice. They are choosing the work, the team, and the trajectory over the paycheck. From what I’ve seen, those people build better things and stay longer. Not always. But often enough that I’ve stopped trying to win the compensation game and started focusing on winning the “is this work worth doing” game instead.

That’s a game a startup can actually win.

DevOps isn’t a role. It isn’t Jenkins. It isn’t even a set of practices you can copy from a blog post. It’s a cultural shift where the people who build software and the people who run it share the same goals, the same pain, and the same wins. Fix the incentives that make dev and ops fight each other first. Tools come second.

I learned this the hard way at a mobility startup.

What Happened at the Mobility Startup

When I joined, we had a classic split. Three backend engineers shipping features as fast as possible. One ops person, call him Max, who kept the lights on. The engineers would push code on Friday afternoon, Max would get paged at 2 a.m. Saturday, and Monday morning would start with a blame session disguised as a standup.

Max was good at his job. The engineers were good at theirs. The system between them was broken.

The fix wasn’t a tool. It was a conversation. I put the entire team in a room and said: starting next week, the person who ships the code carries the pager for it. Not forever, just for the first 48 hours after deploy. If your code wakes someone up, that someone is you.

The reaction was roughly what you would expect. The engineers hated it. Max loved it. But within two weeks, something shifted. Deploys got smaller. Engineers started writing health checks without being asked. Someone added a runbook for the payment service, unprompted. The Friday afternoon deploys stopped entirely.

Nobody told them to do any of that. The incentive structure changed, and the behavior followed.

Start With Shared Pain, Not Shared Tools

That experience taught me something I keep coming back to: if you want DevOps culture, start by making everyone feel the consequences of their decisions.

Developers who never see production alerts write code that’s hard to operate. Ops people who never sit in planning meetings treat every deploy as a threat. The gap is empathy.

The cheapest thing you can do is cross-pollinate. Have a developer shadow on-call for a week. Have the ops person sit in sprint planning. Run a postmortem together after the next incident and focus on the system, not the person. I’ve never seen a team do this and not come out with a better understanding of each other.

Pick a Pilot Team and Let Them Own It

Don’t try to transform the whole company at once. Pick one team. Give them ownership of their deploy pipeline and their on-call. Let them figure out what works. Measure what happens.

At the mobility startup, that pilot was the team running the vehicle availability service. Small blast radius, clear metrics, leadership willing to experiment. They went from deploying once a week to deploying daily within a month. Not because I told them to, but because shorter cycles meant smaller changes meant fewer pages.

The rest of the engineering org watched this happen. Nobody had to sell them on DevOps after that. They just asked when they could start.

The Technical Stuff Matters, But It Isn’t First

Once the culture is moving, you need the technical foundations to support it. Infrastructure as code so environments are reproducible. A CI pipeline so every commit gets tested. Monitoring that answers “is this thing working” without requiring tribal knowledge.

In 2016, that means Ansible or Chef for config management, Jenkins or CircleCI for builds, and something like the ELK stack or Graphite for observability. The specific tools matter less than the principle: everything should be automated, version-controlled, and visible to the whole team.

I’ve seen teams with perfect pipelines and terrible culture. The pipeline doesn’t fix trust. It just makes deploys faster. If the team still throws code over the wall and blames each other when it breaks, a faster pipeline just accelerates the dysfunction.

Traps I’ve Walked Into

The hero trap. At the mobility startup, Max was the hero. He could fix anything at 3 a.m. That felt like a strength until he took a week off and nobody knew how to restart the payment gateway. Heroes are a single point of failure wearing a cape. Spread the knowledge.

Tool obsession. We spent two weeks evaluating orchestration platforms when the real problem was that nobody knew what was running in production. A shared spreadsheet would have been more useful than Kubernetes at that point. Solve the problem you actually have.

Burnout disguised as ownership. If you give developers pager duty without reducing their feature load, you aren’t building DevOps culture. You’re just distributing the suffering more evenly. Shared responsibility means shared capacity planning too.

It’s a Slow Game

DevOps culture doesn’t happen in a quarter. At the mobility startup, it took about six months before the dev-vs-ops tension actually went away. The team went from monthly releases with weekend war rooms to daily deploys that nobody thought twice about. But it was gradual, messy, and full of setbacks.

The wins compound though. Smaller deploys mean fewer incidents. Fewer incidents mean less firefighting. Less firefighting means more time for the work that actually matters. Once that flywheel starts turning, it’s hard to stop.

If you’re starting from zero, that’s fine. Most teams are. Start with the incentives, not the tools. Make people feel what production actually looks like. Pick a small team and let them prove the model. The culture will follow the work.

And then nothing happens. Or worse, leadership approves a vague “cleanup sprint” that accomplishes nothing measurable, and next quarter the same complaints come back louder.

The debt isn’t the problem. The inability to quantify it is.

Ward Cunningham coined the metaphor in 1992, and he chose finance deliberately. Debt has a principal and an interest rate. You can calculate whether it’s worth carrying or paying down. But most engineering teams skip the math entirely. They treat tech debt like a feeling: something you gripe about in retros but never attach a number to.

I’ve been guilty of this. Early at the mobility startup, I’d walk into planning meetings and say things like “the data layer is fragile” or “deploys are getting riskier.” True statements. Completely useless for getting resources allocated. The product team heard “engineers want to rewrite things instead of shipping features.” Which, from their perspective, was a reasonable interpretation.

What changed was when I started tracking three things. First, how long the same type of task took six months ago versus now. Second, how many incidents traced back to the same modules. Third, how much engineer time went into those incidents, counting the fix, the investigation, the communication, and the customer support follow-up.

The numbers were ugly. A task category that averaged two days in mid-2015 was averaging five days by early 2016. Same complexity, same team size. The difference was the accumulated mess in three interconnected services . One module was responsible for four incidents in a single quarter, each burning two to three engineer-days when you counted everything.

Suddenly I wasn’t saying “the billing module is fragile.” I was saying “this module cost us roughly ten engineer-days last quarter in incidents alone, and it’s adding three days to every feature that touches payments.” That’s a number a CEO can reason about. That’s a number you can weigh against a feature roadmap.

The fix doesn’t need to be dramatic. One team I worked with allocated 15% of sprint capacity to debt work. Not negotiable, not borrowable. Small, targeted improvements. Tighten a function while you’re already in the file. Add the missing integration test before you move on. Replace the brittle dependency before it causes another 2am page.

Compound interest works both ways. Small consistent payments on debt keep the codebase healthy enough to move fast. Skip those payments and the interest compounds until a “small change” takes a week and every deploy is a coin flip.

The teams that handle debt well can tell you exactly what their debt costs. They measure cycle time trends. They track incident attribution. They know which modules are hotspots and what those hotspots cost per quarter in real engineer hours.

If you can’t put a number on your tech debt, you can’t make a rational decision about it. And if you can’t make a rational decision, you’ll either ignore it until it cripples you or waste time on cleanup that doesn’t matter.

Measure the pain. Do the math. Present the tradeoff in terms the business already understands. That’s the whole strategy. Everything else is just complaining.