Skip to content

Editorial

Engineering is getting faster. The business isn’t.

Every framework in software development is obsessed with the same thing: making engineering move quicker. DORA metrics. Sprint velocity. Deployment frequency. Cycle time.

It’s working. AI is accelerating it further. Engineers can ship more code, faster, than at any point in history.

And it’s creating a problem nobody has named yet.

When engineering moves faster than the business can absorb the change, speed becomes a liability. Features ship that sales can’t sell yet. Releases land that support can’t support yet. Deployments happen that customers can’t adopt yet.

The bottleneck isn’t in the code anymore. It’s in the space between engineering and the market.

Every existing framework misses this. DORA measures how fast you deploy. It doesn’t measure whether anyone was ready for what you deployed. Scrum gives you velocity. It doesn’t tell you whether velocity is pointed at something the business can use this quarter. DevOps gives you continuous delivery. It doesn’t ask whether continuous delivery is what your customers, your sales team, or your board actually need right now.

Editorial is the framework for the gap between engineering speed and business absorption.

It comes from an unlikely place: the daily newspaper. Newsrooms have coordinated fast, parallel, high-stakes creative work under hard deadlines for centuries — publishing every single day without burning people out and without shipping the wrong thing.

I spent years in that system before I wrote a line of code. Then I spent two decades in software engineering leadership, watching teams struggle with a coordination problem that newsrooms solved a long time ago.

Editorial is a set of composable principles organized around three pillars – Alignment, Speed, and Safety – that let engineering work at full capacity while giving the business control over the rate of change to the market.

It’s not a methodology. There’s no certification. You don’t need to adopt all of it, and you don’t need to do it in order.

Start with one principle. See results. Add another when it makes sense.

This is the alternative to agile theater – and to the emerging chaos of AI-accelerated development without a coordination layer.

For the full case – including why AI makes this urgent and what every existing framework misses – read The Next Bottleneck.


Principles

Alignment

Because code is useless unless it gets used

Shipping Department News – Weekly updates that connect engineering work to business outcomes. Prevents expectation mismatches before they become problems.

Everyone Should Talk to Customers – Including engineers. Especially engineers. Direct feedback loops prevent building the wrong thing.

The Feedback Iceberg – Most feedback arrives too late to matter. Get closer to the source.

Context Is Everything – Engineers want to work on things that matter. Help them see how their work impacts the business and customers.

Speed

Because fearless engineers are fast engineers

The Estimation Death Spiral – Stop performing accuracy theater. Estimates are guesses. Treat them accordingly.

Add Retrospectives to Your Arsenal – Fast teams learn from every deployment. Slow teams repeat mistakes.

Start With the Problem – Give engineers problems to solve, not solutions to implement. Ownership drives speed and quality.

Boring Beats Clever (coming soon) – Prefer boring solutions over novel ones. Boring code is fast to write, fast to review, fast to debug, and fast to maintain.

Safety

Because speed without safety is just a different way to fail

Fridays Are the Safest Day for Deployments – If you’re afraid to deploy on Friday, you don’t have a deployment problem. You have a safety problem.

Save QA for When the Fall is Deadly – Engineers own quality. Add safety nets when the stakes truly demand it, not before.

Mind the Blast Radius – Define your risk tolerance. Ship changes that match it.

If You Break It, You Fix It (coming soon) – Ownership doesn’t stop at code review. Build trust through top-notch incident response.


In the wild

Editorial principles are already working in real engineering teams.

Shipping Department News, two weeks in:

“Unrelated, but thanks again for the Shipping Department News idea. In our second week doing it, we’ve already improved how engineering communicates to the business side plus we found a couple of cases where we weren’t communicating status well within engineering.”

A reader implemented just one Editorial principle – weekly updates connecting engineering work to business outcomes. Within two weeks, they saw improvements in two directions: engineering-to-business communication (the intended goal) and engineering-to-engineering communication (an unexpected bonus).

That’s how Editorial works. Start with one principle. See immediate results. Discover it improves things you didn’t even know needed fixing.


This is what I do

Axiomatic Founder, Chris Vannoy - a middle aged dude in glasses - leans over a desk with a laptop computer, a coffee mug and a red notebook. There are plants. He's wearing a blue blazer over a striped shirt.

I’m Chris, and I founded Axiomatic – a delivery transformation consultancy for B2B SaaS companies whose engineering teams are stuck.

I’ve spent two decades in engineering leadership roles, watching teams drown in agile theater while shipping slowly or recklessly. I’ve seen PE rollups that can’t deploy. I’ve seen startups stuck in three-week release cycles. I’ve seen teams ship fast but misaligned, building the wrong things efficiently.

Editorial is what I teach when I embed with engineering teams for 90 days to fix delivery dysfunction. These aren’t theories – they’re the principles that move teams from 3-week deploy cycles to 2-week sprints, or help companies deploy more in one quarter than they did in the previous two combined.

Every principle here is field-tested. Most companies start with one or two and see immediate results.

I wrote about how a career in daily newspaper production led to Editorial – and why the absorption problem is about to get a lot worse – in The Next Bottleneck.

Want help implementing Editorial at your company? Work with me


Start anywhere

Unlike Scrum (“do all of it or you’re not doing Scrum”), Editorial principles are modular. Each one works independently AND reinforces the others.

  • Start with Shipping Department News and watch communication improve in both directions.
  • Start with Blast Radius and realize you need better visibility into what you’re shipping.
  • Start with “Everyone Should Talk to Customers” and discover you need better context for your team.

The framework emerges from the teaching, not the other way around.

Pick one principle that solves your biggest pain point today. Ship it. See results. Add another when you’re ready.

That’s how Editorial works.