Engineering Teams

When a Fractional Backend Engineer Makes More Sense Than Another Full-Time Hire

The situations where two or three senior days a week solve the problem, the situations where they clearly do not, and how to run the arrangement so it produces real output.

A fractional backend engineer is a senior engineer who works with your team for a defined part of the week, commonly two or three days, as an ongoing arrangement rather than a project with a hard end date. The interesting thing about the model is not the discount. It is that a certain class of engineering problem is bottlenecked on senior judgement rather than on hours, and for those problems a consistent two days a week from someone experienced beats five days a week from someone who is still learning your domain.

That is a real pattern, and it is also over-sold. Fractional engagements fail in predictable ways, and a lot of the time the honest answer is that you need to hire someone permanently and have been avoiding the decision. I work this way, so treat the enthusiasm accordingly, I have put the failure cases in their own section and I mean them.

What “fractional” actually means here

The word is borrowed from fractional CFOs and CTOs, where the logic is straightforward: a small company needs the function but not the full-time cost. Applied to engineering it means something slightly different, because a backend engineer is not only an advisory role. A fractional backend engineer writes code, reviews code, makes architecture decisions and gets things into production. The reduction is in days per week, not in the depth of involvement.

It is worth distinguishing three things that get confused:

The middle one is a project. The last one will not move your backlog. The first is the model this article is about, and its defining feature is continuity: the same person, the same days, every week, long enough to build real context in your system.

Where the model genuinely works

A hiring gap you cannot close quickly

Senior backend hiring in Europe takes months from opening a role to a productive start, and longer if the first candidate declines. Meanwhile the work does not pause. Two or three senior days a week can hold the architecture line during the search: keep the important decisions from being made by default, keep the code review bar up, and keep the roadmap moving. The important part is that this is explicitly a bridge with an intended end, see the failure cases below for what happens when the bridge becomes permanent.

An architecture bottleneck

This is the case where fractional works best, and it is the most common one I see. One person, often the CTO or the single staff engineer, has become the queue that every non-trivial technical decision waits in. Six engineers are productive on Monday and blocked by Thursday because a schema question, a service-boundary question and a queue-semantics question are all waiting for the same calendar.

Decision throughput is not a function of hours. Adding a second experienced person who can own a category of decisions, data modelling, service boundaries, API contracts, clears the queue even at two days a week, because the work being unblocked is five other people’s work.

A seniority gap in an otherwise capable team

A team of solid mid-level engineers who ship features well can still be missing the specific experience needed for a particular class of problem: designing for concurrency, planning a zero-downtime schema migration on a large table, choosing between queue technologies with real understanding of the failure modes, or resisting a fashionable architecture that will hurt in two years. That gap is narrow and does not need a full-time hire to close. It needs someone who has done it before, present regularly enough to be in the conversation when it happens.

A modernization project or migration leadership

Legacy modernization is the clearest fractional fit, because it is mostly sequencing and judgement. Which parts of the old system should stay, what gets improved in place, what is worth extracting, in what order, and how to keep the product shipping throughout. That is a small number of high-stakes decisions plus steady supervision of the execution, a shape that fits two or three days a week much better than it fits a burst of full-time effort followed by nothing.

If the work has a clear beginning and end and needs someone at four or five days a week to hit a date, that is a project engagement rather than a fractional one; I go through how those are structured, priced and papered in the guide to hiring a senior Go contractor in Europe.

Technical debt that nobody owns

Technical debt loses every prioritisation argument against features, forever, because its cost is diffuse and its payoff is invisible. Reserved fractional days are one of the few mechanisms I have seen that actually work: the time exists, it is booked, and it belongs to someone whose job that week is not shipping the roadmap. Pair it with a written, prioritised list, the debt that is actually costing you incidents and velocity, not everything that offends someone’s taste.

Review, mentoring and raising the floor

A senior engineer doing thorough code review two days a week changes how a team writes code, and the effect compounds. Not review as gatekeeping, but review that explains: why this transaction boundary is wrong, why this cache will go stale in a way you will not notice, what this query does when the table is a hundred times larger. Mentoring is a genuinely good use of fractional time because its value survives the engagement ending.

Production stabilization

Frequent incidents, unclear ownership, no useful observability, a runbook that does not exist. Stabilization work is bounded and mostly senior: find the top causes, fix the ones that repeat, add the metrics and alerts that would have caught them, write the runbooks, and set up an incident review habit the team can keep. This works fractionally as long as you are honest that fractional involvement does not mean on-call cover.

When a fractional backend engineer is the wrong choice

This is the section to read carefully, because the model is fashionable and it is genuinely unsuitable for a lot of situations.

The work needs continuous context and daily availability. Some work cannot be paused. A time-critical incident-heavy period, a launch with daily coordination, a tightly interleaved feature build where three engineers are touching the same code every day, all of that needs someone present every day. Two days a week means three days where questions queue up. If your work is like that, hire, or engage someone full-time for a fixed period instead.

You need a manager, not an engineer. If the actual problem is that six engineers have no one setting priorities, running 1:1s, handling performance issues and doing the hiring, no amount of fractional engineering fixes it. That is an engineering manager or a head of engineering, and it should be an employee. Fractional engineering applied to a management vacuum produces good technical decisions inside an organisation that still cannot decide what to work on.

The real problem is unclear product direction. If the roadmap changes every three weeks and nobody can say what the next quarter is for, the constraint is not backend capacity. A senior engineer will build the wrong things competently. Fix the direction first; you will need less engineering capacity than you think afterwards.

There is nobody to hand work to between sessions. Fractional works when the days in between are productive, someone continuing the implementation, running the tests, answering the questions. If the team is at capacity or too junior to carry work forward alone, the arrangement degrades into a two-day-a-week bottleneck with a nicer job title.

Onboarding cost exceeds the engagement. If your environment takes weeks to get running, access requests go through a quarterly review board, and the domain requires months of context before anyone can be useful, then a small weekly slice may never reach the point of paying back. Either commit to a larger engagement or fix onboarding first. Worth noting: that fix pays off for every permanent hire too, so it is rarely wasted work.

You actually need to hire permanently and are avoiding the decision. The most expensive version of this model is using it as an indefinite substitute for a headcount request nobody wants to make, because approval is hard, because the budget line is easier to hide in a services code, or because committing feels risky. If the work is permanent ownership of a domain, the honest answer is a permanent engineer, and stretching a fractional arrangement over years costs more and leaves you with less institutional knowledge. A good fractional engineer will tell you this. If yours never does, that is information about their incentives.

The team sees it as a verdict on them. An outside senior engineer parachuted in without explanation reads as a statement that the current team is not good enough, and the response is polite non-cooperation. Involve the team in the decision, or expect the recommendations to be ignored.

How to make two or three days a week produce real output

The mechanics matter more than in a full-time arrangement, because the gaps between sessions are where the value leaks out.

Fix the days, and treat them as real

Same days every week, Tuesday and Thursday, or Monday to Wednesday. Predictable days let your team plan around them: reviews and design conversations land on those days, and the person is expected to be there. “Two days a week, flexible” degrades into a few fragmented hours that suit nobody. Contiguous days are better for deep implementation work; split days are better for review and unblocking. Pick based on which of those the engagement is mostly for.

Write handovers at the end of every session

Every working day should end with a short written note: what moved, what is blocked, what is safe for someone else to pick up, and what should not be touched. This is the habit with the largest effect on whether a fractional arrangement works, and it is not optional. It should be in a channel the team reads, not a private message to one person.

Record decisions asynchronously

Architecture decision records, one page each: the context, the options considered, the decision, the consequences. In a fractional arrangement these do double duty. They let decisions be made and reviewed without everyone in a room at the same time, and they leave a trail so the reasoning outlives the engagement. If the only record of why your service boundaries look the way they do is in the head of someone who works with you two days a week, you have built a dependency you do not want.

One owner on your side

Name a single person on the client side who is responsible for the engagement: unblocking access, answering domain questions, deciding priorities when two things collide, and taking over the work at the end. Not a committee. Where fractional arrangements go quiet, it is usually because the internal counterpart was never named and everyone assumed someone else was handling it.

Protect a small amount of async time

The productive days are not the only time work happens. Reviewing a pull request the day after, answering a design question in writing, reading an incident report, a small, explicit allowance for asynchronous work between fixed days prevents the team from being blocked for 48 hours on a two-minute answer. Agree how that is handled up front so it does not become invisible unpaid work or an unbounded expectation.

What to measure

Do not measure hours or commits; both are easy to satisfy without producing value. Agree two or three outcome measures before starting, tied to why you engaged in the first place:

• Decision latency. How long does a non-trivial technical decision wait for an answer? If the engagement is about an architecture bottleneck, this is the number.
• Review turnaround and pull request age. A direct measure of whether the team is less blocked than before.
• Incident frequency and repeat incidents. For stabilization work, repeats matter more than the total, a cause that recurs was not fixed.
• Migration or modernization progress against the agreed sequence. Slices completed and old code actually removed, not services added.
• A capability marker. Something the team could not do before and can now, such as running their own zero-downtime schema migration without escalating.
• Latency and error rate on the systems in scope, if performance was the reason.

Review these monthly, in writing, and be willing to end the engagement if the numbers are flat. A fractional arrangement that has quietly become a subscription nobody evaluates is the failure mode to watch for, and it is easier to detect than the equivalent problem with a permanent hire, which is one of the model’s real advantages.

Deciding whether to try it

Two questions cut through most of it. First: is the constraint judgement or hours? If it is hours on well-defined work, you need more capacity at a level below senior, and a fractional senior engineer is poor value. If it is judgement, decisions queueing, a migration nobody wants to start, debt with no owner, a fraction of a senior week goes a long way. Second: is the ownership permanent? If yes, hire; use fractional only as a deliberate, dated bridge while you do.

If those questions point toward a fraction of a senior week rather than another full-time position, that is exactly the arrangement I run: an embedded senior backend engineer on fixed days, PHP and Go, one B2B agreement and a monthly EUR invoice, starting with a short paid pilot on real work so both sides can evaluate the fit at low risk. You can discuss a fractional engagement on my senior backend contractor page, which lists the concrete terms, days, rate and pilot, so you can compare them against the fully-loaded cost of the hire you were considering instead.