The plan needs two quantities nobody currently measures. The first is offered review demand, and the unit is review-minutes, not pull requests. Counting PRs is like counting “some vehicles” at a bridge; a dependency bump and an authorization rewrite are different loads. Estimate minutes per change from size, surface touched, and blast radius, crudely at first, calibrated later from actuals. Note what this replaces: seat count. Seats are not demand. A seat can sit idle, can replace typing without adding submissions, or can produce changes that arrive with evidence and review faster. What hits the queue is minutes, so measure minutes. The second quantity is effective reviewer capacity: not headcount times forty hours, but the review-minutes your qualified reviewers can actually give, after meetings, on-call, and their own delivery work, measured from review activity rather than assumed.

Demand against capacity gives you a utilization ratio, and here queueing theory earns its keep as a warning model, no more. For a stage with high variability in job sizes, which review is, extremely, waiting times grow nonlinearly as the ratio approaches one, and the growth steepens with the variability. Don’t quote a magic threshold; the practical rule is humbler. Track the ratio and the queue-age tail together, per risk class, and treat a rising tail as the constraint announcing itself. The classes matter because the single most effective lever isn’t more reviewers. It’s refusing to price all changes identically.

That lever is risk-tiered review, and it should come before any cap. Low-risk classes, the reversible, well-tested, non-privileged surfaces, get automated checks plus sampled human review at a stated rate, with the sample watched for escapes; the tier earns its lighter process by evidence, and loses it the same way. High-risk classes get full human review from a capacity budget reserved for them, so an authorization change never queues behind forty dependency bumps. Tiering can multiply effective capacity outright. What it can’t do is repeal the arithmetic on the residual: the human-review tiers still have an arrival rate and a capacity, and when the first approaches the second, you cap work-in-progress. Not because Little’s Law commands it, but because the relationship it states means bounded queues are the only way to bound cycle time. When the cap binds, the rule for agents is specific, because “agents work on the queue” invites a category error: an author rechecking itself is not verification. Capped agents split oversized changes, rebase stale ones, answer review comments, repair failing checks, and attach evidence (tests, eval results, stated blast radius) that shrinks a reviewer’s minutes-per-change. Independent verification stays with an independent party, human or a separately-tasked checker , and new submissions wait.

Two boundaries on this program. The metrics need definitions before dashboards: attribute changes to agents at commit metadata, split queued-minutes from active-review-minutes, track p50/p95 queue age per tier, and count escapes per hundred merged changes in a fixed attribution window. Loose definitions here produce confident nonsense. And the apprenticeship pipeline is a capacity investment on a months-long crossover, not a Q4 lever; budget it like one, expecting senior minutes to rise before they fall.

The one-sentence version for the seat-count conversation: your agent capacity is not your seat count, it’s your verified-throughput rate, and the ratio of offered review-minutes to reviewer-minutes tells you which side of the constraint each team is on. Buy seats up to the constraint. Past it, spend the same money on the constraint itself, on tiering, evidence, and reviewers, because that’s where throughput now lives.

Before building on that, note what a survey rate can’t say. A conglomerate has hundreds of workflows; one scaled agent anywhere lets its respondent answer “scaling,” so some of the gap is arithmetic: more workflows, more chances to report. And a smaller firm may be rationally slower. With fewer workflows whose volume justifies the evaluation, supervision, and failure costs agents carry, the correct agent count for some businesses is currently zero. Both explanations are live. The hypothesis I’d add, from that handful (a sample, not a study), is that a real constraint sits in the gap too: scaling agents needs scaffolding, meaning evals, identity, cost control, rollback , and the reference architectures for that scaffolding ship in enterprise size only. Big companies staffed a platform team. Small companies read the same posts, correctly concluded they couldn’t afford one, and stayed in permanent pilot. If that’s right, the failure mode below the line isn’t absent ambition, it’s the miniature enterprise program: a year or more of foundation for workflows that needed a few weeks, recreating the bottleneck platform teams become with none of the amortization that justifies them.

The correction isn’t a smaller platform. A small company needs one workflow with an owner, a quality gate, a security boundary, a cost ceiling, and an off switch. Five entry conditions, each written as a test an executive can check, not a system to build.

An owner: one named person for one commercially real workflow, whose review includes the adoption and outcome numbers, not a side quest . Test: you can say who, and they can say what number they’re moving. A quality gate: a few dozen real cases with pass criteria a domain expert wrote, versioned, run on every change, blocking on failure. That’s the benchmark only you can build , at minimum viable size. Test: a change that degrades the eval set cannot ship. A security boundary: the agent holds its own deny-by-default credentials scoped to that workflow’s systems, and you have revoked them once to prove you can. Test: the revocation drill happened. A cost ceiling: the workflow’s spend on its own billing tag, with a threshold that alerts the owner. Test: the owner saw last week’s number. An off switch: a rehearsed way to route the workflow back to the manual path, with the detection that triggers it. Test: you’ve run it, and the workflow survived the hour.

Then the discipline that makes five conditions sufficient where a platform wasn’t necessary: the amortization rule. Scaffolding amortized across one workflow must be nearly free, so nothing generalizes until workflow two demands it. The registry arrives when two workflows share prompts, the gateway when two owners need the same boundary, the standing review when there are enough numbers to fill one. Abstractions earn existence on the second use. The go/no-go for workflow one is the same arithmetic: expected value of the workflow, against evaluation, supervision, failure, and operating cost. If nothing clears that bar, the right answer is zero agents this quarter, and none of the five conditions built on spec. That outcome is also the falsifier for my hypothesis: a company that meets the five conditions on a worthwhile workflow and still can’t scale it is evidence the constraint lives somewhere else.

If you run a larger org, invert the reading. Your platform investment finally pays in exactly the coin the survey suggests, and the risk is spending the advantage on ceremony instead of workflows that route work differently . Either side of the billion-dollar line, the unit of progress is the same, and it isn’t a platform. It’s one workflow, owned, gated, bounded, metered, and stoppable. Then the next one.

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.

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.

Recruiting Alone Cannot Fix a Broken Stack

AI organizations often describe their issue as “we need stronger talent.” In many cases, they already have capable people. What they lack is a clear operating contract across teams.

The pattern is familiar:

• product optimizes for release velocity
• platform optimizes for reliability and control
• applied AI optimizes for model behavior and evaluation quality

Each goal is rational. The breakdown happens at the handoffs.

When interfaces are unclear, every launch becomes a negotiation. When interfaces are explicit, the same teams produce compounding output.

The Three-Layer Talent Stack

A healthy stack has three interlocking layers with distinct responsibilities:

1. Product owns user outcomes and business success metrics.
2. Platform owns safe defaults, deployment paths, and observability.
3. Applied AI owns workflow behavior, retrieval/prompting/routing choices, and evaluation quality.

They are system components with different jobs.

If product outruns platform, quality debt accumulates. If platform outruns product, infrastructure becomes generic overhead. If applied AI outruns both, you get technically impressive demos that never operationalize.

Where Organizations Usually Break

Most failures are boundary failures, not individual failures.

Common symptoms:

• no explicit owner for the model-to-product handoff
• platform operating as a ticket queue instead of an enablement layer
• applied AI measured by demo novelty instead of adoption in live workflows
• product committing features that infra cannot support safely

Org debt is usually interface debt with better branding.

Design the Stack Intentionally

The fix is not “more syncs.” The fix is explicit decision rights.

• product owns problem selection and business tradeoffs
• platform owns reliability guardrails and release safety
• applied AI owns workflow performance and evaluation integrity
• leadership owns escalation rules when tradeoffs conflict

Once this is explicit, hiring quality improves. You stop searching for mythical generalists and start hiring operators who can perform inside a coherent system.

What to Evaluate Before Adding Headcount

Before opening new roles, run this short check:

1. Are cross-team handoffs documented and current?
2. Does each layer have clear success metrics it actually controls?
3. Are escalation paths clear when speed, reliability, and quality disagree?
4. Are teams rewarded for system outcomes rather than local optimization?

If those answers are weak, fix interfaces first. New hires will scale the current operating model, good or bad.

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.

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

Individual engineers using Copilot or ChatGPT to write code faster is fine. It’s also not the point. One person moving 20% faster doesn’t help if the team is still bottlenecked on the same things it was bottlenecked on six months ago: stale docs, unclear decisions, and onboarding that requires cornering a senior engineer for two hours.

The teams I see getting real gains are the ones that treat AI as shared infrastructure. Not a personal productivity hack. Infrastructure.

What that looks like in practice

A shared assistant for team documentation and search that points to actual internal sources and tells you who owns what, instead of a chatbot that guesses. Automated meeting summaries that feed into the same system where the team already tracks decisions. Onboarding workflows where a new hire can get a credible first answer and a pointer to the right human, instead of posting in Slack and hoping someone responds.

None of these need perfect accuracy. They need consistent routing and clear expectations about when AI is advisory versus authoritative.

The measurement trap

Most teams go wrong here. They measure AI tool adoption . Number of prompts. Lines of code generated. That’s like measuring how many emails your team sends and calling it productivity.

The only question that matters: is the team less stuck?

Fewer repeated questions about the same topic. A shorter gap between a decision being made and that decision being documented. Less rework because someone missed context from a meeting they weren’t in.

If AI usage goes up but those numbers stay flat, you have added a toy, not infrastructure.

Docs, specifically

Documentation is where AI has the most underrated impact. Generating docs from scratch produces garbage. What works: proposing small updates when code changes, flagging content that no longer matches reality, and making each update feel like a five-second approval instead of a batch project.

At one startup I worked at, we struggled with doc decay like everyone else. The trick was making updates feel like routine housekeeping, not a chore you schedule for “next sprint” and never do.

Start small, stay boring

Pick one shared workflow. Make it reliable. Expand based on evidence, not enthusiasm. A small, visible win, like meeting notes that are actually useful the next day, changes team behavior more than any broad AI rollout plan.

The teams getting durable gains are the ones keeping AI practical, scoped, and accountable. Boring wins. As usual.

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.

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.

This isn’t a tooling problem. Notion, Confluence, GitHub wikis, markdown in the repo: the tool doesn’t matter if nobody owns the content.

Why Nobody Reads Your Docs

It’s always the same reasons:

They can’t find them. Docs live in three different places, none of them searchable in the way engineers actually search. Slack threads become the real documentation, and Slack threads expire.

They don’t trust them. One bad experience with an outdated runbook and the engineer stops checking docs entirely. Rational behavior. If the doc might be wrong, it’s faster to ask a human.

They’re written for the wrong audience. A tutorial mixed with reference material mixed with architectural rationale. The reader can’t tell what kind of doc they’re looking at, so they close the tab.

The Fix Is Boring

Separate your doc types. This is the Divio framework and it works:

• Tutorials: learning-oriented, for newcomers. “Follow these steps and you’ll have a running service.”
• How-to guides: task-oriented, for people who already know the basics. “How to rotate database credentials.”
• Explanations: understanding-oriented. “Why we chose event sourcing for the payment system.”
• Reference: information-oriented. API specs, config options, environment variables.

When you mix these, you get a doc that’s too long for lookup and too shallow for learning. Pick one purpose per page.

Structure That Earns Trust

Readers scan. They decide in five seconds whether to keep reading. Help them:

• State the purpose and audience in the first line.
• List prerequisites up front.
• One action per step. Expected output after each step.
• A troubleshooting section for the two or three things that always go wrong.
• An owner name and a “last verified” date.

That last one matters more than people think. A doc with “Last verified: 2022-06-01 by @law” tells the reader someone is paying attention. A doc with no date and no owner tells the reader nobody is.

Ownership Is the Whole Game

At a large consumer platform, we started requiring that every doc in our team’s wiki had exactly one owner. Not a team. A person. That person got a quarterly reminder to verify or archive.

The result: we deleted about 40% of our docs in the first quarter. That was a good thing. The remaining 60% were accurate, and engineers started trusting them again.

No owner means no maintenance. No maintenance means the doc will lie to you. A lying doc is worse than no doc.

Docs as Code

Put docs in the repo. Require doc updates in PRs when behavior changes. Run link checks in CI. It’s the same review process you already use for code. If the deploy process changes and the PR doesn’t update the runbook, the reviewer should block it.

I know this sounds heavy. It’s lighter than answering the same question in Slack every week.

Stop Measuring Page Views

Page views tell you nothing useful. A doc that gets 500 views might be getting 500 confused visitors who leave after ten seconds.

Better signals: How many support questions come in on topics you have documented? How long does onboarding take? How often do incidents get extended because the runbook was wrong?

If the answer to “where is the doc for X” is always “ask Sarah,” your docs have failed regardless of how many pages you have.

Documentation is a product. Ship it or kill it.

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.

That’s a distributed team working. No drama. No blocked work. No meeting about it afterward.

I’ve worked remote-first since before the pandemic made it fashionable. So when March hit and every company on Earth suddenly became “distributed,” I had a front-row seat to a lot of people reinventing wheels. Badly.

Six months in, the panic phase is over. But most teams are still stuck in this weird middle ground where they’re doing office work over Zoom and calling it remote. It’s not. And that gap is where the pain lives.

Writing is the job now

This is the single biggest adjustment and most teams still haven’t made it. In an office, you can be sloppy with communication because you’ll bump into someone at lunch and clear it up. Distributed? That ambiguity sits there rotting until someone makes the wrong assumption.

On the teams I lead, we write everything down . Nobody loves documentation. We do it because the alternative is having the same conversation three times across two time zones and a Slack thread that’s 200 messages deep.

When someone proposes a change, they write it up. Context, options, recommendation. It takes maybe 20 minutes. It saves hours of meetings that would’ve happened otherwise. The people who push back on this the hardest are usually the ones who are used to winning arguments by talking louder in a room. That doesn’t work in a Google Doc.

Meetings should hurt to schedule

Hot take: if your remote team is in more meetings than your office team was, you’ve failed. The whole point of going distributed is that async is the default. Meetings are the exception.

We have a few standing syncs. Short ones. Everything else requires an agenda shared beforehand and a written outcome after. If you can’t write an agenda, you don’t need a meeting. You need to think more about what you actually want.

The time zone thing makes this easier. When you only have a four-hour overlap with half your team, you get very precious about those hours. Pairing sessions, hard design problems, the stuff where real-time back-and-forth actually matters. Everything else goes async.

Onboarding is where you find out if your system works

New hires are the stress test. If your distributed setup actually works, a new person should be able to get productive without scheduling fifteen “intro calls.” If they can’t, your onboarding and documentation are bad. Full stop.

We give every new hire a buddy, a setup guide, and a small ticket that ships in the first week. The shipping part matters. Nothing builds confidence like seeing your code in production on day four. Compare that to spending your first week in orientation decks learning about the company values. Please.

The green dot problem

I talk to other engineering leads and the thing that makes me angry is the surveillance stuff. Screen monitoring. Activity tracking. Checking who’s online at what time.

Stop it. You’re measuring presence, not output. I don’t care if someone takes a two-hour break at 2pm to go for a run. I care if the work ships. If you can’t evaluate your engineers without watching their screen, that’s a management problem. The same goes for activity metrics .

On my teams we’re explicit about this: here’s what we expect this sprint, here’s how we check in, here’s what “done” looks like. That clarity is the actual work of management. It’s harder than installing monitoring software, which is exactly why most people don’t do it.

What still sucks

I’m not going to pretend it’s all figured out. Some things about distributed work are worse.

Catching burnout is harder. In an office you can see someone looking tired or disengaged. Over Slack, people just go quiet, and by the time you notice, they’re already job hunting. I still don’t have a great answer for this beyond frequent 1:1s and actually paying attention.

Spontaneous collaboration is basically gone. Those hallway conversations where two people accidentally solve a problem? They don’t happen on Zoom. We’ve tried virtual coffee chats and random pairing. It’s fine. It’s not the same.

And onboarding senior people into leadership roles remotely is rough. Building the trust and political capital that lets you make big calls takes longer when you can’t read a room.

Remote work exposes old dysfunction

None of this is complicated. Most teams struggle with remote work because distributed work is less forgiving of the dysfunction they were already getting away with in the office. Tools and process docs don’t change that. Bad communication, unclear ownership, meetings that should’ve been emails: all of that was survivable when everyone sat in the same building. Remove the building, and it falls apart.

Fix the fundamentals and the rest follows. Or don’t, and keep blaming Zoom fatigue. Up to you.

I’ve worked remote-first for years, and my cloud infrastructure startup has been fully remote since day one. Not as a pandemic response. By design. So I’m not theorizing here.

You don’t need a 40-page remote work policy. You need to unblock your team this week and set three or four norms that prevent chaos. That’s it.

Week one: just unblock people

Nothing else matters if your engineers can’t access the systems they need from home. This is your only priority for the first few days.

• VPN or zero-trust access. Test it. Half your team has never used it outside the office.
• MFA on everything critical. If you haven’t done this yet, now’s the time. Security doesn’t get a pass because things are hectic.
• Make sure people have decent hardware. Laptop, headset, stable internet. Ship monitors to anyone who needs one. Don’t be cheap about this. A $300 monitor pays for itself in a week of productivity.
• Set up a single support channel for “I can’t access X” problems. Staff it. The first week will be a flood of small blockers. Clear them fast.

Set three norms and actually enforce them

You don’t need a communication manifesto. You need these three things:

1. Async by default . Write your updates so someone in a different timezone (or just eating lunch) can read them and act without scheduling a call. A daily standup message in Slack is worth more than a 30-minute video call where half the team zones out.

2. Meetings need agendas. No agenda, no meeting. This was good practice before. Now it’s survival. I’ve watched teams fill every hour with Zoom calls within three days of going remote. The result is zero deep work and everyone’s exhausted by Wednesday.

3. It’s okay to not respond instantly. This is the one most managers get wrong. They see someone’s Slack dot go grey and panic. Stop. Measure output, not presence. If your engineers are shipping, leave them alone.

The stuff people forget

PRs become your main communication channel. Treat them that way. Good descriptions, clear context on why something changed, how to test it. Hallway conversations don’t exist anymore. The PR is where knowledge transfer happens now.

People will burn out faster than you expect. Working from home isn’t a vacation. The boundary between work and life evaporates. I’ve seen it. Encourage your team to set hard stop times. Lead by example. Don’t send messages at midnight and expect nobody to notice.

New hires are the most vulnerable. They can’t lean over and ask someone a question. Onboarding that was shaky in the office gets worse remotely. Assign them a buddy. Give them a small, well-scoped first task. Check in daily for the first two weeks. This is where remote-first companies either win or lose.

One more thing

Stop trying to recreate the office over Zoom. You’re not going to replicate the whiteboard or the water cooler. That’s fine. Remote work is a different mode with its own habits.

The teams that accept this and build new habits around async communication, written decisions, and trust-based management will come out of this stronger. The teams that spend all day on video calls trying to simulate an open floor plan will burn out in a month.

I’ve been doing this for years. It works. But only if you commit to it instead of treating it as a temporary inconvenience.

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.

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.

At the fintech startup, we went through a painful period where our reviews were either rubber stamps or nitpick wars. Neither helped. We’d ship bugs that a real review would have caught, then overcorrect into hour-long debates about variable naming. It took us a while to find the middle ground. This is what worked, building on what I wrote last year about review quality over quantity .

Reviews exist to manage risk

That’s it. Not to prove you’re clever. Not to enforce your preferred bracket style. Risk.

When I review code now, I’m asking myself a few things: Will this break something in production? Will someone three months from now understand what this does? Are the tests actually testing the right behavior?

The highest-value areas to focus on:

• Data correctness. Anything touching migrations or money gets extra scrutiny. Full stop.
• Security and access control. One missed auth check can undo months of good work.
• Error handling. The happy path is easy. The question is what happens when things go wrong.
• Performance. That innocent-looking query inside a loop? It will bite you.

Everything else (formatting, import order, naming conventions) should be automated. Every minute a human spends arguing about tabs vs spaces is a minute not spent catching a real bug.

How I read a PR

I have a simple routine. Read the description first to understand what the change is supposed to do. Then jump to the tests, which tell you what the author thinks the behavior should be. Then trace the main code path. Finally, look at error handling and edge cases.

This order matters. If you start reading code line by line without context, you’ll waste time on details that don’t matter.

Giving feedback that doesn’t suck

We had a problem at the fintech startup where review comments were either too vague or too aggressive. “This is wrong” helps nobody. “This function does three things, consider splitting parsing from validation so each has one job” is actionable.

A few things that changed our review culture for the better:

Label your comments. We started tagging things as [blocker], [suggestion], or [nit]. Sounds small. Made a huge difference. Suddenly people knew which comments were “fix this or we don’t merge” versus “take it or leave it.” Removed so much unnecessary back-and-forth.

Ask questions instead of making demands. “Is there a reason we check this condition twice?” lands differently than “Remove the redundant check.” Maybe there’s a reason. Maybe the author knows something you don’t.

Explain the why. Don’t just say “use a map here.” Say “this lookup is O(n) inside the loop, a map makes it O(1), and this list will grow.” Now the author learns something instead of just obeying.

Making your PR easy to review

This is the part most people skip, and it drives me nuts. If your PR is 800 lines with no description and no tests, you’re not going to get a good review. You’re going to get a tired reviewer clicking approve to clear their queue.

Keep changes small and focused. Self-review your own diff before asking someone else to look at it. You’d be amazed how many issues you catch yourself. Write a description that explains what problem you’re solving, what tradeoffs you made, and how you tested it.

At the fintech startup we started using a dead-simple PR template:

## What does this solve?
## Key decisions
## How I tested it

Three questions. Takes two minutes to fill out. Cuts review time significantly because the reviewer isn’t guessing at intent.

The team stuff

Review turnaround matters. We set a norm: small PRs get reviewed same day. Bigger ones within 48 hours. When reviews sit for days, people context-switch, branches diverge, and merging becomes painful. Fast reviews keep everyone moving.

Let CI handle the boring stuff. Linting, formatting, type checks, security scanning: all automated. The reviewer’s job is to think about things machines can’t: design, intent, risk.

Disagreements happen. When two people can’t agree, we focus on the goal of the change, not personal taste. If we’re still stuck, we pull in a third person, make a call, and write it down so we don’t relitigate it next sprint.

My quick mental checklist

Before I approve anything, I run through this:

• Do I understand what this change is trying to do?
• Does the code actually do that?
• Are edge cases handled?
• Do the tests cover the risky parts?
• Will this be readable in six months?

If I can answer yes to all five, I approve. If not, I comment.

Once we stopped treating reviews as a gatekeeping ritual and started treating them as a conversation about risk and clarity, we got fewer bugs, faster merges, and less friction.

That was March. By December, we had a small platform team that actually worked. Getting there was messy.

The problem was obvious

We had product engineers writing their own deployment scripts. Plural. Each service had its own way of getting to production. Some used shell scripts checked into the repo. One team had a guy who just SSH’d into the box. Logging was inconsistent. Monitoring was whatever someone remembered to set up. When something broke at 2 AM, diagnosing it meant guessing which service did what and where its logs lived.

This is fine when you have three services. We had more than three services.

What we built

I kept the scope ruthless. Four areas, nothing else.

Developer experience. CI/CD pipelines , a shared staging environment, deployment tooling that didn’t require tribal knowledge. This was the first thing we tackled because it was the loudest pain point.

Runtime infrastructure. Databases, caches, message queues. Standardized. Documented. Not six different Postgres configurations floating around.

Observability. Centralized logging and monitoring . One place to look when things go wrong. This alone saved us hours every incident.

Security defaults. Secrets management that wasn’t “put it in an environment variable and hope.” Auth tooling that product teams could plug into without reading a novel.

Treat it like a product or it dies

What I didn’t expect: building the platform was the easy part. Getting people to use it was the actual job.

We had product engineers with muscle memory. They knew their janky deploy scripts. They didn’t trust our new pipeline. Fair enough. So I stopped thinking of the platform as infrastructure and started thinking of it as a product. Our users were the product teams. If they didn’t adopt what we built, we failed. Full stop.

This meant sitting with teams. Watching them work. Asking dumb questions like “why did you just do that manually?” and then going back and automating whatever that was. It meant writing docs that were actually useful, not docs that checked a box. It meant having a Slack channel where people got answers fast.

Self-service was non-negotiable. If a team needed a new database, they should get it in minutes. Not file a ticket. Not wait for me to wake up. The moment we became a ticket queue, we became the bottleneck we were trying to eliminate.

How we built the team

I started alone, then pulled in one more person with strong ops background. That was the right call. You need someone who has been paged at 3 AM and someone who knows how to build tooling that doesn’t feel like punishment to use. Pure infra people build things that work but nobody can figure out. Pure app developers build things that look nice but fall over under load.

We stayed small. Two people, then three by Q4. Attached to engineering leadership, sitting next to the product teams. Physically close. That proximity matters more than any process. When you overhear someone complaining about deploys, you fix deploys. When you’re in a different building, you build things nobody asked for.

Paved roads over mandates

We never mandated anything. I hate mandates. Instead, we built paved roads, to borrow Netflix’s term: a service template, a default pipeline config, a monitoring setup that worked out of the box. You could ignore it all and do your own thing. But the paved road was so much easier that nobody bothered.

That’s the trick. Make the right thing the easy thing. Don’t write policies. Write code that makes the policy unnecessary.

We exposed platform capabilities through simple APIs. Want a database? Here’s a YAML spec, submit it, done. Want to deploy? Push to master. Want logs? They are already where you expect them.

apiVersion: platform.example.com/v1
kind: Database
metadata:
  name: billing-db
spec:
  engine: postgresql
  size: small

Nothing fancy. Deliberately boring. Boring infrastructure is good infrastructure.

What I would do differently

I waited too long to write documentation. The first three months, everything lived in my head and in Slack threads. That doesn’t scale, even at our size. Write the docs early, even if they are rough.

I also underestimated how much time support would eat. By September, I was spending most of my week answering questions and helping teams migrate. Almost no time left to build new capabilities. We fixed this by setting explicit office hours and protecting two full days per week for building. Should have done that from day one.

Where this goes next

We’re a small company. This setup works for our size. If the fintech startup doubles its engineering team, the platform group will need to split into focused sub-teams: developer experience, infrastructure, security. But not yet. Right now the right move is staying lean and staying close to the people we serve.

A platform team is a product team that happens to build infrastructure. The moment you forget the product part, you’re just an ops team with a fancier name.

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.

I know that sounds harsh. But I’ve watched it happen over and over at the fintech startup and at every team I’ve worked with before. Someone opens a PR, someone else clicks approve within three minutes, and we all pretend the process worked. It didn’t. Nobody read anything. The review was theater.

Almost nobody skips reviews anymore. The problem is that teams confuse doing reviews with doing them well. You can have a 100% review rate and still ship garbage if nobody’s actually thinking about the code they’re approving.

Read the damn code

This shouldn’t need saying, but here we are. Before you leave a single comment on a PR, you need to understand what the change does and why it exists. If the PR description doesn’t explain that, send it back. Don’t guess. Don’t fill in the blanks yourself and hope you got it right.

At the fintech startup we made it a rule: if you can’t explain the change to someone else in plain language, you haven’t reviewed it. Simple as that. I’ve rejected “LGTM” approvals that came in ninety seconds after a PR was opened. There’s no way you read 400 lines of code in ninety seconds. You just didn’t.

Follow the data through the code. Step through the logic path. Check what happens when things go wrong, not just when they go right. That’s the work.

Stop obsessing over style

I see this constantly. A reviewer leaves fifteen comments about bracket placement and variable naming while completely missing a SQL injection vulnerability three lines down. Priorities, people.

Correctness. Security. Error handling. Edge cases. Maintainability. That’s what humans should focus on. Everything else should be automated. We set up linters and formatters specifically so we could stop arguing about tabs versus spaces and start catching actual bugs.

If your review comments are mostly about style, you’re copyediting.

Say something useful

“This is confusing” isn’t feedback. It’s a feeling. Tell the author what is confusing and why. Better yet, suggest a fix.

If a function called processUserData is doing both validation and transformation, don’t just say “this does too much.” Say “split this into validateUserData and transformUserData so we can test them independently and the control flow is obvious.” That’s something someone can act on in five minutes instead of spending twenty minutes guessing what you meant.

Also, label your comments. At the fintech startup we started prefixing with blocker:, suggestion:, or question:. It sounds bureaucratic, but it completely changed the dynamic. Authors stopped treating every comment as a demand and reviewers stopped softening real concerns to avoid conflict. Blockers block the merge. Suggestions are optional. Questions are just questions.

Make reviews possible in the first place

Giant PRs get bad reviews. Always. Nobody can hold 2000 lines of diff in their head and reason about correctness. The code might be fine. The reviewer will never know because they glazed over at line 300.

Keep PRs small. One concern per PR. Write a description that explains the problem, the approach, and how to test it. I’ve seen PRs at the fintech startup where the description was better than the code, and that’s not an insult. Good context makes review ten times faster and ten times more useful.

Automate everything that isn’t judgment

Formatting, linting, type checking, test gates, dependency scanning . All of it should run before a human ever looks at the PR. Every minute a reviewer spends on something a machine could catch is a minute wasted.

Your reviewers’ attention is finite and expensive. Protect it.

Say when you can’t review properly

If you don’t have time to review something properly, say so. “I can’t get to this until tomorrow” is infinitely more useful than a rubber-stamp approval today. A fake review is worse than no review because it gives false confidence. At least with no review, everyone knows the risk.

Code review works when people treat it as the last chance to catch something before it hits production. Everything else is just counting approvals.

We Have No Security Team

Our fintech startup serves financial data to thousands of users. Eight engineers. No dedicated security person. No budget for one either.

But we handle user data, API keys, third-party integrations, and payment flows. The attack surface isn’t small. And everything I know from cyber-defense exercises confirms that “we’ll deal with security later” is how you end up in an incident report.

So I borrowed an idea from military operations: you don’t need every soldier to be a specialist. You need embedded people who know enough to spot danger and escalate fast.

That’s a security champion.

What a Security Champion Is

Not a security expert. Not a penetration tester. Just an engineer on the team who volunteers to keep security visible.

At the fintech startup, our champion was a backend developer with a natural paranoia about input validation. Perfect. I didn’t need him to write a threat model from scratch. I needed him to ask “where does this data come from?” during design discussions. To flag hardcoded credentials in PRs. To be the person other engineers felt comfortable asking basic security questions.

The role boils down to three things:

1. Ask the uncomfortable questions during design and code review. Not after. During.
2. Keep the basics visible. Auth, data handling, dependency updates , logging.
3. Escalate what’s beyond their depth. In our case, that meant escalating to me or to an external advisor we had on retainer for a few hours a month.

That’s it. Lightweight. High leverage.

Why This Works Better Than You’d Expect

Single points of failure kill you. This is a core lesson from cyber-defense exercises. If one person holds all the security knowledge, they become a bottleneck, and when they’re on vacation or quit, you’re blind. Champions spread awareness across the org. Security stops being one person’s job and becomes part of how the team thinks.

Context beats checklists. An external auditor can scan your code. But your champion knows that the team just shipped a new webhook endpoint last Thursday, that it accepts user-supplied URLs, and that nobody discussed SSRF. That contextual knowledge is worth more than any automated scan.

Culture shift happens from the inside. When the security voice comes from within the team instead of an outside compliance function, people listen differently. It stops feeling like an audit and starts feeling like engineering discipline. At the fintech startup, after a few months, engineers who weren’t champions started raising security concerns on their own. That’s when you know it’s working.

How to Set It Up

Let people volunteer. Draft picks don’t work here. The engineer who wants the role will actually do the work. The one who gets voluntold will treat it as overhead.

Give them real time. This is where most programs die. If security work sits on top of a full sprint, it won’t happen. We carved out a few hours per week. Not a lot. Enough to signal that leadership actually cares.

Train them, but practically. Skip the theory-heavy workshops. We ran short sessions: here’s how XSS works, here’s how to spot an insecure deserialization pattern in our stack, here’s what our threat model looks like for this feature. Hands-on, specific to our codebase, thirty minutes at a time.

Give them air cover. This is the one that matters most. If a champion pushes back on shipping an unsafe feature and gets overruled by a PM every time, the program is dead. Leadership has to back them up. I made it clear at the fintech startup: if the champion says “this needs a security review before it ships,” that’s what happens. No exceptions.

Make the work visible. If nobody sees the security work, nobody values it. Mention it in standups. Bring it up in performance reviews. Treat it as a real engineering contribution, because it is.

The Pushback You’ll Get

Engineers will say they’re not qualified. Good. That means they understand the limits of the role. Champions aren’t supposed to be experts. They’re supposed to spot obvious risks, ask questions, and know when to escalate. That’s a much lower bar than people think.

Engineers will say they don’t have time. They’re right, unless you give them time. Protect those hours.

Some people will question whether it actually helps. Point to the PR where a champion caught a SQL injection before it hit staging. Or the design review where someone asked “what happens if this JWT is expired but the signature is still valid?” and saved the team a week of debugging in production.

Scaling It

With eight engineers, one champion is enough. As the team grows, the model scales: one champion per team, a shared Slack channel for cross-team security questions, and a monthly sync where champions compare notes. Eventually, if you’re lucky enough to grow into needing a real security team, your champions become the connective tissue between that team and the rest of engineering. They already know the code, the people, and the history.

A Bridge to Real Security Investment

A security champion program doesn’t replace real security investment. It bridges to it. It gets a startup from “we have nothing” to “we have something real” without blowing the budget. It builds habits that stick. And it creates a culture where security is part of building software instead of a panic after a breach.

It works at the fintech startup because we have one engineer who gives a damn and leadership that backs him up. The process is far from perfect. Start there.

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.

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.

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.