Automation First: Why Speed is Your New Competitive Advantage

Back in 2011, an engineering director at Amazon named Jon Jenkins told a conference how often his company shipped new code to customers. On an average weekday, Amazon deployed to production every 11.6 seconds. Not every quarter. Not every sprint. Every 11.6 seconds.¹

Now picture the company Amazon was competing against. That company shipped software four times a year. Its release weekends were all-hands events with a runbook, a war room, and a prayer. When something broke, and something always broke, it took days to find and fix.

Most people read that comparison as a story about engineering. It is not. It is a story about how fast a whole company can learn. Amazon was finding out what customers wanted, correcting mistakes, and turning ideas into value faster than its competitor could hold a planning meeting. That speed did not stop at the code. It ran through how the company designed products, set prices, tested offers, and served customers. The competitor was not slow because its engineers were slow. It was slow because everything the business learned, it learned late.

Faster learning is the real advantage automation buys you. And most companies never collect it, because they buy automation to cut costs and stop there.

Automation is a learning machine, not a cost-cutting tool

Walk into most budget conversations and automation gets pitched as a way to save money. Fewer manual steps, fewer people to run a process, lower operating cost. All true. All beside the point.

The strategic value of automation is that it makes learning faster. Every part of a company runs the same loop: have an idea, act on it, find out whether it worked, adjust. A product team runs it on a new feature. Marketing runs it on a campaign, finance on the monthly close. Automation shrinks the time that loop takes, wherever it runs. Go from an idea to a real answer in a day instead of a quarter and you get more attempts, with the answer arriving while the idea is still fresh. Compound that over a year and the gap between you and a slower competitor stops being a gap. It becomes a canyon.

Software delivery is simply the place this is easiest to measure, so start there for the numbers. The clearest evidence comes from DORA, short for DevOps Research and Assessment, a long-running study now run by Google Cloud that has surveyed tens of thousands of technology professionals.² DORA tracks four numbers that, together, describe how fast and how safely a team ships: how often it deploys, how long a change takes to reach production, how often a change breaks something, and how quickly it recovers when something does break. The best performers deploy on demand, get a change to production in under a day, break things on fewer than one in twenty deploys, and recover in under an hour. As of the 2024 report, only about 19 percent of teams hit that bar.

Read those four numbers again, because there is a myth hiding inside them. The myth is that you trade speed for safety, that going faster means breaking more. The data says the opposite. The best performers are not fast and reckless. They are fast and stable at the same time, and the thing that lets them do both is automation. Automated tests catch the mistake before a customer ever sees it. Automated deploys strip out the human error behind most outages. And fast feedback tells you within minutes, not weeks, when something is off.

The payoff is not theoretical, and it is not confined to the engineering budget. The research behind these metrics found that the best performers were twice as likely to exceed their goals for profitability, market share, and productivity.³ Separate work by McKinsey found the same thing from the executive seat: companies in the top tier of software delivery grew revenue several times faster than the bottom tier.⁴

Speed of learning shows up on the income statement, not just the release calendar.

It starts at the drawing board

The biggest returns from automation come before a line of code is written, back when you are still deciding what to build at all. Most of those decisions are wrong, and that is the uncomfortable part.

Ronny Kohavi, who built and ran the experimentation systems at Microsoft’s Bing search engine and is one of the most cited voices in the field, has reported that even among carefully designed experiments meant to improve a specific metric, only about one in three actually do.⁵ Two out of three ideas that smart people were confident about did nothing, or made things worse. If that is the hit rate on your best bets, the only way to win is to make a lot of cheap bets and find the truth fast.

Booking.com does exactly that, running more than a thousand experiments at once on its live site.⁶ Those tests are not just code. They are copy, layout, price, and offer, which means design and marketing are being tested as fast as the software. You cannot run a thousand experiments through a committee and a quarterly review. You can only do it when standing up a test takes minutes and the results come back in hours.

The same approach works on a product that does not exist yet. A team that can put a rough concept, a fake landing page, or three price points in front of real customers this week finds out which direction is viable, instead of debating it for a quarter. That is automation applied to discovery, and it is where the highest-paid person in the room stops being the one who decides by guessing.

Building it

Once you know what to build, the automation that carries it to customers rests on three capabilities, and none of them delivers much alone. Start with the safety net, because it is the one people skip. Automated testing checks every change and catches the break before it reaches a customer, and without it the other two are dangerous. Then there is the pipeline that carries a change from someone’s idea out to the real world without a person babysitting every step. And underneath both, fast feedback: quick, honest measurement of whether the thing you just shipped is helping or hurting. Pull any one of the three and the others wobble.

Software teams have pushed this furthest, and the examples are worth borrowing. Netflix deploys thousands of times a day with no central quality-assurance team signing off on releases, and it runs a now-famous tool that deliberately shuts down its own servers in production to prove the system can survive the failure.⁷ Failure stopped being an event and became background noise the system routes around.

For a skeptical executive, HP is the case that sticks. Its LaserJet firmware group was drowning. Around 2008, roughly 80 to 90 percent of its engineering capacity went into just moving old code onto new printers, with almost nothing left for new features. The team rebuilt the whole operation around automated builds, automated testing, and a continuous pipeline. Cost per program dropped by close to 78 percent. More important, the share of engineering time spent on genuine innovation went up roughly eightfold.⁸ Automation did not just make the old work cheaper. It bought back the capacity to do new work.

The shape is not unique to code. A marketing team that can launch a campaign, watch the numbers, and pull it back the same day has the same three capabilities at work. So does an operations team that can change a fulfillment rule, see the effect on a live dashboard, and reverse it if the numbers turn. The tools are different. The pattern is identical.

Running it by hand is a tax you are already paying

Every manual process in the chain is a tax. You do not see it as a line item, which is exactly why it is dangerous.

Part of the bill is visible if you go looking. The Consortium for Information and Software Quality, an industry group that studies software cost, estimated that poor software quality cost the United States 2.41 trillion dollars in 2022.⁹ A large chunk of that is the cost of finding and fixing defects that automation would have caught earlier, when they were cheap.

Inside a team, the tax shows up as toil, the manual, repetitive work that keeps the lights on but builds nothing new. Engineers at Google measured it directly and found they spent about a third of their time on toil on average, and Google now treats crossing 50 percent as a problem to be fixed, because past that line a person stops building and starts babysitting.¹⁰ The principle is worth stealing word for word: reducing toil is engineering work, not a chore you squeeze in later. The same tax shows up everywhere else, too. It is the finance team hand-keying the monthly close, the support team retyping the same answer for the hundredth time, the marketer copying numbers between three tools, and the knowledge worker losing an hour hunting for a file a better system would have handed them.¹¹

Capital One shows what it looks like to pay the tax down on purpose. The company decided to become a technology company that happens to do banking, exited its data centers by 2020, and rebuilt on automated cloud infrastructure. Over a few years, it increased how often it changed its applications by more than 300 percent, while cutting transaction errors and the time to resolve critical incidents by roughly half.¹² The whole business got faster, not just the engineers.

Building an automation-first culture without new bureaucracy

None of this sticks if you turn it into a program with a steering committee. Automation culture is not a mandate. It is a default, and defaults are built one small decision at a time.

The simplest rule that works: if you do something twice, automate it the third time, or decide out loud that you are choosing to keep doing it by hand. The first time is fine. The second time is a signal. The third time is a choice, and most teams make that choice by accident and pay for it for years.

Culture also decides whether automation takes hold, and the deciding factor is safety. Teams that feel safe embrace automation, because a failed automated step is something to learn from. Teams running on fear resist it, because any failure is a reason to be blamed, so it feels safer to keep control and do everything slowly by hand. I have watched capable teams quietly choose the slow, manual path because the fast one felt risky. No tool fixes that. Only safety does.

This is also where AI enters, and where a lot of leaders are about to make an expensive mistake. The 2025 DORA report found that teams using AI now ship more and build better products, but that AI still hurts stability. Its own summary put it plainly: AI amplifies what is already there.¹³ Point AI at a team with strong automation and fast feedback and it makes a strong team faster. Point it at a team pushing unchecked work into a fragile manual process and it helps them make mistakes at a speed they have never managed before. AI is not a shortcut around the fundamentals. It is a multiplier on whatever you already have.

So the work this quarter is concrete, and small enough to actually start. Pick one function, anywhere in the lifecycle, not the whole company. Measure how long its core learning loop really takes, from idea to knowing whether the idea worked, even if the honest answer is embarrassing. Automate the manual step your team dreads most, not the easy one. Take a decision you are about to make on gut feel and turn it into a small experiment instead. And before you let AI accelerate anything, ask whether the thing it is accelerating is one you would actually want to go faster.

The gap is learning, not code

Go back to those two companies. One deploying every 11.6 seconds, the other four times a year. The distance between them was never really about how fast code moved. It was about how fast the whole organization learned, corrected, and turned an idea into something a customer valued. That distance runs from the first design sketch to the running service, through every function that touches the work.

The gap is still the game, and it is wider now, because the tools to close it are cheaper and better than ever, and just as cheap for a competitor to use against you. Automation is how you decide which side of the gap you are on. The only question that matters is whether you will build the machinery to learn faster than your market changes, or keep paying the tax until the market decides for you.

Notes

1. Jon Jenkins, “Velocity Culture,” O’Reilly Velocity Conference, 2011. ↩

2. DORA (DevOps Research and Assessment), now part of Google Cloud; benchmarks from the 2024 Accelerate State of DevOps Report. ↩

3. Nicole Forsgren, Jez Humble, and Gene Kim, Accelerate: The Science of Lean Software and DevOps (IT Revolution, 2018). ↩

4. McKinsey & Company, “Developer Velocity: How software excellence fuels business performance,” 2020. ↩

5. Ronny Kohavi and Stefan Thomke, “The Surprising Power of Online Experiments,” Harvard Business Review, 2017. ↩

6. Kaufman et al., “Democratizing online controlled experiments at Booking.com,” 2017. ↩

7. Netflix Technology Blog, on continuous delivery and the Simian Army / Chaos Monkey. ↩

8. Gary Gruver, Mike Young, and Pat Fulghum, A Practical Approach to Large-Scale Agile Development: How HP Transformed LaserJet FutureSmart Firmware (Addison-Wesley, 2012). ↩

9. Consortium for Information and Software Quality (CISQ), “The Cost of Poor Software Quality in the US: A 2022 Report.” ↩

10. Site Reliability Engineering: How Google Runs Production Systems (O’Reilly, 2016), chapter on eliminating toil. ↩

11. McKinsey Global Institute, “The social economy: Unlocking value and productivity through social technologies,” 2012. ↩

12. Amazon Web Services, Capital One case study, 2020. ↩

13. 2025 DORA Report (State of AI-Assisted Software Development), Google Cloud, 2025. ↩