Frank
Systems engineers and developers are not the same kind of animal. I’ve worked both sides of this fence, not as a professional developer, but as someone who has spent 28 years keeping enterprise infrastructure alive while also building real apps in his homelab after hours. I’ve been in the war room when a bad deployment took down mail flow for 200,000 users. I’ve also been the guy at 11pm who broke his own Docker stack trying to push a new feature to HookHouse-Pro. I’ve felt both kinds of pain.
And I’m here to tell you: the gap between these two disciplines is not a communication problem. It’s a worldview problem.
We Don’t Even Agree on What “Broken” Means
Systems engineers live in the world of right now. Something is either up or it’s down, and if it’s down, people are calling. Not emailing. Not submitting tickets. Calling.
Developers live in the world of eventually. Broken means it’ll get logged, triaged, assigned, and fixed in sprint four, right after the new onboarding flow gets finished. That’s not laziness, that’s the job. Feature velocity is how their success gets measured.
But here’s where the damage happens: those are not just different workflows. They are fundamentally different definitions of success. When an uptime-obsessed engineer and a velocity-obsessed developer sit across from each other in a deployment meeting, they are not speaking the same language even when they’re using the same words.
The Infrastructure Is Not Your Sandbox
From where I sit, every reckless deployment that drops Exchange or corrupts an Active Directory attribute is a five-alarm fire with real humans on the other end. Nurses who can’t access patient communication systems. Clinicians locked out of accounts. A help desk that just lit up like a Christmas tree.
From a developer’s chair, that same event is a bad push that gets rolled back. Write the post-mortem, merge the hotfix, move on.
I’m not saying developers don’t care. Most of them do. But when you’re supporting an environment the scale of Advocate Health, there is no “we’ll sort it out Monday.” The environment isn’t a testing ground. It’s a lifeline, and a lot of the people relying on it don’t have a fallback.
That difference in stakes shapes how you think about every decision, every change, every “it should be fine.”
Developers Think We’re Order-Takers. We Think They’re Cowboys.
Here’s the mutual misread that nobody says out loud in the standup meeting.
Developers often see systems engineers as gatekeepers. The people who exist to slow things down, ask annoying questions about change windows, and refuse to just let good code run.
Systems engineers often see developers as people who write brilliant code inside a hermetically sealed bubble and then hand ops a live grenade on the way out the door.
Neither of these is entirely wrong. Neither is entirely fair.
The real tension lives in two places: different definitions of “done,” and different answers to the question of who owns the blast radius when something goes sideways. A developer’s job is often finished when the code ships. A systems engineer’s job starts there.
The Strongest Argument Against Me (And Why It Still Doesn’t Win)
I’ll give the counterargument its due. DevOps is real. Platform engineering is real. There are genuinely gifted people who write production code in the morning and manage infrastructure in the afternoon without breaking a sweat. The wall isn’t absolute.
But here’s what my own experience tells me.
I build apps. HookHouse-Pro is a full React and TypeScript AI music workstation. HomeBase is a homelab asset tracker. Crumble is a PHP and MySQL recipe manager I hand-built from scratch. These are real projects with real code.
And I still context-switch hard when I go from building one of those to managing our hybrid Exchange environment at work. They are not the same muscle. At all.
When I’m building, I’m thinking about what the app should do. When I’m in Exchange, I’m thinking about what breaks if I get this wrong and who’s going to feel it. Even inside my own head, those two modes do not peacefully coexist. They take turns.
Expecting them to be the same thing in a real enterprise org is optimistic to the point of being reckless.
The Translation Problem Nobody Wants to Admit
The actual problem isn’t skill overlap. It’s priority mismatch at the speed of a production incident.
A systems engineer’s urgent is a developer’s background noise. A developer’s “this architecture is technically elegant” means absolutely nothing to someone staring at a mail flow alert at 2am trying to figure out why a connector broke.
Both of those people are right about their own world. That’s what makes it hard.
What actually works in cross-functional environments isn’t forced unity or mandatory empathy training. It’s building just enough shared vocabulary to hand off cleanly, and enough mutual respect to not blow past the boundary where your expertise ends and theirs begins. That’s a low bar, but it’s the right bar.
So Can We Actually Work Together? Yes. But Let’s Be Honest About What That Costs.
Collaboration between these two disciplines works. I’ve seen it work. But it only works when both sides drop the fantasy that the other will ever fully get it.
The goal is not mutual understanding. It’s mutual respect for expertise you don’t have.
The engineers I’ve seen thrive in cross-functional roles aren’t the ones who became developers. They’re the ones who learned to translate without losing their operational instincts. They can sit in a dev meeting, understand what’s being built, ask the right infrastructure questions, and then walk back to their desk still thinking like someone who will be on call when this thing goes live.
That’s a skill. It’s not the same as being a developer, and it shouldn’t have to be.
We don’t need to fully understand each other. We need to respect what the other side is protecting, communicate clearly at the handoff, and stop pretending the gap doesn’t exist.
The gap exists. Working with it honestly is a lot more productive than pretending it away.
