Nobody Owns Your Infrastructure: The Case for a Fractional Senior

There is a stage in a company's growth where the infrastructure has an author but no owner. Someone set it up (usually the second or third engineer, usually in a hurry, usually well), and then the company grew around it. That engineer is now a team lead, or building the product that pays the bills, or gone. The AWS account, the CI pipeline, the DNS, the Terraform that almost matches production: all of it still runs. None of it is anybody's job.

Nothing is on fire, which is the problem. Unowned infrastructure doesn't fail loudly. It drifts, and the drift shows up in places nobody thinks to connect.

The symptoms, which nobody connects

The cloud bill grows faster than revenue, and every month somebody says they'll look into it. They don't, because looking into it means reading the invoice as a design document, and nobody has the context or the mandate to change the design it describes.

Deploys are fragile in a very particular way. They work, as long as the right person does them. There is a runbook, written for a version of the system that no longer exists, and a Slack channel where the real procedure lives in scrollback. Friday deploys are banned, not by policy but by folklore.

Security questionnaires arrive from the enterprise customer you've been chasing for six months, and they get answered by whoever is free that afternoon. The answers are optimistic. "Do you encrypt data at rest?" Yes, probably; the defaults do. "Do you review access quarterly?" We will now. Nobody is lying exactly, but nobody could put their hand on the evidence either, and the questionnaire is the easy part: the audit that follows it isn't.

Then there is the person who knows the DNS. Every company of this size has one. Their knowledge is load-bearing and undocumented, and their holiday is a risk-management event.

Taken one at a time, each of these is a small annoyance with a ticket in the backlog. Taken together, they're one problem. There's no senior person whose job is to own the platform the product runs on: to make decisions about it, to say no to things, and to be accountable when it breaks.

Why this happens to good teams

It isn't negligence. It's a gap in the hiring curve, and in the companies I've worked with it tends to open somewhere between ten and fifty engineers.

At five engineers, infrastructure is a side job and that's fine: the system is small, everyone understands it, and the person who built it is still in the room. At a hundred engineers, you have a platform team, or at least an SRE function with a budget and a manager. In between, there's a long stretch where the infrastructure is too complex to be anyone's side job and too small to justify a team.

The obvious answer is a senior hire. That has three problems. Senior infrastructure people are expensive and hard to find, and the good ones are choosy about companies where they'd be the only one. The role isn't full-time, or not yet. After the first few months of fixing the obvious things, it settles into a pattern of reviewing, deciding, and occasionally firefighting, which is a few days a month of real work. And a lone senior hire in a company that has never had one often ends up doing everything infrastructure-adjacent because they're the only person who can, which, in my experience, burns them out well inside two years.

So the company does the rational thing, which is nothing, and waits for the problem to become big enough to justify the hire. It usually does, in the form of an incident.

What a few hours a month actually buys

A fractional senior is not a contractor you bring in to do a migration. That's a different engagement with a different shape and an end date. Fractional means ongoing ownership at low intensity: someone senior who holds the map of the system in their head, who is on the hook for its direction, and who turns up regularly enough to keep that map current.

In practice, that buys four things.

Decisions. Most of the value is in a small number of decisions made well and early. Which managed services to lean on and which to avoid. Whether the second region is worth it yet. What "production" means, and who is allowed to touch it. These are cheap to make and expensive to reverse, and without an owner they get made by default, one pull request at a time.

A roadmap for the platform. Not a grand plan: a short, ordered list of what to fix, what to leave alone, and what to watch. The value of the list is mostly in the third column. Knowing which ugly things are safe to ignore is what lets the engineers get on with the product.

Someone to ask. Engineers on a product team make infrastructure decisions constantly, because every feature has an operational shape. Having someone to sanity-check those decisions in a fifteen-minute conversation, before they become architecture, is worth more than it sounds.

Answers you can stand behind. The security questionnaire gets answered by someone who knows the true answer, and who can say, when the true answer is embarrassing, what it will take to change it and by when. Enterprise buyers can tell the difference. So can their auditors.

What it doesn't buy

It doesn't buy hands on keyboards. A few hours a month is enough to decide, review, and direct. It is not enough to also do the work, and pretending otherwise is how fractional arrangements fail. The implementation still falls to your engineers, or to a separately scoped piece of work with its own budget.

It doesn't buy an on-call rota, either. A fractional senior can design your on-call, review your incidents, and tell you honestly whether your alerting is a smoke detector or a doorbell. They can't be the person woken at three in the morning, and a sensible one won't pretend they can.

And it doesn't fix a culture that doesn't want the problem fixed. If the leadership team's revealed preference is to ship features and deal with infrastructure when it breaks, a fractional senior will produce a very good list of things that won't get done. That's worth knowing, but it's an expensive way to find out.

How to structure it

The arrangements that work share a few features.

There's a fixed monthly retainer for a fixed number of hours, with an understanding that some months are heavier than others. Paying by the hour produces the wrong incentives on both sides: you ration the calls you should make, and they have no reason to make the problem go away.

There's a regular cadence. A monthly review is the minimum; fortnightly is better for the first quarter, while there's catching up to do. The review is not a status meeting. It covers the cost trend, the incident log, the decisions queued up, and the list of what's changed since last time.

There's a named internal counterpart: an engineer or engineering manager who owns the relationship, carries the decisions back into the team, and is the person the fractional senior is gradually making less dependent on them. That last part matters. A good engagement has exit criteria from the start. Typically the exit looks like one of two things: you've grown enough to hire the full-time person, who inherits a platform with a map and a roadmap instead of an archaeology project, or the internal counterpart has grown into the role.

And there's access, which sounds obvious and often isn't. Read access to the cloud accounts, the billing console, the CI, the incident channel, and the repositories. You cannot own a system you're only allowed to hear about in meetings.

The test

If you want a quick way to decide whether you need this, try answering three questions without asking anyone.

Who decided your production architecture looks the way it does, and when did they last review it? If the most recent large line on your cloud bill doubled next month, who would notice, and how soon? If your enterprise prospect's security team asked to see evidence for your questionnaire answers, who would assemble it, and how long would it take?

If the answer to all three is a name, you're fine. If it's a shrug, or the same overworked name three times, the infrastructure has an author and no owner.

This is the work I do, through WWFF.tech: a few hours a month of senior ownership for companies that have outgrown "a developer set it up" and aren't yet big enough for a platform team. If the three questions above made you uncomfortable, that's the conversation to have.