A fractional CTO works a limited number of hours, so the first month decides how much of that time goes to real decisions. Companies that prepare access, name the decisions they need and agree a working rhythm get to useful output sooner. These four weeks are a practical sequence for both sides.
Week 1 — Access and context
Goal: Remove the waiting time before any real work starts.
- Grant read access to code, cloud accounts, issue tracker and documentation.
- Share the current roadmap, budget and any vendor contracts.
- List the people they should meet, and book the introductions.
- Write down the three decisions you most need help with.
You finish with: Access in place and a written list of priority decisions.
Week 2 — Assess
Goal: Build an honest picture of the current technology and team.
- Review architecture, delivery process, security basics and costs.
- Talk to each engineer or vendor about what slows them down.
- Separate urgent risks from long-running improvements.
- Agree which findings stay private and which go to the team.
You finish with: A short assessment with risks ranked by urgency.
Week 3 — Decide
Goal: Turn the assessment into decisions and owners.
- Work through the priority decisions, one at a time, with options and tradeoffs.
- Agree what to stop, start and keep doing.
- Assign an owner and a date to each action.
- Flag anything that needs a budget or hiring decision from you.
You finish with: A decision log with owners and dates.
Week 4 — Set the rhythm
Goal: Make the engagement predictable for the rest of its term.
- Fix a weekly slot for decisions and a written weekly update.
- Agree how urgent issues reach them between sessions.
- Set the milestones for the next 60 days and how progress is shown.
- Review the fit: scope, hours and whether the priorities have changed.
You finish with: A 60-day plan and an agreed operating rhythm.
Common pitfalls
- Spending the first weeks waiting for access.
- Asking for “a strategy” instead of specific decisions.
- No single internal owner for the relationship.
- Treating the fractional CTO as an extra engineer instead of a decision-maker.