Fractional tech lead work is not consulting. It’s not freelancing. It’s not an extended code review. The distinction matters — and most engagements that fail do so because neither the client nor the lead was clear on what they were actually hiring for.
I’ve been running fractional tech lead engagements for a few years now. What follows is how I actually do it: how I scope work, how I price it, how I onboard into an unfamiliar codebase and team, and what kills these engagements before they have a chance to succeed.
What fractional tech lead work actually looks like
A fractional tech lead is a part-time engineering leader embedded in a team that doesn’t have one full-time. You’re not a senior developer. You’re not a consultant dropping in to write a report. You’re accountable for the technical direction of the product — and you have limited hours to do it.
In practice, that means two or three days per week, sometimes less. It means being in sprint planning, architecture reviews, and engineering retrospectives. It means making the calls that nobody else on the team is positioned to make: which technical debt to pay down now, which to defer, when to push back on a feature request because the foundation isn’t ready.
The day-to-day is less glamorous than it sounds. A lot of it is async: reviewing pull requests, answering questions in Slack, writing ADRs (Architecture Decision Records) so that the reasoning behind decisions outlives your involvement. A lot of it is listening — to developers frustrated by process, to founders frustrated by slow delivery, to both at the same time.
What you’re not doing: writing most of the code. Some, occasionally, to stay credible and to unblock a stuck developer. But if you’re deep in a feature branch for eight hours, something has gone wrong with how the engagement is scoped.
How I scope an engagement
The first conversation with a potential client is a scoping call, not a sales call. I’m trying to understand one thing: is there actually a tech lead problem here, or is there something else?
Some companies need a fractional tech lead. Others need a senior developer who will also do code reviews. Others need an engineering manager who won’t write code at all. These are different roles and mixing them up wastes everyone’s time.
The signals I look for in a scoping call:
The team has technical capability but no architectural direction. Developers are shipping, but there’s no clear owner of the system design. Nobody’s thinking about what the codebase looks like in 18 months.
There’s a communication breakdown between product and engineering. The product manager doesn’t trust the technical estimates. The developers feel like requirements keep shifting. A tech lead sits at that boundary — that’s where most of the value gets created or destroyed.
A specific inflection point is coming. Scaling for a new market, migrating off legacy infrastructure, integrating a new system. These are the moments when having a clear technical voice matters most.
Once I’ve confirmed the problem, I scope the deliverables — not the hours. Clients want to pay for hours; I push to define outcomes. Hours are a bad unit for leadership work because leadership isn’t linear. One well-timed architecture conversation can save weeks of re-work. One missed conversation costs the same.
A typical engagement scoping document includes: the technical problem to be solved, the time horizon (usually three to six months with a checkpoint), what’s explicitly out of scope (hiring, vendor negotiations, full-time delivery commitments), and what success looks like — in measurable terms.
Pricing and time commitment
I don’t charge hourly. I charge a monthly retainer based on days-per-week commitment.
The reason is practical: hourly billing creates the wrong incentives for a tech lead role. If I’m billing by the hour, I’m incentivized to be in meetings, to review every PR personally, to stay visibly busy. That’s not leadership — that’s performing leadership. A retainer incentivizes the opposite: get the team to a state where they don’t need me for every decision, because that’s what good tech leadership actually produces.
Typical engagements run two days per week. Below one day per week, you don’t have enough context to make good architectural decisions. Above three days per week, you’re approaching a full-time role and should be priced accordingly.
Time commitment decisions I make at the start of every engagement:
When do I attend synchronously? Sprint planning and architecture discussions are non-negotiable. Everything else — daily standups, feature reviews — I attend only if my presence adds something a developer on the team can’t provide.
What’s my async response commitment? I commit to a same-day response on Slack for anything blocking a developer. Anything non-blocking gets addressed in the next working session.
What documentation am I responsible for? At minimum: ADRs for significant technical decisions, a technical onboarding document for new developers joining the team, and a quarterly state-of-the-system summary. These aren’t deliverables I hand over at the end — they’re living documents maintained throughout.
Onboarding fast into an unfamiliar codebase
The first two weeks of any fractional engagement are diagnostic, not prescriptive. I’m not there to tell the team what’s wrong. I’m there to understand why things are the way they are.
Speed matters. I have limited hours and the team is paying for leadership, not for a learning period. The onboarding process I run:
Day one: read the README, run the project locally, find out what’s broken. Every codebase has a gap between the onboarding documentation and reality. That gap tells me something important about how much the team invests in maintainability.
First week: map the system. Not the architecture diagram in Confluence — the real system. I trace a representative request from entry point to database. I look at the test coverage. I find the parts of the codebase that nobody wants to touch. I read six months of closed PRs and open issues to understand the team’s decision-making patterns without having to ask.
Second week: one-on-ones with every developer. I ask three questions: What’s slowing you down? What would you change if you could? What’s the one thing you hope I don’t touch?
That last question is usually the most informative. It tells me where the load-bearing walls are — the fragile but critical parts of the system that everyone has silently agreed to work around.
By end of week two, I have a list of the three highest-leverage technical problems. I share it with the team and the client before acting on any of them. See How I Debug Distributed Systems Without Losing My Mind for the same diagnostic-first approach applied to production incidents — the mental model transfers directly.
The failure modes that end engagements early
I’ve seen fractional tech lead engagements go wrong in predictable ways. Most of them are visible in the first month if you know what to look for.
Scope creep into delivery. The client starts asking for code, not just direction. Usually starts innocently — “can you just take a look at this ticket” — and accumulates until you’re spending 80% of your time as a senior developer. The fix is to catch it in week three, not month three. I keep a simple log of how I’m spending my time. If more than 40% is individual contribution rather than leadership, I raise it explicitly.
Unclear ownership of technical decisions. If the founder or CTO is still making the final call on every architectural decision, a fractional tech lead has no real authority. This isn’t about ego — it’s about function. A tech lead who can’t own a decision can’t move fast enough to be useful. I require, at the start of every engagement, a written agreement on which decisions are mine to make and which require escalation.
Being brought in too late. Sometimes a client has already committed to an architecture, a vendor, or a delivery date that’s technically impossible. A fractional tech lead who arrives after the decisions are made can only help at the margins. The engagements where I create the most value are the ones where I’m in the room before the commitments are made. I ask, during scoping: what major decisions are you planning to make in the next 60 days? If the list is long, I push to start immediately.
No single point of contact. When I’m reporting to both the CTO and the CEO, and they disagree about technical priorities, the engagement becomes political. I require one named client-side contact who owns the relationship and breaks ties.
What makes an engagement succeed
The engagements I’m most proud of share a few common patterns.
The team writes better code after I leave than when I arrived. Not because I told them what to do — because the process I put in place made quality a default rather than an exception. Simplicity over engineering is the principle I apply most often: the highest-value technical intervention is usually removing complexity, not adding capability.
The client treats it as a leadership role, not a contractor role. This sounds obvious but it isn’t. Contractors are given tasks. Leaders are given problems. The clients who get the most value from a fractional engagement are the ones who tell me the outcome they need — “we need to ship to three new markets in Q4” — not the tasks they want done.
There’s a clean handoff. The best fractional engagement ends with the client in a position to hire a full-time tech lead who will inherit a well-documented, maintainable system. Or it ends with a developer on the team leveled up enough to take on the role themselves. Either way, my goal is to make myself unnecessary. Engagements that become indefinite dependencies are usually a sign that the right knowledge transfer didn’t happen.
The question every potential client asks
“What’s the minimum viable engagement?”
My honest answer: three months at two days per week, with a defined problem and a named outcome.
Below that, you can’t build enough context to be useful. You spend your limited hours constantly re-learning the system instead of improving it. The engagement becomes expensive advice from a distant expert rather than embedded leadership.
The fractional model works because leadership compounds. The architectural decisions I make in month one affect how fast the team moves in month three. The documentation I write in week two saves hours of onboarding when a new developer joins in month four. That compounding effect disappears if the engagement is too short or too thin.
If a client wants a one-off architecture review, I refer them to a consultant. If they want a tech lead — someone accountable for where the system goes, not just what it looks like today — that’s the work I do.
Running a fractional tech lead engagement or thinking about hiring one? I’m happy to compare notes. Find me on LinkedIn.
Leave a Reply