In the beginning, there was nothing. And a programmer said “Let there be software.” And there was still nothing, until Operations decided to deploy it.
That, more or less, was first gear. And the problem with first gear was that it was a clutchy affair. Two disciplines living in different worlds. Development cared about shipping features. Operations cared about keeping things stable. More than different priorities, they were different value systems with different incentives, different vocabularies, and often different reporting lines. Development was rewarded for change. Operations was rewarded for predictability. Both were doing their jobs well, and the result was still a mess.
Second gear came in the form of DevOps, which at its core was a cultural argument: these disciplines need to share ownership. Build it and run it. Understand what happens to your code after it leaves your laptop. Care about reliability if you’re a developer, care about velocity if you’re in operations. The tooling followed, CI/CD pipelines and infrastructure as code and automated testing, but the tooling was in service of a more fundamental idea: that the barrier between building software and operating it was organizational, not technical.
The Second Gear Plateau
Back in 2018, Forsgren, Humble and Kim published Accelerate, making the case that software delivery performance is measurable and predictive. Organizations that deploy frequently, with short lead times, low failure rates, and fast recovery times outperform their peers as businesses. The research gave us a vocabulary for something practitioners had always felt but couldn’t prove: the speed and reliability of getting code from idea to production is a competitive advantage.
Five years later, the findings hold up, but the landscape they described has shifted. DevOps was supposed to be a culture. A set of principles about collaboration, automation, and shared ownership. Then organizations turned it into a role, a team, and eventually a department. The same thing we saw happen with agile, where cultural shifts get absorbed into the org chart and lose their edge.
A financial services client I worked with had gone all-in on DevOps. Every team owned their CI/CD pipeline, their infrastructure as code, their observability stack. They were autonomous to a large degree. They were also spending roughly 30% of their engineering capacity on platform concerns that had nothing to do with the product they were building. Configuring build pipelines, debugging deployment scripts, figuring out why their monitoring disagreed with the team next door about whether the system was healthy. The same scaffolding, rebuilt slightly differently forty times over.
By the measures that Accelerate described, this client had high autonomy but low flow. Which brings us to the core of the problem.
Flow and Friction
Flow is the ability to move an idea from concept to production without unnecessary waiting, rework, or ceremony. Developers spending their time on the actual problem rather than on the machinery around it. Friction is whatever disrupts that flow; it can be deliberate or accidental.
- Deliberate friction is worth keeping. Code reviews, security scans, architecture review for a critical system. These exist to protect quality, and removing them in the name of speed is how you end up with excessive technical debt.
- Accidental friction is the stuff nobody designed and nobody owns. A three-day wait for an environment because provisioning requires a ticket and two approvals. A week lost debugging a deployment pipeline that another team solved six months ago and never documented. Rebuilding the same observability setup for the fourth time because there’s no shared standard. None of this produces value. It just burns capacity and morale, quietly, every sprint
Not long ago, the source of accidental friction was a result of manual processes, siloed teams, and heavyweight change management. Those still exist. But a new category crept in: the overhead of distributed autonomy itself. Every team choosing their own everything created coordination friction that looks different from bureaucratic friction but has the same effect. It slows you down in ways that are hard to see until you add up the hours.
Shifting Into Third
Platform engineering emerged as the response, and in many ways it works. Build an internal developer platform that handles the repetitive infrastructure concerns, encode the organization’s opinions about how deployments and environments and observability should work, and let product teams focus on the thing they were actually hired to do. In Accelerate’s terms, this is the loosely coupled architecture the research said mattered most, applied to the developer experience rather than just the application design.
Organizations doing this well treat the platform as a product that completes with the roll-your-own ways of working. They platform has a direction, a roadmap, and prioritize features to increase adoption by development teams. They pay attention when developers route around the platform, because that’s feedback about where the platform falls short, rather than just seeing it as a compliance problem.
That’s third gear. And third gear is a real improvement. But it’s also where many organizations are coasting.
A recent client went through three iterations of their internal platform before it worked. The first two were designed by an infrastructure team that knew what developers should need, instead of watching what developers actually struggled with. The third version started from observing where teams lost the most time, which turned out to be environment provisioning and deployment configuration. So the platform team built exactly two things: a self-service environment tool and a standardized deployment pipeline with sensible defaults that teams could override. Adoption followed, because the platform removed friction that people felt every single day.
So What’s the Fourth Gear?
There’s a reason this question is coming up now. Organizations trying to operationalize AI realize that they need somewhere to put it. Model serving, data pipelines, evaluation framework, and so on. The infrastructure requirements for AI in production are significant, and they’re landing on teams that were already stretched thin by platform concerns.
The organizations that built coherent platforms before the AI wave have a foundation to extend. Everyone else is bolting AI infrastructure onto existing sprawl, which is how you end up with the kind of architectural debt we’ve been writing invoices for since the pandemic.
But even beyond AI, there’s a broader challenge. Most internal platforms were still designed around the deployment lifecycle: get code from a repository to a running environment efficiently. Fourth gear means extending that thinking to the full development lifecycle, including how teams discover existing capabilities, how they share patterns, how they collaborate across product boundaries without creating the coordination overhead that platforms were supposed to eliminate. The deployment pipeline is solved, or at least solvable. The cognitive load on developers is not, and that’s where the next real gains are hiding.
Platform engineering gave us the organizational pattern to improve delivery performance. The next question is whether we can extend that thinking beyond infrastructure and into how software-enabled organizations learn and adapt, because that’s where the engine has more to give.
In the meantime, third gear beats second. And second gear certainly beats first. But if you’ve been cruising in third for a while and wondering why everything still feels slow, maybe it’s time to look at the gearbox.
