Why part-time contracts usually disappoint
Part-time senior help sounds efficient and often is not. The usual failure is not the engineer’s skill. It is the gaps. A question is asked on Tuesday, answered on Thursday, and picked up the following Tuesday. Three pieces of work are started and none finished. The team does not know whether a half-built feature is safe to touch. After a month, everyone agrees the arrangement is “fine” and nothing much has shipped.
Those failures are predictable, which means they can be designed out before the first day. That is what this role is built around.
The working agreement
Before any engineering starts, we write a one-page working agreement with your manager or founder. It is the signature deliverable of this role and it is reviewed monthly. It covers four things:
- Weekly capacity. Which days, fixed. Two fixed days are worth more than three floating ones, because your team can plan reviews and decisions around them.
- Work-in-progress limit. How many items I may have open at once, usually one or two. New work waits until something finishes.
- Communication window. When I am reachable outside my working days, if at all, and through which channel. Usually a short window for unblocking questions, not open availability.
- Decision turnaround. How quickly your team answers a question that blocks my work. If I ask by the end of my day, the answer arrives before my next one.
Illustrative example:
| Item | Agreed |
|---|---|
| Days | Tuesday and Wednesday, your business hours |
| Workstream | Evaluation suite for the support assistant, then fixes it reveals |
| Work in progress | One build item and one review item at a time |
| Communication window | Thursday morning, async in the team channel |
| Decision turnaround | Answered before the next Tuesday; escalate to the founder if not |
| Carries the work between days | Named backend engineer, about two hours a week |
| Review point | First Tuesday of each month |
Illustrative example showing the format, not a record from a client engagement.
What the work involves
On my days, I own one workstream end to end: design, implementation, review and release, in your repositories, through your process. I end each day with a written status: what changed, what is next, and what I need answered. Between my days, the named engineer carries anything small and keeps context, helped by tests, types and CI checks that make changes safe without me there to explain them. The approach is the one I describe in my published work on guardrails for AI-assisted development: mechanical checks rather than relying on someone remembering.
Good part-time workstreams have a senior-sized problem and natural pauses: evaluation cycles that wait on labelling, agent workflows that wait on a system owner’s approval, retrieval changes that need a week of real usage before they can be judged.
How acceptance is judged
Your manager accepts work through normal review. The working agreement is itself measured at each monthly review: did work wait on decisions, was the work-in-progress limit kept, did the named engineer have what they needed. If the agreement is not working, we change it, or agree that a different arrangement would serve you better.
Ownership and handover
Because a named engineer carries the work between my days from the start, ownership is shared throughout and the final handover is short. It covers what was built, the remaining backlog in priority order, and anything that only I understand, which should be nothing by then.
When to choose something else
If you are covering a gap until a permanent hire starts, the interim bridge role includes helping you hire and onboard them. If you need leadership with decision authority on a monthly basis, use fractional AI CTO. If you need someone to own an enablement programme part-time rather than engineer, see the fractional AI enablement lead. For full-time work in a particular area, start from the contract roles overview.