A new CTO usually arrives with an expectation of change. The company has problems; otherwise the role would not have been opened or the previous leader would not have been replaced. The urge to show results quickly is understandable.
But the first months are better used to build an accurate model of the company. Move quickly on what you understand. Understand the rest before changing it.
Month one: understand the business before the technology
I would start not with the architecture diagram but with conversations with the CEO, product, sales, finance, and operations. How does the company make money? Where does it lose speed? Which promises to customers are critical? Which risks does leadership already see?
The same technical limitation can be a minor annoyance or a major business risk depending on the business model.
You cannot set technology priorities well until you understand that context.
Build a map of decisions
The org chart tells you who reports to whom. It rarely tells you who actually makes decisions.
Who decides what enters the roadmap? Who owns architecture? Who can stop a release? Who controls budget? Which questions bounce between functions for weeks?
Sometimes the company's real problem is not bad technology but decisions without clear ownership.
Find the strong people before changing the structure
A new leader can see flaws in the current organization immediately and still miss the informal mechanisms that keep it running.
Who knows the system deepest? Who gets called during incidents? Who can disagree constructively? Who connects teams? Who is overloaded because too much depends on them?
Reorganizing before answering those questions can destroy precisely the relationships currently holding the system together.
Separate urgent risk from irritating imperfection
A new CTO will almost certainly find old code, strange processes, manual work, and decisions they would have made differently. That does not mean those things should be fixed first.
Identify risks that can genuinely hurt the business: critical single points of failure, dependency on one person, data problems, security gaps, weak recovery, or growth constraints.
Not everything ugly is dangerous. And not everything dangerous looks ugly.
In month two, define a small number of decisions
By then, the output should not be a giant transformation program. It should be a short list of things that truly need to change.
Perhaps architecture ownership needs to become explicit, one critical bottleneck needs removal, prioritization needs to change, engineering leadership needs strengthening, or the business and technology teams need clear rules for technical debt.
A good first-months plan should fit in your head. If it needs a massive transformation deck to explain, it may already be too complicated.
By day 90, not everything should be known — only what matters
A CTO does not need to have fixed the technology function in three months. But the CEO should already see that the new leader understands the system as a whole.
What are the major technology risks? Which organizational constraints matter? Which decisions require investment? Where is the company consciously accepting a tradeoff? Who owns the changes?
The first 90 days are not for rebuilding the company. They are for stopping important decisions from being made blindly.