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.

The most common pattern across Series B–D companies that quietly stalled in 2024–2025: somewhere between $1M and $3M of engineering and infra 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 — not 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 .

AI programs rarely fail because one team is incompetent. They fail because the organization tells itself three different stories about the same system. Engineers hear one version of reliability, executives hear one version of commercial impact, and investors hear one version of scale. By the time those stories collide in a board meeting, the disagreement has already been baked into the program. A CTO’s job is to keep the story true enough that people can act on it.

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.

The point is not to produce more slides. The point is to keep the story consistent enough that people can challenge it honestly.

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.

Key Takeaways

• AI programs fail when each audience hears a different success definition.
• Engineers, executives, and investors need different levels of detail, but they need the same core truth.
• Use a consistent communication rhythm so the story does not change every time the room changes.
• Keep asking what changed, what it affected, and what happens next until the answer is sharp enough to survive board scrutiny.

By mid-February 2026, the org question isn’t “should we have an AI team?” It’s “where does ownership live?” The best structures make evaluation, cost, and incident response someone’s job, not a shared worry. Most teams land on a hybrid: a small enabling platform group plus embedded delivery in product teams.

AI work has shifted from experiments to ongoing product and operations work. Most organizations that ship AI features have converged on a small set of structures. 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 focuses on structures that stay stable under real delivery pressure, not aspirational org charts.

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 a single pane of glass 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, not a side task. 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.

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 isn’t technology. It’s 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 Actually 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.

That’s the whole secret: clear ownership, reliable evaluation, and the discipline to maintain both. Everything else is detail.

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.

I’ve been pulled into three different “help us restructure after layoffs” conversations this year. The pattern is remarkably consistent. Company does layoffs in Q4 2022 or Q1 2023. The remaining engineers are spread thin. Ownership is unclear. Two or three critical systems now belong to nobody. Leadership decides a reorg will fix it.

It usually doesn’t. Not because reorgs are bad, but because they’re solving the wrong problem.

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 actually need isn’t new boxes on a chart. It’s 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.

The real talk

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.

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

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

Here is the thing I didn’t expect. Building the platform was the easy part. Getting people to use it? That 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.

Golden paths over mandates

We never mandated anything. I hate mandates. Instead, we built golden paths — 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 golden path 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 main. 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 with three product teams, it doesn’t scale. 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. Keep your users close, build for self-service, and make the right path the easy path. That’s the whole playbook.