June 22, 2026
The Middle
This post is part of my Medium blog.
For most of my career I've worked in the middle — not quite a developer, not quite an operator, which meant I wasn't fully claimed by either side. I liked it there. You got to see both worlds clearly because neither one had fully domesticated you yet.
The thing that made it interesting wasn't just knowing the technology on both sides. It was learning to work with people who had fundamentally different ideas about what the work even was. A developer and an operator, sitting in the same room, looking at the same system, often couldn't agree on what "working" meant, let alone what "done" meant. One wanted to move fast and ship things. The other wanted to not get paged at 3 AM. Neither was wrong. They were just solving different problems with different time horizons, and the gap between them was structural.
Go back far enough and there was almost no gap to bridge — because there was almost no contact at all.
Thirty years ago, "developers" and "sysadmins" were in different buildings, sometimes different companies, working under entirely different assumptions. The developer handed off a binary or a deployment package and that was it. The sysadmin figured out how to run it. They didn't really talk. The mental model was: developers make things, operators run things, and those are two completely different kinds of knowledge held by two completely different kinds of people.
The internet blew that up. Not immediately, but persistently. Once you were running web servers that had to stay up, that had to handle real traffic, that had to be patched while live — the old handoff model stopped working. The developer who didn't understand the production environment kept shipping code that broke in production. The operator who didn't understand the codebase couldn't diagnose what was wrong when it did. The separation that had worked when software shipped on disks couldn't survive the always-on, always-deployed reality of the web.
That's why DevOps emerged — not as a technology, but as an acknowledgment that the wall had to come down. I was doing that bridging work before anyone called it DevOps. It wasn't glamorous. It mostly meant sitting in rooms where both sides were slightly annoyed you were there, trying to get them to talk to each other in a language they could both understand.
Now AI is doing something different. Not bridging the gap. Collapsing it.
When you're orchestrating agents to write code, you're not just writing code anymore. You're reviewing output, verifying behavior, catching errors in systems you didn't type character by character. You're watching what the machine produces and intervening when it goes wrong. That's closer to operations than to traditional development.
And the operator is moving the other direction. The sysadmin who used to write bash scripts now has an agent generating Terraform. The SRE who built runbooks by hand now has an agent drafting incident response. The skills that defined each side — writing code, running systems — are both being mediated by the same tools, which means the people using those tools are starting to look a lot more like each other.
This is different from DevOps. DevOps was a cultural movement that asked two groups to collaborate better. This is a technological shift that's making the two groups harder to tell apart. DevOps said: work together. This says: you're already doing the same thing, you just haven't noticed yet.
The disciplines that have tried to bridge gaps before have a bad track record of becoming the gap themselves.
DevOps was supposed to integrate development and operations. Instead it became a third team — not quite engineering, not quite ops, not fully trusted by either, and eventually just another island in the org chart. FinOps is doing the same thing in cloud costs: a team that was supposed to make the rest of the organization cost-aware has become the team you call when you want someone else to deal with your AWS bill.
That's the pattern. You create a discipline to connect two groups, and it becomes a third group that neither side listens to.
The orchestrator role forming now can't afford to make that mistake. But it has to start from a clearer idea of what the orchestrator actually does — not bridging, not intermediating, but standing in the middle and directing traffic in both directions. That's a different job. A bridge connects two sides. An orchestrator decides.
Who becomes an orchestrator? The people who were already in the middle. The developers who understood operations. The operators who understood code. The people who never quite fit either box because they were doing both. They've been there a while. The rest of the industry is catching up.
This is part of a larger argument about what happens when developers and operators converge — and whether the bridge disciplines survive the collapse. Contingent, forthcoming.
In Redundant, the first book in The Condition Set trilogy, Rob Coleman runs the FinOps review that names the waste nobody wants to hear about. The numbers don't change. The question is who they get used against.