Why Your Competitors Are Always One Step Ahead
The answer has nothing to do with their strategy, their budget, or their people.
You have good people. A credible strategy. You are not standing still.
And yet somehow, your competitors always seem to be one step ahead. You launch a feature : they already have it. You cut a price and they had already cut it. You announce an initiative and they are six months into delivery. The gap never closes. If anything, it widens.
Most leaders in this position look for the problem in the wrong places. The strategy. The talent. The technology. But the organisations consistently winning shoot-outs are not winning because of superior ideas. They are winning because they can move those ideas to customers faster than anyone else, and they have been building that capability for decades.
This is not a technology story. It is a story about how organisations are designed.
Toyota figured this out first
Not just on the factory floor. In every process, every approval gate, every handoff, every decision sitting in a queue waiting for the right meeting. Toyota didn’t win by building better cars in isolation. They won by building an organisation that could respond to what customers actually wanted, faster than any competitor could react.
The lesson Western manufacturing took decades to absorb, and most industries still have not absorbed, is that speed is not the output of a good strategy. Speed is the output of a well-designed operating model. You cannot will your way to faster. You have to build for it.
Jim McCarthy understood this when he ran the Visual C++ team at Microsoft in the 1990s. His observation about competitive markets was blunt: when you are in a shoot-out, the organisation that ships faster wins. Not the one with the better roadmap or the bigger budget. The one that gets working product in front of customers more frequently learns faster, corrects faster, and compounds that advantage with every single release.
No one ever asked Amazon to ship slower and charge more
Amazon understands something that most organisations pay lip service to but never fully operationalise: customers are never truly satisfied. Not because they are difficult, but because expectations only ever move in one direction. The experience that delights someone today becomes the minimum they expect tomorrow.
When I was at AWS teaching customers about working backwards, I would share the “delightfully dissatisfied” customer analogy. No customer has ever called Amazon and asked for same day delivery to be slower and more expensive. Customer expectations only move in one direction, and Amazon designs its entire operating model around that reality.
No customer has ever called Amazon asking them to slow down and charge more. That sounds obvious. But walk through your own organisation and ask honestly: how many of your internal processes, approval structures, and governance frameworks were designed around the assumption that speed matters as much as control? Or were they designed to manage risk at the expense of everything else?
That orientation toward the customer is only sustainable if your operating model can actually respond. If it takes six months to change a product, three months to launch a feature, and four approval layers to move budget between teams, you cannot be customer-obsessed. You can only be intention-obsessed. Which is a very different thing, and it shows up in the results.
Amazon had the same problem you have
Here is where I want to push back on the most common thing I hear from senior leaders: *we’re not Amazon, we can’t operate like that.*
Let me tell you where Amazon actually started.
In the early 2000s, Amazon.com ran on a single system called Obidos, a monolith that every engineer in the company was touching, and that every customer transaction ran through. Around a hundred engineers, all working on the same piece of code. A single mistake by one team could bring the entire site down. Their own internal research found it was taking an average of 16 days to get a change from idea to customer, with less than an hour of actual work involved. The remaining 14 days was pure organisational drag. Queues. Handoffs. Waiting for approvals. Coordination overhead between teams who all depended on each other.
Sound familiar?
Amazon fixed it, not by hiring better engineers, but by redesigning how the organisation worked. Smaller teams with genuine end-to-end ownership. No shared infrastructure that created invisible dependencies between groups. Every team accountable for its piece from concept to customer. The microservices architecture invented by James Lewis at ThoughtWorks and scaled by AWS was not primarily a technology decision. It was an operating model decision that happened to have technical consequences.
The constraint was never the technology. It was always the organisation.
The AI trap most leaders are about to walk into
Right now, every board in the country is asking the same question: how do we move faster on AI?
And most organisations are answering it the same way they answered “how do we move faster on cloud” a decade ago, by buying tools, standing up a centre of excellence, and placing the initiative alongside the existing business rather than changing how the business actually operates.
The organisations that will win the AI shoot-out are not the ones with the most sophisticated models. They are the ones that can get AI-driven improvements in front of customers the fastest, learn what works, and iterate before the competition has finished their business case.
That requires the same operating model discipline that Toyota was teaching in the 1960s and that Amazon has been compounding ever since. AI does not change this equation. It accelerates it. The organisations that already had the discipline to move fast are now moving faster still. The ones that didn’t are watching competitors do in weeks what used to take them quarters, with the same headcount and a fraction of the drag.
The DORA research, a decade of data across tens of thousands of organisations, led by Jez Humble, Nicole Forsgren, and Gene Kim, found a direct and measurable correlation between how frequently an organisation can ship and its financial performance. Revenue growth. Market share. Profitability. The top performers outperformed their peers on every business metric that mattered.
Speed is not a nice-to-have. It is a compounding financial advantage. And it is almost entirely a leadership and organisational design problem.
The question worth taking into your next leadership meeting
In March 2018, I sat in front of the board of AMBank in Kuala Lumpur and made a version of this argument. The response was the same one I see consistently when senior leaders genuinely engage with it: recognition, followed quickly by the uncomfortable realisation that the constraint is not somewhere else in the organisation.
It is in the room.
Shipping speed is not an engineering metric. It is a business performance metric. And it is almost entirely determined by how your leadership team has designed the organisation: how teams are structured, how decisions are made, how budgets are approved, how risk is managed, and how much of your best people’s energy goes into coordination rather than creation.
If your most important strategic initiative needed to change course tomorrow based on what customers told you today, how long would it actually take?
If the honest answer is months, the problem is not your technology. It is not your people. It is the operating model that has been quietly compounding the gap between you and the competitor who always seems to be one step ahead.
Only your leadership team built that model. Only your leadership team can fix it.
Bruce McLeod has spent 30 years inside the gap between how organisations say they work and how they actually do, across ThoughtWorks, Amazon Web Services, and now as Practice Leader at Datacom Australia. He advises senior leaders on operating model design, AI-augmented delivery, and the decisions that determine whether transformation actually sticks.