Resource · Fractional Engineering Leadership
The first 90 days
for a new engineering leader.
The first 90 days of an engineering leader will make or break everything that follows. This is the whole playbook in one place, in four parts, the week-by-week timeline, how to choose and score the quick win, the communication cadence that carries it, and the failure modes to avoid. Built from running this playbook ourselves, and watching what happens when other people don't.
Installing a leader in a portfolio company? This is also the plan you should expect to see from them by week two, and the standard we hold ourselves to when we take the seat.
Got candidate projects already? Score them with the interactive scorer
Make it your plan
One date turns this page into your plan, dated phases, deadlines, and send dates.
Part 01 · The timeline
Thirteen weeks, six phases.
The job in the first 90 days is not to fix things. It's to understand the system, pick the right place to start, ship one credibility-building win, and earn the right to do the larger work. The boundaries below are firm; the contents inside each phase flex to your context.
Phase 1
Weeks 1-2
Listen and map
Understand the current state. Resist the urge to propose anything.
- 30-minute 1-on-1s with every stakeholder affected by your remit, engineering, product, sales, customer success, executives, finance if involved
- In every conversation, ask three questions: what hurts, what would help, what failed here before and why
- Map influence vs. support across the org
- Identify the "Shadow CTO", the unofficial technical authority you will need to bring with you
- Find the burning platform: the pain the business is actually living with, not the one the deck talks about
Phase 2
Weeks 3-4
Define the quick win
Pick one project you can land by day 75, proof of how you operate.
- Choose a quick win that meets all six tests (below)
- Score your shortlist against the four dimensions, 14/20 is the bar
- Get explicit leadership buy-in, verbal nods are not enough
- Assign a small team (2-4 people) with the bandwidth to actually do it
- Communicate the choice to the wider organisation so people see you commit
Phase 3
Weeks 5-8
Execute and build the roadmap
Stay in delivery. Draft the longer roadmap in parallel.
- Stay engaged in execution, do not delegate yourself out of the room
- Weekly cadence: Monday kickoff, Wednesday update, Friday demo
- Draft and socialise the full roadmap in parallel, including what you are explicitly not doing
- Test the roadmap against the stakeholder map from weeks 1-2
Phase 4
Weeks 9-10
Ship the quick win
Ship even if it is not perfect. Make the value visible.
- Ship even if it is not perfect, shipped beats shiny
- Create before/after metrics that a non-engineer can read
- Celebrate publicly and give credit to the team
- Document what you learned and what you would do differently
Phase 5
Weeks 11-12
Communicate the vision
Present the roadmap with the quick win as proof.
- Present the full roadmap to leadership using the quick win as evidence
- Reset expectations honestly, including the things that will take longer than people hope
- Get explicit resource commitments before you leave the room
- Secure approval to proceed into the next phase
Phase 6
Week 13
Establish rhythm
Turn the first 90 days into an operating system.
- Set the operating cadence, standups, planning, reviews, retros
- Identify the next quick win and start the loop again
- Document the processes so the next person inherits something, not nothing
Part 02 · The quick win
Choosing the project that buys your credibility.
Everything in weeks 3-4 hangs on one decision. Run every candidate through the six tests, score the survivors on four dimensions, and pattern-match against the traps before you commit.
Step one: the six tests
Every quick win you consider should pass all six. The ones that fail one or two almost always slip past 90 days, and slipping is the most expensive thing that can happen in this window.
- 1. ≤75 days Landed by day 75: picked by day 30, built in five to six weeks It must land before the credibility window closes. Longer projects accumulate risk.
- 2. Real pain Solves a real pain surfaced in the listening tour It must address an issue from the stakeholder interviews, not from your own preferences.
- 3. Low deps Minimal dependencies on other teams Other teams will delay you. Fewer than two external dependencies.
- 4. Risk-proof Achievable even if half the risks materialise Plan for the version where half the things that could go wrong do go wrong.
- 5. Shows approach Demonstrates your approach to the wider organisation It should show your philosophy, product thinking, user focus, phased delivery.
- 6. Visible outside Visible to people outside engineering People outside engineering must notice and care about the result.
Step two: score the shortlist. 14/20 is the bar.
Name up to three candidate projects and tick off the tests each one passes, the pills are the six tests above. Then score the four dimensions 1 / 3 / 5 (hover a button for what each score means). The maths and the verdict happen right here, nothing leaves this page unless you ask us for a written read at the end.
The six tests
1. Business impact
2. Political capital gained
3. Simplicity of execution
4. Team morale boost
The six tests
1. Business impact
2. Political capital gained
3. Simplicity of execution
4. Team morale boost
The six tests
1. Business impact
2. Political capital gained
3. Simplicity of execution
4. Team morale boost
Then make the decision
- 1. Compare scores. The option with the highest score, minimum 14/20, is your front-runner.
- 2. Gut check. Can you explain in one sentence why this matters to a non-technical executive? Will stakeholders actually notice when it’s done? Are you confident the team can ship it in 60-75 days? Does it create momentum for the bigger transformation? Will the team be proud of it?
- 3. Validate with three people. Your direct manager (alignment), the "Shadow CTO" (technical buy-in), and one person from the affected department (confirms the value is real).
- 4. Document and commit. Write a one-page brief, problem statement, proposed solution, success criteria, timeline with milestones, the team, and the risks with mitigations. Then communicate it broadly and start.
Walk away if you see these
- Nobody you interviewed mentioned this problem, you are solving the wrong thing.
- Multiple executives have competing visions for the solution, political nightmare.
- The project requires approval from someone notorious for blocking things.
- You cannot clearly articulate the business value.
- The team is not excited or believes it isn’t achievable.
- It requires a major technology bet on unproven tools.
- Success depends on another team meeting their deadline.
- The "quick win" is actually a small piece of a much larger project.
The four traps, and what good looks like
The "foundation first" trap
No stakeholder outside engineering cares or notices.
- × Rewrite the authentication system (no visible change)
- × Migrate to a new database (infrastructure only)
- × Refactor core libraries (developers notice, nobody else)
- × Implement a monitoring framework (groundwork, not results)
The "too ambitious" trap
Cannot complete in 60-75 days, too many dependencies.
- × Migrate the entire service to microservices
- × Replace the legacy CRM with a modern solution
- × Rebuild the mobile app from scratch
- × Implement company-wide SSO across all systems
The "political minefield" trap
High political risk, requires consensus from people who disagree.
- × Sunset a system the VP of Sales loves
- × Change a process Finance mandated last year
- × Replace a tool the CEO personally bought
- × Deprecate an API that top customers rely on
The "boring tech" trap
No story to tell, hard to communicate value.
- × Upgrade framework versions (necessary but invisible)
- × Pay down technical debt (important but unexciting)
- × Improve code coverage (developers care, nobody else)
- × Optimise database queries (valuable but not celebrated)
Quick wins that pass, by company size
Under 200 people
- ✓ Kill the manual deploy that only one person knows how to run
- ✓ Replace the spreadsheet that quietly runs an entire department
- ✓ Automate the one integration everyone re-keys data around
- ✓ Fix the chronic bug behind most of the support tickets
- ✓ Stand up basic monitoring so outages stop being a surprise
200-400 person companies
- ✓ Automate the deployment process (4 hours → 20 minutes)
- ✓ Create an internal API for a tool used by three or more departments
- ✓ Fix the chronic performance issue causing support tickets
- ✓ Build a self-service portal for common IT requests
- ✓ Eliminate the manual data export/import between two systems
400-700 person companies
- ✓ Implement feature flags for gradual rollouts
- ✓ Build the analytics dashboard the customer success team has been asking for
- ✓ Create a standardised onboarding environment for new engineers
- ✓ Automate the compliance reporting that takes two days every month
- ✓ Build the integration between two critical business systems
700-1,000 person companies
- ✓ Implement CI/CD for one specific product line
- ✓ Build an internal developer platform for common needs
- ✓ Create unified authentication across legacy systems
- ✓ Automate infrastructure provisioning for new projects
- ✓ Build a data pipeline that eliminates manual reporting
Part 03 · The cadence
Seven messages, keyed to the timeline.
Under-communication is the most common failure mode for new engineering leaders. These seven messages carry the whole 90 days. What matters is the rhythm and what each one must contain, the wording is yours; write it like you talk.
Week 1
Every stakeholder, individually
1. The intro request
Get 30 minutes with everyone your remit touches.
- Ask to learn, not to pitch, questions and a notebook
- Time-bound: 30 minutes, their calendar
- Say explicitly that you are not bringing solutions yet
Week 4
The wider organisation
2. The commitment
Announce the quick win you chose, and why.
- Name the pain it solves, in the words people used in the 1-on-1s
- The timeline (60-75 days) and the named team
- Why this first, what it demonstrates about how you will work
Weekly, weeks 5-12
Stakeholders + team
3. The 30-second update
Keep the rhythm even when nothing dramatic happened.
- Three things done, two things next, blockers or "none"
- On track / behind / ahead against the target date
- Short enough to read in 30 seconds, that is why it gets read
Weeks 9-10
Everyone
4. The ship announcement
Make the win visible and give the credit away.
- Before/after metrics a non-engineer can read
- Named credit to the team and the stakeholders who unblocked it
- What you learned, and a preview of what is next
Week 11
Leadership
5. The roadmap ask
Convert the shipped win into a mandate.
- The win as evidence, not the plan as promise
- Resource needs, risks, and go/no-go points, stated, not implied
- The deck 48 hours ahead of the meeting
Monthly, from month 2
The wider organisation
6. The monthly note
Sustain visibility at a rhythm you can keep.
- Progress and cumulative impact, not activity
- What you are hearing back, and what you changed because of it
- One clear pointer to what is coming next
Whenever pushback lands
The sceptic, directly
7. The pushback reply
Turn resistance into a conversation, not a battle.
- Restate their concern in your own words and ask if you heard it right
- Your reasoning, without defensiveness
- An invitation: "what would you need to see?" and 30 minutes
The principles behind them
- Communicate before you have all the answers. Silence creates anxiety.
- Bad news does not get better with age. Share problems early.
- Credit others generously. Claim victories humbly.
- Use concrete examples over abstract concepts. Show, don’t tell.
- Acknowledge what you don’t know. "I need to investigate" builds trust.
- Repeat key messages. People need to hear things multiple times.
- Make it easy to give you feedback. Ask questions, don’t just broadcast.
- Celebrate progress, even when it feels small. Momentum matters.
Part 04 · What goes wrong
The failure modes, and how to see them coming.
Pitfalls to avoid
- Starting with architecture instead of with problems
- Ignoring the human side of change, the org chart matters more than the tech stack
- Taking on too much, too fast, before you have credibility to spend
- Not celebrating small wins, your team needs the proof too
- Forgetting who you actually serve
Your interview list
- ? What pain caused them to hire you?
- ? Who is the "Shadow CTO" and how do you bring them with you?
- ? What past modernisation or transformation efforts failed here, and why?
- ? Who are your champions, and who are your blockers?
- ? What will you explicitly not change?
Frequently asked
Questions we get
When should a new engineering leader start delivering visible results?
Sixty to seventy-five days, with one quick win shipped by day 90. Faster than that and you're shipping before you understand the business; slower than that and you've lost the room. The first 30 days are listen and define; days 30-90 are execute and demonstrate.
What if the burning platform is not what leadership thinks it is?
It often is not. Your listening tour is partly there to surface the gap between what leadership thinks is broken and what is actually painful for the people doing the work. Naming that gap is sometimes the highest-leverage thing you do in the first 90 days.
Why so many emails, isn’t this overkill?
Because under-communication is the most common failure mode for new engineering leaders. The default behaviour for most engineers stepping into leadership is "ship the work and let it speak for itself." It rarely does. Seven messages across 90 days is roughly one a fortnight, about the minimum cadence required to keep stakeholders informed enough that you don’t lose the room.
Should I send these as emails or post in Slack?
Email for things that need to be reference-able later (the quick win announcement, the completion announcement, the monthly newsletter) and for executive audiences. Slack for the weekly updates and inside the immediate team, it's where they actually get read. The medium changes; the rhythm shouldn't.
Is 90 days enough to actually fix anything?
No, and that is not the point. The first 90 days are about understanding the system, picking the right place to start, shipping one credibility-building quick win, and earning the right to do the larger work that follows. Trying to fix everything in 90 days is the most common way new leaders burn out and lose the room.
Running this playbook yourself, or hiring someone to?
If you're standing up the engineering leadership seat, full-time or fractional, this is the work. We run it for companies who want a senior engineering leader without the full-time hire.