The Binary We Don’t Question

Here’s something weird about how we think about work in tech: it’s binary. You’re either a full-time salaried employee (equity, a laptop, a Slack account you’ll never fully mute) or you’re unemployed. That’s it. Those are the options.

When a company needs something done, the conversation almost always starts with “we need to hire someone.” Not “we need this capability” or “we need this outcome.” We jump straight to headcount. FTEs. Full-Time Equivalents. It’s so baked into how we think about building teams that we don’t even notice we’re doing it.

And look, for a lot of roles, that makes sense. You probably want your core application engineers full-time. Your product managers. The people who need to be in every standup and carry deep context on the product roadmap day after day.

But not every need is a 40-hours-a-week need. And that’s where the binary starts to crack.

There’s a Spectrum. Fractional Lives On It.

Between “unemployed” and “full-time employee” there’s a whole range of engagement models. Contract work. Consulting. Agencies. And somewhere on that spectrum, closer to the employee end than most people expect, sits fractional work.

Fractional means exactly what it sounds like: a fraction of a full-time role. Instead of hiring a senior DevOps engineer for 40 hours a week, you engage one for 10 or 20. They’re on your team. They’re in your Slack. They know your systems, your debt, your deploy pipeline, your on-call runbook (even if they’re not the one carrying the pager). They just aren’t there five days a week.

It’s not a new concept. Fractional CFOs and fractional CMOs have been a thing in the business world for years. It just hasn’t fully landed in engineering yet. Which is a shame, because engineering might be where it makes the most sense.

What It Actually Looks Like

Let me get concrete, because “fractional” can sound hand-wavy if you haven’t seen it in practice.

A typical fractional engagement might look like:

• 10-20 hours per week, with a consistent weekly rhythm (not sporadic bursts)
• Embedded in the team’s tools: Slack, Jira/Linear, GitHub, whatever the team actually uses day-to-day
• Recurring syncs with engineering leadership, maybe a weekly 1:1 and async updates
• Defined areas of ownership: maybe it’s CI/CD pipeline health, maybe it’s a cloud migration, maybe it’s standing up an observability stack
• Long-term engagement: months, not weeks. Often open-ended.

What It’s Not

This is where it helps to draw some lines.

It’s not contracting. Contractors are typically brought in to fill a seat for a defined period, doing the same work a full-time employee would do but with an end date. Fractional is a different shape: fewer hours, longer duration, usually more senior.

It’s not consulting. Traditional consultants assess, advise, and hand you a deliverable. Fractional engineers do the actual work. They’re writing the Terraform, reviewing the PRs, debugging the pipeline at 2pm on a Tuesday.

It’s not an agency. Agencies give you a team (or a rotating cast of characters). Fractional gives you a specific person who builds context on your systems and sticks around.

The common thread in what fractional isn’t: those models are fundamentally transactional. Fractional is relational. The person builds context, and that context compounds over time. That’s the whole point.

Why You’d Hire Fractional

There are really three scenarios where fractional makes sense:

1. The need is real but doesn’t justify a full-time hire. This is the big one. Maybe you’re a 20-person startup and your infrastructure needs serious attention, but you don’t have 40 hours a week of DevOps work (or the budget for a senior hire at market rate). You need someone good for 15 hours a week. That role doesn’t exist on a job board. It exists in fractional.

2. Cost efficiency. A senior DevOps engineer in a major market might cost you $180-220k fully loaded (salary, benefits, equity, equipment, the works). A fractional engagement at 15 hours a week will run you significantly less, and you’re typically getting someone more senior because the kind of person who goes fractional usually has the depth to be effective across multiple contexts. Dollar for dollar, the expertise-per-hour tends to be higher.

3. A specific strategic initiative with a known shape. You’re migrating to Kubernetes. You’re standing up a platform engineering function. You’re untangling a deployment process that’s become everyone’s least favorite day. These are projects with clear goals that benefit from senior expertise but don’t necessarily turn into a permanent role once they’re done.

When It’s the Wrong Choice

I’d be doing you a disservice if I didn’t tell you when fractional doesn’t work.

You need on-call coverage. A fractional engineer isn’t carrying a pager for you at 3am. If your primary need is 24/7 operational support, you need full-time staff (or a managed service). A fractional person can build the on-call process, set up the alerting, write the runbooks. They’re just not going to be the one waking up.

You need a whole team. Fractional works for adding senior capability to an existing team, or providing expertise a team lacks. It doesn’t work as a substitute for actually building the team. If you need three engineers working full-time on infrastructure, fractional isn’t the answer. Hiring is.

The work is too core to live outside. If the thing you need done is deeply intertwined with your core product and requires real-time, full-context availability five days a week, that’s a full-time role. Don’t try to fractional your way around a hire you actually need to make.

Knowing when not to use fractional is part of what makes the model credible. Anyone who tells you fractional solves everything is selling you something.

“But How Can Someone Part-Time Really Understand Our Systems?”

Fair question. This is the skeptic’s objection, and it deserves a straight answer.

Two things make this work:

Senior people ramp fast. Someone with 15 years of experience across dozens of environments doesn’t need six months to understand your Kubernetes cluster. They’ve seen the patterns. They know what to look for. They’ll ask pointed questions in week one that would take a junior engineer months to even formulate. The ramp-up time for a seasoned practitioner is dramatically shorter than you’d expect.

They stick around. This isn’t a two-week consulting gig. A fractional engagement is measured in months or years. The engineer builds real context: your tech debt, your team dynamics, your deployment quirks, your business constraints. By month two they’re operating with the kind of institutional knowledge that usually takes a full-time hire six months to develop, because they came in already knowing how most of this stuff works in general. They just needed to learn your specific flavor.

The trust problem is real, but it solves itself faster than people think.

A Typical Month

Let me paint a picture of what an actual month might look like for a fractional DevOps engagement at, say, 15 hours a week:

Week 1: Review the CI pipeline that’s been flaky for months. Identify that the issue is test parallelization hitting a shared database. Ship a fix. Async update to the engineering lead.

Week 2: Pair with a backend engineer on Dockerfile optimization. Their build times have crept up to 12 minutes; get it down to 3. Start scoping the Grafana-to-Datadog migration the team’s been talking about for a quarter.

Week 3: Draft the migration plan for observability tooling. Set up a proof-of-concept Datadog agents in a dev environment. Join the architecture review for a new service to flag deployment considerations early.

Week 4: Continue the Datadog migration. Write runbook documentation for the new alerting setup. 1:1 with the CTO to discuss infrastructure priorities for next quarter.

That’s roughly 60 hours of senior engineering work in a month. Real, shipped outcomes. Not a strategy deck. And the engagement continues next month, building on everything that came before.

The Kind of Person Who Does This

Here’s something worth considering from the other side: the type of engineer who chooses fractional work is almost always deeply senior. They’ve been doing this for 10, 15, 20 years. They’ve run platform teams. They’ve been on-call at scale. They’ve done the migrations, survived the outages, built the thing from scratch more than once.

They go fractional not because they can’t get a full-time job (they definitely can) but because working across multiple environments keeps them sharp, and they’ve reached a point in their career where they’d rather do high-impact work across a few companies than sit in one place attending meetings that could have been emails.

This matters for you as the buyer. When you hire a mid-level DevOps engineer full-time, you’re getting 40 hours a week from someone who’s still building their pattern library. When you hire a fractional senior, you’re getting 15 hours a week from someone who’s seen your exact problem six times before and already knows what works. The skill-to-dollar ratio is genuinely hard to beat.

The Point

We’ve been conditioned to think about hiring in binary: full-time or nothing. But the actual landscape of what companies need is way more nuanced than that. Some problems need 40 hours a week. Some need 15. Some need 60 hours spread over four months and then they’re done.

Fractional is just a name for the part of the spectrum we’ve been ignoring. It’s not a hack or a compromise. It’s a different (and sometimes better) way to match expertise to need.

If you’re an engineering leader staring at a growing list of infrastructure problems and thinking “I need to hire someone,” it might be worth asking a different question first: how much of someone do I actually need?