Your engineering team just got faster.
Maybe you invested in CI/CD. Maybe you reorganized around smaller teams. Maybe AI-assisted development cut your cycle time in half (or more!).
Congratulations. You’ve just moved the bottleneck.
It’s not in engineering anymore. It’s downstream – in the space between what engineering can ship and what the business can absorb.
This is the problem nobody is talking about, and it’s about to get a lot worse.
The absorption problem
Here’s what it looks like in practice.
Engineering ships a major feature on Tuesday. Marketing didn’t know it was coming until Monday. Sales finds out from a customer who found it before they did. Support gets tickets about the new workflow with no documentation to reference. The CEO asks why the board deck from last week didn’t mention it.
Nobody did anything wrong. Engineering shipped fast. The pipeline worked. The deploy was clean.
But the business wasn’t ready. The change hit the market before the market – internal or external – could absorb it.
Now multiply this by AI.
If AI-assisted development doubles or triples engineering output over the next two years – and every indication says it will – the absorption gap doesn’t just grow. It compounds. More features, more changes, more deployments, all arriving faster than the organization around engineering can process them.
The current conversation about AI and software development is focused almost entirely on the wrong side of this equation. How do we make engineers faster? How do we use agents to write more code? How do we reduce cycle time?
Nobody is asking: faster for whom?
What the existing frameworks miss
The major frameworks in software delivery all share the same blind spot. They measure engineering from engineering’s perspective.
DORA tracks deployment frequency, lead time, change failure rate, and recovery time. These are valuable metrics and I recommend them to folks all the time. They tell you how fast and reliably you can push code to production. They tell you nothing about whether production was ready for what you pushed, or whether the business can do anything useful with it this quarter. Or even if you shipped the right thing to market.
Scrum gives you sprint velocity and story points. It tells you how much your team can produce in a two-week cycle. It doesn’t tell you whether the thing you produced at maximum velocity is aligned with what sales needs to close a deal next month or what marketing planned to announce at the conference in six weeks.
The Flow Framework connects value streams to business outcomes and measures the flow of features, defects, debt, and risk. It’s the closest thing to addressing the gap. But it was built for enterprise-scale digital transformation – Fortune 500 companies with thousands of engineers and complex toolchains. It requires specialized platforms to implement and is designed for organizations that have already achieved basic delivery competence.
DevOps solved deployment as a bottleneck. Before DevOps, getting code to production was painful, slow, and risky. DevOps fixed that. But DevOps assumed that if you could deploy continuously, the rest of the organization would figure out how to keep up.
It didn’t.
What every one of these frameworks optimizes for is the speed of the supply side – engineering’s ability to produce. None of them address the demand side – the business’s ability to absorb what engineering produces.
This is the structural gap. And it’s the next bottleneck for every software company that gets serious about engineering velocity.
Speed without alignment is useless
I learned this in the pre-AI days, in a career that most software engineers haven’t had.
Before I wrote code for a living, I was a professional sports journalist and newspaper production editor. I worked in daily newsrooms – environments where parallel, creative, high-stakes work shipped on a hard deadline every single day.
A daily newspaper is a remarkable coordination machine. Dozens of reporters work independently on stories. Photographers shoot and process images. The copy desk reviews everything for accuracy and clarity. Editors decide what makes the front page and what gets cut. The whole thing converges on a single press deadline, and the edition publishes.
Every day. Without fail. Without burning people out.
The newsroom didn’t achieve this through heroics or surveillance or micromanagement.
It achieved it through a workflow that separates the speed of production from the rate of publication.
Reporters work fast. The copy desk reviews at its own pace. Editors decide what’s ready for this edition and what holds for tomorrow. The press deadline creates a forcing function that stops work from expanding indefinitely.
Speed and alignment aren’t in tension. They’re decoupled. Reporters can move as fast as they want. The edition controls what the audience actually sees and when they see it.
This is the piece that software development is missing.
The coordination layer
In software, we’ve conflated two things that should be separate: engineering velocity and the rate of change to the market.
When you deploy continuously, every merge is a potential change to what customers experience. When you batch releases, you create the deployment bottleneck that DevOps was invented to eliminate.
The solution isn’t to slow down engineering or speed up the business. It’s to insert a coordination layer between them — one that lets engineering work at full speed while giving the business control over the rate of change.
The newsroom has had this layer for centuries. The editorial process – the meeting, the assignments, the independent work, the copy desk review, the edition – is a coordination mechanism that decouples production speed from publication cadence.
In software, this looks like:
Decomposition for independence. Work is broken down so engineers (or AI agents) can work in parallel without stepping on each other. In the newsroom, the city desk reporter doesn’t need to coordinate with the sports desk. In software, this means designing work so that it can be built, reviewed, and merged independently – then assembled into a coherent release.
Feature flags as pages. Just like a newspaper has sections and pages that can be composed into an edition, feature flags let you control what’s visible to users independently of what’s deployed. Engineering ships continuously. The business decides what goes live and when. Feature flags live at a higher level than each individual change, but at each market-releasable bundle.
Review as a cadence, not a gate. The copy desk doesn’t review every word before the reporter writes it. It reviews the finished work before it publishes. In software, this means code review and QA happen at the right altitude – catching what matters without becoming a bottleneck that negates the speed you just gained.
The edition as a forcing function. The press deadline isn’t arbitrary. It’s the mechanism that creates convergence. Work that’s ready ships. Work that isn’t holds for the next edition. This prevents the slow creep of scope and the “one more thing” that delays releases indefinitely.
Hard stops that create sustainability. The press runs. The edition publishes. People go home. In software, this means engineering speed doesn’t translate to midnight alarms and weekend firefighting. The workflow has natural stopping points.
Why now
This gap has always existed. High-performance software engineering teams have always been capable of moving faster than the business around it.
But three things are making it acute:
AI is compressing cycle time dramatically. When AI agents can produce working code in minutes instead of days, the volume of change that hits the system accelerates beyond what any existing coordination mechanism can handle. The teams that figure out the absorption problem first will pull ahead. The ones that don’t will drown in their own output.
PE-backed software companies can’t afford the chaos. Private equity firms acquiring B2B SaaS companies need engineering to deliver measurable value on a compressed timeline. They can’t wait for organic alignment to develop between engineering and go-to-market. They need a framework that creates it deliberately, from day one.
The “just ship it” era is ending. For a decade, the dominant advice was to move fast and break things. But breaking things has real costs – customer churn, support load, sales friction, brand damage. As markets mature and competition intensifies, the companies that win aren’t the ones that ship the most stuff the fastest. They’re the ones that ship the fastest in the right direction, at the right time, with the business ready to capitalize on what shipped.
Editorial
I’ve been building and refining this framework across two decades of engineering leadership and a consulting practice focused on B2B SaaS delivery transformation.
I call it Editorial because it comes directly from the publishing workflow that newsrooms have used for centuries – adapted for software development, tested in real engineering teams, and designed for the AI-accelerated era we’re entering.
Editorial is organized around three pillars:
Alignment: Because code is useless unless it gets used. This is the set of principles that connect engineering output to business outcomes: making engineering work visible to non-technical stakeholders, getting engineers closer to customers, and ensuring that context flows in both directions.
Speed: Because fearless engineers are fast engineers. This is the set of principles that remove friction from the building process: killing estimation theater, giving engineers problems instead of solutions, learning from every deployment, and choosing boring solutions over clever ones.
Safety: Because speed without safety is reckless. This is the set of principles that make fast deployment sustainable: managing blast radius, deploying when risk is lowest, putting quality ownership where it belongs, and building trust through incident response.
Each principle is composable. You don’t need all of them. You don’t need to do them in order. You don’t need a two-day training course or a certification.
Start with the one that addresses your biggest pain point. See results. Add another when you’re ready.
The framework emerges from the practice, not the other way around.
The choice
Every software company is going to face this decision in the next few years.
You can keep optimizing engineering speed and hope the rest of the organization figures out how to keep up.
You can add more process – more meetings, more status reports, more approval gates – and watch the speed you just gained disappear into coordination overhead.
Or you can adopt a coordination layer that decouples engineering velocity from the rate of change to the market – one that lets engineering work at full capacity while giving the business control over what ships, when, and to whom.
The newsroom solved this problem a long time ago.
It’s time software caught up.
I’m Chris Vannoy, founder of Axiomatic, a delivery transformation consultancy for PE-backed B2B SaaS companies. I help engineering teams ship fast, safe, and aligned. Learn more about Editorial or work with me.