Every software organization eventually builds a team to fix the friction between the people who write code and the people who keep it running. Every few years, that team gets a new name.

DevOps arrived in 2009. Site reliability engineering had already taken shape years earlier under a different vocabulary. Today, we call it platform engineering with Gartner projecting that by the end of this year, 80% of large software engineering organizations will have established platform engineering teams, up from 45% in 2022. Three names spread across more than two decades describe the same underlying problem: development and operations don’t naturally coordinate and somebody has to own closing that gap.

I’ve worked under all three labels, sometimes on the same team without the team itself changing much. Different job title on the org chart, but same meetings about why deploys are slow and whose fault the last outage was.

The Same Meeting, Three Names

DevOps grew out of a 2008 conversation about “agile infrastructure” at the Agile Conference in Toronto. It then got its actual name the following year when Patrick Debois held the first devopsdays conference in Ghent, Belgium, in 2009. Google’s site reliability engineering practice traces back further, to 2003, when Ben Treynor Sloss took over a seven-person production team and ran it the way a software engineer would run it, not the way a traditional operations team had always been run. Treynor Sloss’s own definition was concrete: “SRE is what happens when you ask a software engineer to design an operations team.” Google’s SRE workbook later made the DevOps relationship explicit with its programming-language shorthand: “class SRE implements interface DevOps.”

They were different implementations with the same goal, started by communities years apart and only later realized they were solving the same problem.

Platform engineering picked up the same territory again around 2019. It answered a question DevOps and SRE both left loose: who builds the tools and pipelines that make good practice the default instead of the effortful choice? That only helps if the shift is real, though, and it isn’t always.

The Real Change

The difference between a genuine platform shift and a rename shows up in two places.

The first is authority. Traditional operations and early reliability teams could mandate practices because they held production leverage (including the dreaded pager). A platform team that’s really changed treats its internal customers like customers, building something developers choose to use because the self-service path is genuinely faster than filing a ticket and waiting. That’s a different day job than being the group that gets called when something breaks.

That distinction, earning adoption instead of mandating it, is something I’ve written about before at the level of a single tool. The same applies to the team itself.

The second is funding. A platform team with its own roadmap and adoption metrics is resourced differently than a rebadged ops team absorbing whatever falls through the cracks. Job titles update, internal wiki pages get renamed, and six months later deploys still take the same amount of time, because nothing about who owns what, or how that team gets funded, moved.

I’ve sat on both sides of this. I’ve inherited teams where “platform” meant a genuine shift in who owned what and how they were measured, and I’ve inherited teams where it meant a new slide in the org announcement and nothing else. The second is easy to spot once you stop reading the title and dig into the backlog.

So What’s Next?

Whatever fancy name starts trending next, the problem underneath isn’t going away. Development and operations will keep needing deliberate structural help to coordinate as organizations grow, whatever the industry decides to call that help five years from now.

Having watched this cycle multiple times, what’s worked better for me is asking the funding and authority questions before adopting whatever term comes next, not after the org chart has already changed.

Before renaming the team again, name what specifically stops being true about how it operates. If that list is short, the rename is premature.