How to run a fractional engineering team week to week
The operating manual: briefs that work, the two-hour weekly rhythm, what to check on Fridays, and the five habits that separate great engagements from wasted ones.
The pitch for a fractional team says you get engineering without the management load. That’s about 80% true. The crew runs its own work, coordinates its own seams, and doesn’t need your calendar. But the remaining 20% is real, it’s specific, and when engagements go sideways it’s almost always because that 20% didn’t happen.
This is the operating manual for that 20%: what you owe the engagement, in about two hours a week. It’s written from the provider side, which means we’ve seen the same few failure patterns often enough to know them by their Monday-morning smell.
The mental model: direction, not supervision
You manage a fractional team the way you’d manage a very good film crew. You don’t teach the camera operator to frame a shot. You do have to know what movie you’re making, and say so out loud, in writing, before shooting starts.
Concretely: you own what and why. The crew owns how and when-within-the-week. Every failure we’ve watched traces to one side crossing that line: a founder dictating implementation details they half-remember from a bootcamp, or a crew left to guess at priorities because “you’re the experts.”
The weekly rhythm, hour by hour
The whole cadence fits in roughly two hours of your week. We described the in-week version in how to hire engineers by the week; here’s the standing version once a crew is a regular part of your operation:
Monday, 30 minutes, live. Set the week’s sentence: a verb and a deliverable per active seat. “Billing retries ship behind a flag.” “Onboarding redesign reaches testable staging.” Confirm nothing changed over the weekend that reorders priorities. Done.
Midweek, 15 minutes, async. Read the written check-in the crew sends; answer whatever it asks. The questions are usually cheap for you and expensive for them: “A or B?”, “does this edge case matter?”, “who can unblock the Stripe account?” Answer same-day. Founder response latency is the single biggest throughput variable in the whole arrangement, and it’s entirely in your control.
Friday, 45 minutes. Watch the demo of working software. Read the written summary: what shipped, decisions made, what’s proposed for next week. Then do the ten-minute part almost everyone skips: decide next week’s booking now, while context is warm. Same seats? Add QA for the launch? Drop to a heartbeat day? The monthly version of this decision is the seat-sentence test from the scaling playbook.
That’s it. If an engagement needs materially more of your time than this, either the scope was never written down or the crew is wrong for you. Both are fixable; neither fixes itself.
The brief: your half of the contract
Every good engagement we’ve run sat on top of a written brief, and every rescue mission started by writing the missing one. One page:
- What the product does, in the words you’d use to a customer.
- What this engagement ships, as outcomes with a definition of done you’d defend.
- Boundaries. What not to touch, what not to refactor, which sleeping dogs lie. (“The auth module is load-bearing and haunted. Ask first.”)
- Access and people. Who answers questions, how fast, in what channel. Where the repo, staging, and error tracker live.
- Taste. Three adjectives for how you want the product to feel, or three products whose fit-and-finish you’d steal. Saves a hundred small guesses.
Twenty minutes to write. It converts “manage the team” from a standing anxiety into a document the team manages itself against.
What to actually check (and what to ignore)
Founders without an engineering background often over-monitor the wrong things because the right ones feel too simple. The right ones:
- Did working software ship this week? Deployed, clickable, real. Streaks of “almost” are the earliest honest warning sign, and week two is when to say so.
- Do the Friday summaries read like decisions or like activity? “Chose X over Y because Z” is a team thinking. “Worked on the API” is a team billing.
- Is the same crew showing up? Continuity is what you’re paying the model for. Cast changes without conversation are a provider problem, and a serious one.
- Are estimates converging? Everyone misses early estimates; good crews miss smaller each week as they learn your codebase. Divergence is the tell.
And what to ignore: hours worked, commit counts, how busy anyone looks, and whether the branch names follow a convention. Output is the contract. The moment you’re auditing inputs, either trust has broken (address that) or you’re supervising out of habit (address that too).
The five habits, ranked by payoff
- Answer fast. Same-day answers to blocking questions. This one habit outweighs the other four combined.
- One decision-maker. A crew serving two masters with different priorities ships neither’s. If there are two of you, disagree privately, brief once.
- Write changes down. Priority changed Tuesday? Say so in the channel, in writing. Verbal pivots are how Friday demos the wrong thing while everyone acted in good faith.
- Keep scope inside the week. New ideas go in a parking-lot doc for Monday, not into Wednesday’s work-in-progress. The week’s sentence is a contract both directions.
- Do the Friday booking decision. Deciding weekly is the mechanism that makes the whole model elastic. Skip it and you drift into auto-renewal, which is the staircase you left employment to avoid.
When it’s going wrong
Two weeks of missed sentences means stop and rewrite the brief together; nine times out of ten the scope was fiction and everyone’s been too polite to say so. A crew that can’t explain its Friday summary in plain language is hiding, or lost. And if you find yourself dreading the Monday call, say that out loud too. A one-week commitment means the cost of an honest “this isn’t working” is five days, which is precisely the feature you bought. (Compare the same conversation four months into a full-time hire.)
Run the two hours, write the brief, answer fast, and the 80% takes care of itself. The providers worth using make their half visible: written summaries, live booking views, the same faces every Monday. Ours is built that way on purpose, and the first week is the cheapest way to check whether the visible half matches this essay.
