The Systems Owner Nobody Hired.

Most mid-market companies have a role that nobody wrote a job description for and nobody officially hired. It’s the person who ends up owning the systems. Not the servers or the laptops. The business applications: the ERP, the CRM, the integrations between them, the reports leadership relies on, the workflows that quietly run the company. Usually this job lands on whoever was standing closest when it got complicated. And usually that’s a problem.

I have been that person twice, once by accident as a general manager who also ran the ERP, and now on purpose as a director of enterprise applications, and I have been called in to clean up after the accidental version of it. So let me make the case for hiring it on purpose.

The gap where this lives

Picture the range. On one end, a small business where the office manager handles IT on the side, resets passwords, and calls a vendor when QuickBooks acts up. On the other end, a real enterprise with a CIO, an IT department, and a team of analysts. Most mid-market companies sit in the long, awkward middle, and the middle has a specific hole in it.

The company has outgrown “someone handles it on the side.” The systems are now complex. There’s an ERP with real customization, a handful of integrations, data flowing between platforms, dozens of people depending on it every day. But the company isn’t big enough to have built a formal applications team, and often isn’t even sure that’s a thing you hire for. So the systems have no owner. They have a collection of part-time babysitters who each know one corner.

What it costs to leave the seat empty

An unowned system doesn’t announce its problems. It accumulates them.

Customizations pile up with no one thinking about the whole. Every department bolts on the thing it needs, nobody’s watching how the pieces interact, and two years later the ERP is a haunted house where changing one field breaks a report three teams away. Integrations get built as one-offs and then nobody maintains them, so they rot quietly until a sync fails and no one can say why. Institutional knowledge lives entirely in people’s heads, which is fine right up until one of those people leaves and takes the only understanding of how payroll actually posts with them.

And the reports leadership trusts to make decisions? Nobody owns whether those numbers are right. They look official. They came out of the system. Whether the logic underneath them still reflects how the business runs is anyone’s guess.

None of this shows up as a line item. It shows up as friction, slow closes, bad data, projects that stall, and a general sense that the systems are working against everyone. The cost is real, but it’s spread across so many small daily annoyances that no single one ever justifies a hire. Add them up and they usually would have justified two.

What the person in this seat actually does

The applications lead, systems owner, whatever you call it, is the person who holds the whole picture. The role needs enough technical depth to understand what the developers and vendors are saying, and enough operational fluency to understand what the business needs, because the job lives in the seam between the two. That seam is where companies at this size bleed.

Concretely, they do a few things nobody else is positioned to do:

• Own the roadmap for the systems, so changes are deliberate instead of reactive, and so the person asking for a customization has to get past someone thinking about the whole.
• Say no. A huge part of the value is stopping the bad idea, the redundant tool, the customization that will haunt you, before it gets built. Nobody without ownership has the standing to say no.
• Translate between the business and the technical. When operations says “we need this,” someone has to turn that into what the system should do, and push back when the request would make things worse.
• Keep the knowledge out of people’s heads and in documentation, process, and configuration that survives turnover.
• Watch the whole board, so a change in one system accounts for its effect three systems over.

When to hire it

You don’t need this person on day one. You need them at the moment your systems became load-bearing and you stopped being able to hold the whole thing in one head. Usually that’s when there’s a real ERP, more than one or two integrations, and decisions riding on system data. If changes to your core systems already feel scary, if nobody can confidently explain how a number gets calculated, if every integration is a small mystery, the seat is already empty and the debt is already accruing.

Filling it is some of the highest-leverage hiring a mid-market company can do, because one person who owns the whole picture prevents a hundred small messes that each look survivable on their own. That whole-picture ownership, keeping systems coherent as a business grows instead of letting them sprawl, is a lot of what I do. The companies that name the role and hire for it on purpose spend a lot less time cleaning up. The ones that leave it accidental usually call someone like me later, and by then the cheapest fix is long gone.