The CompUSA platform rebuild was on an eight-month timeline with 18 engineers and a $5.5 billion company’s e-commerce presence depending on the outcome. I joined as the architect. Within the first week, before a line of architectural guidance had been written, three different senior developers had given me three different descriptions of what the system was supposed to do.
That was day one.
timeline title Fractional CTO Engagement Phases Days 1 to 30 : Listen and map current state Days 30 to 60 : Architecture review and risk register Days 60 to 90 : Roadmap and sequenced decisions Month 3 to 6 : Operating rhythm installed Month 6 plus : Ongoing oversight and team development
The First Week Is Not About Answers
The first thing a fractional CTO does is listen. Not as a management nicety — as an architectural necessity. The gap between how a technology system is described and what it actually is can be significant, and the only way to know which version is accurate is to talk to multiple people, read the actual code, and observe where the team’s energy goes versus where the org chart says it should go.
At CompUSA, the divergence in those first conversations was not unusual. Every large engineering effort develops informal descriptions that simplify what’s actually happening. The architect who designed the original system has one mental model. The developers building against it daily have another. The product team has a third. The CEO has a fourth. None of these are wrong exactly — they’re each looking at the same system from a different vantage point.
The first job is to synthesize those vantage points into a clear picture of what the system is, which decisions are genuinely stuck, and what the team is actually capable of versus what’s being assumed on the project plan. That can’t be done remotely or from documents. It requires presence and it requires people to say what’s actually true.
What a Current State Assessment Actually Produces
The output of the first month is not a strategy document or a technology roadmap. Those come later. The output is a set of answered questions.
Which decisions have been deferred, and what is blocking each one?
What does the actual architecture look like in production versus how it’s described?
Where is the engineering team’s capacity concentrated, and where is the gap relative to what the business needs?
What are the immediate technology risks — the conditions that could cause a significant problem if not addressed in the next 60 days?
These questions sound basic. Getting accurate answers in a new environment in 30 days requires significant access and judgment. It also requires credibility with the team — engineers need to say what’s actually true rather than what the project plan says is true. That trust doesn’t come automatically. It comes from demonstrating that the questions are being asked in service of the work, not as an evaluation of the people doing it.
Where the Work Concentrates
Most fractional CTO engagements end up spending the first 90 days on three things.
Architectural clarity. Most technology organizations of any size have some version of undocumented or disputed architecture — systems that work in ways that aren’t in the docs, decisions made years ago and never written down, integration points held together by institutional knowledge. Making these explicit is the prerequisite for making good decisions about what changes next. A thoughtful AS-IS architecture view gives the executive team a way to reason about technology decisions without needing to go inside the code — and it surfaces the real risk register that no project plan is tracking.
Decision clearing. Technology organizations accumulate stuck decisions the same way codebases accumulate technical debt. A decision that should have been made six months ago is still open because nobody has the authority and information to close it, or because closing it requires a difficult conversation with another part of the organization. Part of a fractional CTO’s job is to identify these and create conditions for them to be resolved — which sometimes means making the call directly, and sometimes means structuring the conversation so the right people can make it.
A roadmap the business can actually act on. The first roadmap isn’t a comprehensive multi-year plan. It’s a prioritized view of the next six to twelve months: what has to happen, what should happen if capacity allows, and what gets deferred. The test of a useful roadmap isn’t whether it covers everything — it’s whether the CEO and the engineering team agree on what comes next and why.
What Day One Actually Looks Like
The CompUSA engagement started with three different descriptions of the same system. Within the first two weeks, a fourth description had surfaced, along with a dependency that nobody had mapped and a test environment configuration materially different from production.
None of that was hidden deliberately. It was hidden in the sense that nobody had the role or the time to hold all of it at once and say: here is what we’re actually working with. That’s the first job.
The value of a fractional CTO is not primarily in the individual decisions made over the course of an engagement. It’s in the clarity those decisions are made from. Day one is the beginning of building that clarity, and almost everything useful that follows depends on getting it right.
