The DevOps community is running on fumes and at the lowest point in mindshare and interest that it’s ever been at. This is stupid. The practices, tools, and mindset of DevOps are vital to how most organization run their software1 and DevOps has improved the way the software we use everyday is built and run, improving all of our lives. If DevOps wasn't a thing, the world of software would be worse and each day would be a little more tedious because the apps we depend on would be worse. 

Here's what I think DevOps needs to do to come back from the dead:

(1) Steal back the flame from platform engineering

Developing software and building digital capabilities is becoming ever more complex. By 2026, 80% of large software engineering organizations will establish platform engineering teams as internal providers of reusable services, components and tools for application delivery - up from 45% in 2022. Gartner, circa 2024.

"Platform Engineering," is fine, but creating it as separate, new method of work has done a disservice to DevOps. Shoving DevOps into a grave was also a bit rude.

Platform engineering was a very well done marketing strategy to establish a new market for a handful of portal vendors to start working in. All of us joined the momentum of platform engineering. I have done it many times, and probably still will!

Much like The 12 Factor App, a piece of brilliant technical marketing, platform engineering has actually become its own, legit thing now. But, that early strategy of stealing the sun-light from DevOps made platform engineering seem like more than it is. Platform engineering is just DevOps with one small thing: adding in product management.

The rest of platform engineering is just adding new tools to the DevOps toolchain: primarily internal developer portals and all of the work and tooling that goes into making Kubernetes usable for developers. Over the next 12 months, platform engineering is going to take hold in "enterprises" (see Gartner prediction above), which is what I call large organizations that are not tech companies: you know, IT normies. There's early use here-and-there in enterprises,2 but not at the scale of DevOps, or even cloud native (you know, architecting your applications in containers).

The DevOps community has to take over, gobble up, or otherwise “ride” the platform engineering wave or get drowned by it, lost in the deep like some ancient city. It's too late to reverse the name. And, really, "platform" as a name is incredibly valuable and descriptive, and "platform engineer" is a fine synonym for "DevOps engineer."

The job title might even do a good job to clean house on what exactly a "DevOps engineer" is. This is the case with DevOps in general: it's become so dominate that “DevOps” has started to mean most anything, and everything related to building and running in-house applications. This is not good!

(2) DevOpsDays should be renamed to Platform Days 

When suggesting such a thing, one must always begin with praise.

The community-driven, global DevOpsDays organization is one of the most unique assets in the IT world. At the moment, there's nothing like it: a vendor-independent, volunteer-led organization focused on industry best practices that holds regional events to educate and enrich the community. 

Let me do some boosterism here:

1. Being vendor-independent is important for two reasons. First, it means the content is actually practical and "true" without the bias of a commercial agenda. Second, it means that all vendors feel comfortable sponsoring DevOpsDays. Vendors are incredibly important to the DevOps community. They're the ones who have funded its existence! If the overall community and DevOpsDays was owned by a single vendor or an oligopoly it wouldn't have been successful nor valuable. Vendors have an agenda to sell their products and their market category (people who sell on-premises software want to show buyers why private cloud is the best, people who sell public cloud software want to show buyers why on-premises software is better, people who have new tools of monitoring and log management want to explain to you why the old ways suck - shocker!). Vendor's budgets also come and go at the whim of their business, new technologies, and macro-economic headwinds. One year, the company is focused on growth at all costs to drive company valuation, the next year the company is focused on cutting costs because a PE firm bought them. One year, money is cheap, the next year money is scarce. One year, DevOps is important, the next year generative AI is important. Budgets shift! In short, depending on vendors to support an ongoing, multi-decade community is risky.

2. The volunteers are the ones, then, who make it all happen. The passion that DevOpsDays volunteers have for the DevOps community and event is extremely rare in other parts of IT. Even the agile community doesn't seem to muster enough energy to put on so many conferences. I don’t think application developers can be bothered to look up from their IDEs. There are regional meetups and user groups in IT, sure, but I don’t think there’s anything close to the scale of DevOpsDays. While my overly utilitarian, cold heart might ache at all the "culture" talk in the DevOps community, that vibe is incredibly real and important: it becomes part of the identity and lives of these volunteers. I don't want to see that lost, and it's a huge asset that the IT community should cherish and protect.

3. Focusing on best practices means that the talks, workshops, and discussions at DevOpsDays are focused on continually improving the IT community. There have been four, maybe even five stages of DevOps over the past 15+ years. The DevOpsDays talks focus on what the DevOps community needs help with at the time. You can see this in the community's shifting from automation (infrastructure as code, immutable infrastructure, Puppet, Chef, etc.), to monitoring and management (observability, chaos engineering, etc.), to culture (how people work, the mindsets that lead to good outcomes and good lives), to filling the usefulness-gap created by people's over-enthusiasm for Kubernetes, to the present.

4. DevOpsDays are in-person which is the most effective way to educate the community and keep it thriving. More than many other in-person events, the edge that DevOpsDays has is that the events are regional. They’re all over the world. This means that people in the DevOps community don't have to pay to travel, and if they do, it's usually just an hour or two to go to a nearby city. Compare this to one, large event a year in Las Vegas or Barcelona. The audience and community reach for DevOpsDays is so much larger and, thus, more effective.

The survival of DevOpsDays is more important than the survival of the name DevOpsDays. Because the platform engineering community successfully stole so much of the mindshare, they've sucked much of the sponsorship money out of the DevOpsDays. Worse than redirecting the money is drying the money up all together. Marketing budgets are tight now-a-days (I'm not sure why: vendors want to sell more than ever) so the people controlling event sponsorship money is looking for an excuse to cut costs. And, of course, there’s the redirection that platform engineering, drawing attention and therefore people away from DevOps.

There is currently no platform engineering set of conferences like DevOpsDays. PlatformCon is a good, online conference. I enjoy the recordings, have presented at them, and have encouraged other people to present. The PlatformCon crew is building up momentum for more in-person events (see all the regional group on their above page) - this is great! Good for them! Yay! RIP-TAYLOR-CONFETTI-BLAST!

But it will take years to replicate the reach and assets that the DevOpsDays community has.

I know it feels weird to the DevOpsDays people - it feels weird to me! - but renaming DevOpsDays to PlatformDays would solve a lot of problems quickly. Maybe the PlatformCon community could even merge with DevOpsDays, joining up the benefits of both. I don’t know. Maybe.3

(3) DORA should focus less on metrics and more on practices

DORA is probably the most important marketing asset DevOps has and has had. And it's a genuinely useful tool! DORA’s work is what helped spread DevOps into the mainstream, all those "enterprises.” And the annual cadence and DORA community has helped DevOps evolve, and kept it alive. 

The problem DORA has now is that most people focus only on the four DORA metrics. Common lore is that those enterprise normies don't look beyond the four metrics. This extends to DORA's annual clustering of elite, high, medium, and low performers: these are rankings. Those are just small parts of the overall knowledge in and utility of DORA. I don't think this short-sightedness of DORA users is intentional, or even conscious. It's how just people work. 

Whenever you put metrics and rankings in front of a corporate-human, eventually they'll focus most of their intention on upping their ranking. People do this because they think that being successful means being ranked high, getting a good score/grade. This is because that's how rewards are given in most organizations! Gaming metrics is the most rational thing for a person to do in most organizations. Each year, DORA refines high-grade fuel for this way of working and thinking.

Just as it's not really the fault of the users, it's not really DORA's fault either. But, DORA can help people do better by re-orienting their annual work.

First, the value of DevOps practices are not really in dispute. We all know that they're good. As with flossing, we all know that we should do the practices. DORA shouldn't stop gathering and analyzing these metrics, nor reporting on them. 

What DORA needs to do is move the focus reporting on the actual practices people follow. The activities they do day-to-day, the tools they use, that lead to the great results and clustering.

Of course, DORA currently cover this, but over the years the reports have focused more and more on a discussion of the survey and mechanics of the research rather than actions to take. This is fine! I get it - I have an engineering mindset and I would rather tell you about the internals of what I build, how I did it, and, most of all, what's cool about it. But the DORA-users need a tool. They need to know what to do, not why they should be doing it.

Sure, there's a danger that the users apply tools the wrong way, and you end up with a similar trap of focusing just on the four metrics. But, I mean: let's have a little more faith in people, and DORA’s ability to avoid that.

Let's also take a lesson from Extreme Programming. Extreme Programming is incredibly prescriptive. And, while I don't want to speak on behalf of the priests of that community, over the past few decades there's been a latent operating principle of using Extreme Programming: start with following all of the strict practices, learn what works and doesn't work in your organization, adapt the practices, and start the loop over again. That is how the DORA practices should be applied, and it should be the mission of DORA to make it happen.

In the most recent DORA report (2023) an easy to use discussion of these practices doesn't start until page 81 (out of a total report size of 95 pages). I confess my laziness here and apologize if it resulted in error, but after a few quick flips, I couldn't even find where the practices are covered after flipping through the 77 pages of the 2022 report, the 45 pages of the 2021 report, and had to go all the way back to 2019 to find this on page 31 of 82 pages:

…and page 57 to find the equally valuable this:

There's a snark in the DevOps community that the problem with Accelerate is that everyone who read it came across the four metrics on page 17, declared that they had all they needed, and then closed the book. Well, how about we put a discussion of practice - these very charts - on page one, or, at least page 9.

People in enterprises who are struggling to get better at software need this kind of material: easy to understand, focused and quick, and possible to put into place practices. How do you ensure you floss everyday? First, buy some floss. Second, put it where ever you brush your teeth. Third, notice when you do it and don’t do it. Fourth, keep trying to do it better each day. Life-hack: put it on your desk and turn off the camera when you're bored in a dumb Zoom meeting you can't get out of, and floss. You could also keep the camera on.

The "model" (as I think DORA calls it) is there, and it's even nicely done on the DORA community site (see the figure at the beginning opening of this section). What I'm suggesting is that it should the primary, the first focus of each report. When you email around a 45 to 95 page PDF in enterprises you have one shot to get people to read it and benefit from it. They're looking for the most effective tool they can use right now to achieve whatever goals they have. That practices chart is the tool they're looking for and it should be the first thing they see in the 30 seconds they're going to spend on that PDF. The rest of the work is great, valuable, and hard to do, but those are the "backup slides" that you'll use once you get people's attention and show them what you're proposing.4

We don't need further proof that flossing is good, nor to be told that people who floss have elite teeth. We need to know the mechanics of flossing and how to build a system that lets us put in place continuous flossing.

(4) DevOps should add product management for infrastructure

I give platform engineering a hard time because the people who launched it tried to push the DevOps community in the grave. Or, I don't know, maybe they were just having fun with the headline. Har, har, har…good one.

But, rasing the prominence of product management is an incredibly valuable thing that the platform engineering community has done. And it’s why I think it’s a good, helpful body of work.

The ideas of product management - identifying your customers/users and using, their problems/jobs to be done, crossed with what is technically feasible, and using feedback loops to continuously build a product that best solves their problems…with software - haven't been a large part of the DevOps community. The platform engineering community frames their work as building platforms for application developers, treating them as "customers," and, therefore product managing infrastructure for application developers.5

Sure. Absolutely. Without a doubt. The DevOps community has wanted that outcome and worked towards it. It's right there in the name: Dev! But product management as a practice hasn't been a focus in the DevOps community. It should be! There is a-funny-because-it's-true joke that there are very few devs at a DevOpsDays conference.6 The same is true for the community as a whole.

The good news here is that product management is one of the most understood, well documented, and proven methods of working in software. Thus, from a regular person's perspective - those people enterprises - product management is straightforward and learnable.

Despite product management being easy enough to learn, I think it’ll be incredibly difficult for enterprises to add product management to their infrastructure/DevOps/platform groups. They’re going to need help, and the DevOps community has a proven track record for such tough work.

Some of the people who introduced product management into infrastructure ("platforms") over the past ten years have done a great job grafting their term of art, “platform as a product,” into platform engineering. And it's stuck! I wish this had happened in the DevOps community, but because the platform engineering fig vines took over, it didn't.

Well. You know. We should bring product management into the DevOps world.

For example, DORA could start incorporating it into their studies. While product management is understood for applications, there's not a lot of work on applying it to infrastructure (yes, again: "platforms," if you prefer) and developer tools. Us vendors know about it since it’s our business, but figuring out how to do it in enterprise infrastructure (or even apps!) isn't much studied. DORA can do that, and it'd help clear out some of those vines if they did. (I know the Puppet study-surveys are going for it, so good on them!)

In fact, I'd go as far to say that product management is the missing piece for the wider success of DevOps.

(Now, if you wanted to be clever, you would think this: platform engineering is focused on developers and product manages for them. DevOps will do that, of course, but what a DevOps person will tell you is operations people are also customers [and maybe security people if they behave]. Why not product manage for ops too?)

I will be sad

Listen: I know! I hear you.

But, I'm not saying your efforts are wasted - it's all good stuff. We just need to do more. We need to adapt and change. Fast feedback loops, continuous learning, and changing to do what works are core principles of DevOps. This is what I'm seeing in the feedback loops and the theories I have for how to get better.

I give a huge, massive, rainbow-smelling shit about the DevOps community. It's been a positive force in my career and life. Many of my friends are in the DevOps community and going to DevOpsDays is how I see them. It’s fun! DevOps has also had an important, large impact on how the world builds and runs software. And not just “hats on cats” apps, but apps that you and use everyday to run our lives.

There's a lot of existential malaise going on in the DevOps community, especially among the most enthusiastic and committed members of the community. Some (many?) of the original DevOps community members have drifted out of the community, and will sort of roll their eyes over the whole thing over drinks. There isn't a better community in IT than the DevOps community - it's managed to remain kind, helpful, and nice. I'll be sad if we can't keep it alive and thriving.

Logoff

I guess what I’m trying to say is: DevOpsDays Antwerp was good. It was nice to visit with everyone and see some great talks.