A fractional CTO arrives with limited hours and high expectations. The temptation is to prove value fast: rewrite the roadmap, pick a new framework, reorganise the team. That's usually a mistake. In the first month, the most valuable thing you can do is understand what's really going on, then make a small number of decisions that clearly help.
Week one: listen
- One-to-ones with every engineer, plus the people who depend on them: product, sales, support, and whoever handles the budget.
- Ask each person what's slowing them down, what they'd fix first, and what they're worried nobody has noticed.
- Read recent incidents, the backlog, and the last few months of commits. History is more honest than slide decks.
Weeks two and three: look at the system
Review the architecture, deployments, and operations with the team, not at them. The goal is a shared picture of the main risks: the parts of the system nobody understands, single points of failure (often a single person), security gaps, and anything that makes releases scary.
Resist the urge to fix everything you find. Write it down, rank it by risk and cost, and look for the one or two changes that will make the biggest difference to how the team works.
Week four: decide and communicate
By day 30, three things should exist:
- A short risk register, in plain language, that the leadership team understands and agrees with.
- A small number of agreed priorities for the next quarter, with clear owners.
- A working rhythm: when you're available, how decisions get made and recorded, and how the team raises problems between your days in.
The last one matters most for a part-time role. A fractional leader who's a bottleneck is worse than none. The aim from day one is to help the team make good decisions without you, and to grow the people who'll eventually take the role on.
- Fractional CTO
- Technical leadership
- Architecture review