Has Your DevOps Revolution Hit a Wall?

In most companies, 1 in 10 developers devote all of their time to deploying code that’s already written. That means a midsize company spends about $6 million per year just on headcount for deployment.

That’s a problem. And it’s confusing because, for the past decade, developers have absolutely nailed the process of writing quality code quickly. And infrastructure teams have nailed quickly provisioning things. Yet either one person still dedicates themselves to deploying it, or each developer spends 20-30 percent of their time on so-called “delivery-related toil,” because they’re missing a fully mature DevOps implementation to tie it all together.

In these companies, the writing, provisioning, and deploying of software are separated. Instead, they ought to be tightly intertwined, as they are at top organizations within Meta, Amazon, and Google. 

But there’s good news: Modern DevOps is attainable to all. It’s never too late and no implementation is ever unsalvageable. The journey is a continuum, and you just have to keep moving up the curve to maturity.

If you’re going through DevOps hell, keep going

In most companies, DevOps is deployed with great expectations. DevOps have to meet expectations of speed, scalability, security, and out-innovating competitors. But somewhere along the way, something gets lost.

All those time-saving, developer-delighting, security-ensuring practices actually conspire to create more work.

Perhaps people focus so heavily on the tools and so lightly on the culture that the old culture has prevailed, and now workflow looks and acts suspiciously like a waterfall, with all its attendant downsides.

Or perhaps DevOps ideas about stewardship and direct accountability crashed into an old, hierarchical command and control culture, and lost the fight. Now people wait for orders, and they don’t act until they get a response. Maybe a lack of agreement on metrics has set developers and DevOps at odds. After all, if developers are measured on releases and DevOps is measured on things not breaking, conflict must ensue.

Here’s the thing. These aren’t signs of a failed DevOps deployment. They’re the signs of an incomplete DevOps deployment. It may mean that you’re just halfway there and not seeing the effects yet. And, without too much additional effort, you could.

And if you want to save time, the right, purpose-built software tools can help you get there.

Opinionated tooling can help you transform faster

There’s no question that in the mnemonic “people, process, and technology,” things matter in exactly that order. But what about when technology can institute processes and educate people? 

If your organization is focused on adopting cutting-edge DevOps tools, which have the right guardrails, practices, and safeguards already encoded within, they can leapfrog years of painful experimentation. Just the same way countries that were late to build out their information networks skipped copper cables and leapt straight to fiber optics.

A developer doesn’t need to know which tests to run if those tests are determined for them by machine learning (ML). (And automatically rearranged in the order of importance, to suss out errors sooner.) And they don’t have to guess and stress about how deployment pipelines are built. It’s already set up. In this convention, the best way becomes the only way for people to do things.

This is how companies still mired in a waterfall of tests by people can move to zero-touch and zero-trust deployments. 

It’s how a company racking up outrageous cloud costs, which has had to hire a cloud governance team, can repurpose those people and time. Rather than relying on people around the globe to shut off unused resources, it’s built into the system. (See: Policy As Code.) Now, those individuals can stop pausing shipments to assess the cost impact, and move on to higher-order optimizations. 

Software tooling is how teams can roll back only the pieces of deployments that failed, not everything. And because that’s quicker, the fixes are quicker, and they’re better able to reincorporate those learnings back into their pipeline. 

Lots of legacy organizations attempt this by developing their own internal tooling. But per Conway’s Law, that tooling can only ever be a reflection of their internal, immature processes. Plus, these tools are often limited and team-specific, and only make cross-departmental coordination or scale even more difficult. Whereas a standard tool or suite of tools, built by an organization steeped in best practices and enriched by consistent feedback from top DevOps teams, tends to be more effective.

If you adopt the proper tooling, you still need strong people and culture. There’s no getting around that. But it’ll help you augment everyone to work faster and with greater confidence. Plus, it creates a better developer experience (DX), which feeds the virtuous cycle of being able to attract even better developers and continue to increase your DevOps maturity.

The DevOps maturity curve

That brings us to the maturity curve. The Cloud Native Computing Foundation (CNCF) has developed the Cloud Native Maturity Model, and we’ve lightly adopted it here to work for DevOps maturity. We do recognize that the CNCF project is open source, and something short of fully authoritative, but we think it has a great foundation. Our curve uses the same five-level framework.

Per Conway’s Law, software tooling can only ever be a reflection of internal, immature processes.

As a company ascends the maturity curve, it achieves more of the vision of DevOps. At the low order, it may have only a temporary DevOps team that simply acts as a go-between to connect longstanding development and operations teams. At the higher order, that DevOps team becomes a full organization, and perhaps one day, melts away, when its purpose is achieved and DevOps becomes a way of existence. 

Implemented fully, DevOps no longer slows things down and adds complication. It speeds things up and simplifies. The system provides constructive guardrails by restricting access and templating pipelines such that developers can move faster knowing that anything they can do is compliant, tested, and safe. And all the other teams can trust that if a wrong thing were to go into production, it’d be rolled back automatically, piecemeal, and get addressed. (As opposed to an immature environment where you don’t actually know what’s broken.)

The question for you is, where are you today? And what does the curve recommend next?

Realizing the full promise of DevOps

As you achieve greater maturity, your business becomes more efficient. Your “idea to production pipeline” allows you to launch updates and features faster, and that, in turn, makes your business more competitive. 

When acting on updates is quicker and cheaper, everyone in the business is freer to respond to the market. To test. To react. To out-compete. To easily tie development back to the company’s goals, like scaling to one million users, or launching apps faster than competitors. It also has a wonderful impact on recruitment. 

Good DevOps is synonymous with a good developer experience. When DevOps isn’t a bottleneck, when 1 in 10 employees needn’t spend all their time deploying others’ code, you become a more attractive technical employer. And that becomes a positive cycle that sustains itself.

So, if you’re feeling like the DevOps revolution has hit a wall at your company, know that it’s not because it’s failed. It hasn’t. It’s only incomplete.