Every founder I have worked with has the same question when we start: "So... what exactly are you going to do?" It is a fair question. Fractional CTO is a title that sounds strategic and vague in equal measure.
The answer is specific, and it follows the same pattern every time I start a new engagement. The fractional CTO first month is not vague advisory work - it is a structured process with real deliverables. Not because I am running a script, but because the first 30 days have a natural order. There are things you need to know before you can do other things, and there is an order in which trust gets built.
Here is what the first 30 days actually looks like.
Week 1: Listen Before Anything Else
The first week is almost entirely listening. I do not make recommendations in week one. I ask questions and read everything I can find.
The conversations I have in the first week:
The founder. Not just about the technical situation - about the business, the customers, the investors, the competitive landscape. What keeps them up at night? What have they tried and abandoned? What decisions are they most uncertain about? I want to understand the company before I understand the system.
The engineering team, individually. Not as a group - individually. The group conversation is dominated by whoever is most senior or most confident. The individual conversations reveal what people actually think. What are they proud of? What are they embarrassed by? What decisions do they disagree with but feel they cannot say? Where do they feel most uncertain?
Other functions: product, sales, customer success. What do they hear from customers? What features have they been promised that engineering has not delivered? What do they do manually that they wish the system did?
The documentation. Architecture diagrams, runbooks, incident reports, commit history. The documentation tells you what the team thinks the system is. The gap between the documentation and the actual system tells you something about how the team operates.
By the end of week one, I have a preliminary picture of where the real problems are. I do not share it yet. The picture is incomplete.
Week 2: Verify and Deepen
Week two is where I go from conversations to direct observation. I stop asking about the system and start looking at it directly.
I go through the codebase. Not a full code review - I am looking for patterns. Where is the code clean and where is it not? Where is coverage high and where is it zero? Which modules have a dozen contributors and which have one?
I follow a piece of work from start to finish. I watch a pull request get reviewed and merged. I watch a deployment happen. I look at how the team handles a production issue. Watching the process in action tells me more than any interview.
I look at the production environment. What does monitoring look like? What alerts are configured? What would happen if the primary database failed right now? Who would know? What would they do?
By the end of week two, I have a grounded assessment. I know what the actual problems are, not just what people said the problems are. The two are never identical.
Week 3: The Assessment Document
Week three is when I produce the first major deliverable: a written technical assessment.
This document covers the current state of the engineering organization across four dimensions:
Architecture and infrastructure: what is the system design, what are its strengths, what are its limitations, what are the highest-priority risks.
Team and process: how does the engineering team operate, what does the development and deployment process look like, where are the gaps.
Strategic alignment: how well is the technical work connected to business priorities, what technical debt is most relevant to the company's current goals, what is being over-engineered relative to what actually matters.
Immediate priorities: the three to five things that should happen in the next 30-60 days, with specific recommendations and rough effort estimates.
I share this document with the founder before sharing it with the engineering team. Not to build a coalition - to make sure the business context is right. The founder often has information that changes the framing of a finding: "that architectural decision you flagged was a conscious tradeoff because of X customer requirement" or "that's exactly what I've been worried about and couldn't articulate."
After that conversation, I share it with the engineering team. Transparently, directly, including the things that are critical. A technical assessment that only tells people what they want to hear is not useful.
Week 4: First Actions
By week four, we are past analysis and into doing. The specific activities depend on what the assessment surfaced, but the pattern is consistent.
I pick one thing that I can move on immediately. Not the biggest problem - the biggest problem is usually a months-long project. I pick something real, meaningful, and completable in a week. A security issue I can fix. A process I can change. A conversation I can have with a vendor that has been stalled.
Early action in the first engagement serves a purpose beyond the immediate improvement: it establishes that the engagement is not just advisory. I am here to make things better, not to write documents about why things are not better.
I have my first 1:1 with each engineer. Not a performance conversation - a relationship conversation. What are they working on? What is frustrating them? What do they wish they could spend more time on? The early 1:1s are where I start to understand the team's actual capabilities and motivations, beyond what I learned in week one interviews.
I establish the operating rhythm. What meetings am I in? What decisions do I need to be in the loop on? What does the founder want a weekly update to look like? The operating rhythm needs to be designed in the first month - if it does not get designed, it gets improvised, which usually means too many meetings and not enough signal.
What Is Not Done in the First 30 Days
Just as important as what happens in the first 30 days is what I explicitly do not try to do.
I do not make major architectural changes. The first month is for assessment and trust-building. Making significant architectural decisions before you have full context is how you repeat the mistakes that got the company to its current state.
I do not reorganize the team. Team changes in the first month send a signal that the incoming executive is cleaning house rather than assessing. Even if I see problems in the team, I need more context before making changes.
I do not promise things I cannot deliver. The first 30 days inevitably surface things that need fixing. I am careful to set expectations about the timeline for those fixes. Nothing undermines trust faster than promising to fix something in week two and then still having it open in week six.
The first 30 days sets the pattern for the entire engagement. An engagement where I listened carefully, assessed honestly, communicated transparently, and delivered one concrete early improvement is one where the founder and the engineering team trust me enough to do the harder work in months two and three.
That trust is the actual deliverable of the first 30 days.
Book a 30-minute call: https://calendly.com/alpsf/zoom-with-aleksandr