Guides for engineering managers
A fractional CTO's first 30 days: reading a team from the outside
A week-by-week plan for understanding an engineering team in a day or two a week, and showing the founder something useful by day 30.
- As a fractional CTO you have a day or two a week and a founder who wants answers quickly. Spend week one on access and data, not opinions.
- Read the team's history from its artifacts: git, deploys, incidents and tickets. Then interview people to find out what the data can't tell you.
- Deliver a short written findings memo by the end of week three, and ship one or two quick wins in week four.
- Set up a lightweight recurring update for the founder or board. Keep it at team level; you are reading a system, not watching individuals.
Fractional CTO work has become a real career path rather than a stopgap. Gergely Orosz, writing in The Pragmatic Engineer article "Headed for the Exit: the Great Engineering Leader Career Break" (August 2026) about engineering leaders stepping back from full-time roles, notes that some now prefer fractional work: one or two days a week per startup, across a few companies. It suits experienced leaders, and it suits early companies that need judgement more than headcount.
It also creates a specific problem. You arrive from the outside, with limited hours, and you need to understand a team well enough to give useful advice before the founder starts wondering what they are paying for. As Eric Brown puts it in his guide to a fractional CTO's first 30 days, "nobody trusts a consultant who spends a month assessing and has nothing to show for it."
This is the plan we would follow. It assumes roughly two days a week and a team of three to twenty engineers.
Before day one: agree what the engagement is for
Ask the founder one question and write the answer down: "In 30 days, what would make you say this was worth it?" Typical answers are a clear view of whether the team can hit the roadmap, a plan for a hire, a fix for reliability, or someone to talk to the board about technology. Your memo at the end of the month should answer that question directly.
Also ask the founder to tell the team you are coming and why, in their own words. "We've brought in someone to help us scale engineering" lands very differently from silence followed by a stranger asking for repo access.
Week 1: access and data
Get read access to everything first. You want the team's history, and the history is in its tools:
- Git history. How often code is merged, how large pull requests are, how long they wait for review, and which parts of the codebase change most. Look for areas only one person ever touches.
- Deploys. How often the team ships to production, how (button, script, or one person's laptop), and how often a deploy is rolled back.
- Incidents. What has broken in the last three to six months, how it was noticed (alerts or customers), and whether anything changed afterwards. If there is no incident log, that is a finding in itself.
- Tickets. How work enters the team, how much is planned versus interrupt-driven, and how long things sit in progress.
- Cloud and tooling costs. Including AI coding tools. Founders increasingly ask about this, and it is easier to answer if you look early.
Read all of this at the team level. Your job is to understand how work flows, where it gets stuck, and where risk concentrates. It is not to rank engineers by commit count. Activity data is a poor measure of individual contribution, and as DX notes, research shows developers don't like metrics aimed at measuring individual engineers. If the team suspects the new outside person is building a surveillance case, you will lose the interviews before you start them.
By the end of the week, write down a list of questions the data raised. That list becomes your interview guide.
Week 2: interviews
Talk to every engineer if the team is small, and to every lead plus a sample if it is larger. Also talk to the founder again, the product lead, and whoever handles support or customer success. Thirty to forty-five minutes each is enough.
Interview questions
- What are you working on right now, and how did it end up on your plate?
- What slows you down most in a normal week?
- When something breaks in production, what happens?
- What part of the system are you most worried about?
- If you could change one thing about how the team works, what would it be?
- Is there anything you think the founder doesn't know that they should?
Say up front what you will do with the answers: themes go into a memo for the founder, nothing is attributed to individuals. Then keep that promise. Engineers who have been through a bad consultant before will be watching for it.
Listen for the gap between the data and the story. If git shows one person reviews nearly everything, ask how they feel about it. If the founder says deploys are fine and the team describes them as stressful, both facts matter.
Week 3: write the findings memo
Put your conclusions in writing, short enough to read in ten minutes. The founder should be able to forward it to a co-founder or board member without editing.
First findings memo template
- The question. What the founder asked for in week zero, restated in one sentence.
- Summary (3 to 5 sentences). The answer, as plainly as you can put it.
- What is working. Two or three things the team does well. Name them; they are easy to break by accident.
- Top risks (three at most). For each: what it is, the evidence, and what happens if nothing changes. Example: "Only one engineer has deployed the billing service in six months. If she is unavailable during an incident, we cannot ship a fix."
- Recommendations. What to do in the next 30, 60 and 90 days, in priority order, with an owner for each.
- Quick wins already in progress. What you are doing this week.
- Open questions. What you don't know yet and how you will find out.
Walk the founder through it live before sending. Then share a version with the team. They gave you the material; they should see what you made of it, and it is the fastest way to build trust for the next phase.
Week 4: quick wins
Pick one or two changes that are small, visible and clearly helpful to engineers, not just to management. Good candidates:
- Writing a deploy runbook so more than one person can ship a hotfix
- Adding alerting for the failure customers keep reporting first
- Agreeing a review turnaround expectation, so pull requests stop waiting days
- Starting a simple incident log and a 30-minute review after each incident
- Cutting a tool or cloud cost nobody was watching
Avoid starting with a reorganisation, a rewrite or a new process for the whole team. Those may come later; in month one they mostly spend trust you have not earned yet.
Set up a lightweight recurring update
Because you are part-time, the founder and board can't see your work day to day, and you can't see theirs. A short recurring update fixes both. Fortnightly is usually right; monthly if the board is the main reader.
Recurring engineering update
- Shipped. The three to five most important things that reached users, in plain language.
- Health. Deploy frequency, incidents and their follow-ups, anything stuck. Team-level numbers only.
- Risks. What changed since last time, and what you are doing about it.
- AI and tooling. What the team is using, what it is helping with, and what it costs. Describe outcomes, not token or line counts.
- Decisions needed. Anything you need from the founder or board, with a date.
Keep it to one screen. Write it from the same sources you read in week one, so it takes under an hour. If it takes a day, you will stop sending it.
Respect the people already there
The engineers on the team built the thing that is working well enough to need you. Assume their decisions had reasons, ask what those reasons were before suggesting changes, and give credit in writing when you find something good. The fastest way to fail as a fractional CTO is to be the outsider who arrived, judged, and left a slide deck. The fastest way to succeed is to make the team's work more visible, to the founder and to each other.
If you are taking on a team full-time instead, see our first 90 days as an engineering manager. For the reporting side, read how to show leadership what AI is doing for your team.