How a Fractional CTO Spots the Real Problem in Week One
The brief that arrives at the start of a Fractional CTO engagement is almost never the complete picture. This is not because the people who prepared it were careless or misleading. It is because organisations have a natural tendency to define the problem in terms of the solution they have already considered. The presenting problem is real. The proposed solution is genuinely believed to be the right one. And the full context of what is actually driving the situation, the constraints, the history, the decisions that created the current state, exists primarily in the heads of the people closest to the work rather than in any document.
Identifying the real problem beneath the stated problem is the most valuable thing a Fractional CTO does in week one. It is also the work that looks least like progress from the outside. There are no deliverables produced. There are no frameworks presented. There is no architecture whiteboard session with confident annotations. There are conversations, observations, and a structured pattern of questioning designed to surface the information that was not in the brief.
After fifteen years of working as a Fractional CTO across more than a dozen organisations through SuperBotics, I have developed a diagnostic methodology for week one that consistently surfaces the real problem before any work is designed around the wrong one. The methodology is not complicated. It is structured around a specific sequence of questions asked of a specific set of people in a specific order. What it produces is a picture of the technical terrain that is almost always more complicated and more useful than the brief that arrived at the start of the engagement.
The Real Problem Diagnostic Sequence: Week One Protocol
The first step is always a conversation with the team closest to the work, not leadership. Leadership’s view of the problem is important and will be captured separately. But the people who live inside the systems every day have information that leadership frequently does not, not because leadership is uninformed but because the information is operational and accumulated through proximity rather than through any reporting structure. These conversations are not structured interviews. They are directed conversations designed to surface the places where people hesitate, qualify, or flag things they assume are already known.
The real problem is almost always visible in the hesitations, not the answers. When someone says “well, technically we could do that, but…” the word after “but” is where the diagnostic work begins.
| Who to Talk To | What to Ask | What to Listen For |
|---|---|---|
| Engineering leads | What slows delivery most? | Technical debt patterns, process friction |
| Product managers | Where do decisions get stuck? | Misalignment between tech and business |
| Operations team | What workarounds exist? | System gaps, unofficial processes |
| Leadership | What does success look like? | Unstated assumptions about the solution |
Reading the Workarounds
Every organisation has workarounds. These are the unofficial processes, the manual steps, the spreadsheets maintained alongside the systems that are supposed to handle the data, the messaging channels used to coordinate things the workflow tool should be handling. Workarounds are the most reliable diagnostic signal available in week one. Each one points to a place where the official system or process does not adequately serve the real operational need. Read collectively, they form a map of the most significant gaps in the current technology setup.
In one engagement I worked through, the presenting problem was a request to rebuild a customer-facing platform that the leadership team believed was driving customer churn. Week one revealed that the platform was performing well by every available metric. The churn was being driven by a three-week onboarding delay caused by a manual data migration process that nobody had documented as a problem because everyone had accepted it as simply how onboarding worked. The platform rebuild that would have consumed six months and significant budget would have delivered nothing against the actual driver of churn. Finding the workaround that revealed the manual migration process cost two conversations and three hours of careful listening.
The Constraint Archaeology Question
One of the most consistently productive questions in week one diagnostic work is what I call the Constraint Archaeology Question: for each significant constraint in the current technology setup, tracing back when it was introduced and why. Technical constraints are almost never arbitrary. They were created by decisions that had reasons at the time. Understanding those reasons is the only way to accurately assess whether the constraint is still necessary or can be safely removed.
Organisations frequently assume that constraints in their current systems are technically necessary when they are actually the residue of decisions made under conditions that no longer exist. A data structure that cannot be easily changed was built that way because of an integration requirement that was replaced two years ago. An API design that creates performance problems was specified to meet a compliance requirement that has since been updated. Understanding the history of constraints allows a Fractional CTO to distinguish between what is genuinely fixed and what is simply assumed to be fixed, and the difference between those two categories is often where the most valuable improvement opportunities live.
Presenting the Real Problem Back
At the end of week one, the most important output is not a report. It is a conversation with leadership that presents the real problem back to them in terms they can evaluate against what they already know. This conversation is designed to test the diagnostic findings against leadership’s understanding and to create space for the organisation to decide whether they want to solve the problem as it was originally defined or as the diagnostic has surfaced it.
In most cases, the diagnostic shifts the priority of the work significantly. The presenting problem is still real and still worth solving. But the sequence changes. The root cause gets addressed before the symptom. The constraint that was generating multiple downstream problems gets resolved before the individual downstream problems are attacked separately. The engagement becomes more efficient and more valuable because it is solving the right problem rather than the most visible one.
If your organisation is entering a Fractional CTO engagement, the most useful preparation you can do is to ask yourself honestly whether the problem as you have defined it in the brief is the root problem or a symptom. That question does not have to be answered before the engagement starts. But the willingness to revisit it in week one is the condition that makes the engagement worth having. More on technology leadership and diagnostic methodology on this blog.
