The First 90 Days as CTO

The CTO label can hide very different jobs. One company needs a chief architect, another a product and business partner, a third someone who can scale an engine that already works, and a fourth a crisis leader who restores reliability and trust. The starting point is therefore the type of transition and the company's stage: a startup is building foundations, a growing business is removing constraints, a mature corporation is seeking efficiency, and a crisis system needs immediate intervention. Industry, regulation, ownership, geography, founder or board expectations, and the candidate's own experience complete the picture. The aim is not to find an impressive badge but a situation where the company's problems match the work the person wants and is able to own.

Much of the map can be built before an interview. Public reports reveal economics, customer reviews the quality of the promise, job postings the organizational shape and investment directions, conference talks the level of technical maturity, and release history or status pages the pace and reliability of delivery. A consumer product can be installed, exercised, and tested through support. The flow of money deserves separate reconstruction: who the customer is, which value they pay for, how revenue, margin, and costs work, what share technology consumes, and what justifies further investment. A CTO owns a capital-intensive part of a business; speaking the language of money with peers requires understanding both the economics and the engineering reality. This work produces questions and contradictions, not a final diagnosis, ready to be tested with insiders.

A senior-leadership interview runs both ways. The company examines the candidate's former scope, decision style, and influence outside the technology function; the candidate investigates the actual mandate. An org chart is an incomplete map of power because decisions flow through budgets, trusted relationships, access to owners, advisers, and informal centers of influence. A formal CTO may depend on the CFO for any meaningful spend, while a security leader may enable change or block it. At the commitment point, both sides should make the mutual contract explicit: why the role exists now, which outcomes matter after 30 and 90 days and a year, what the person owns, what can be changed independently, which resources and hiring authority exist, who sponsors the transformation, and how success will be assessed. Internal moves need the same clarity and are especially prone to vague promises.

The first month after joining is for reducing uncertainty and earning trust. ‘At my previous company we did it this way’ becomes an anti-pattern when it substitutes for studying the new context. Alexander recommends turning on one's eyes and ears: speak with C-level peers, direct reports, next-level managers, and engineers; listen to their wording and observe committees, working rhythms, and actual artifacts. Facts must be separated from interpretations, with attention to whose lens is being used — finance, product, engineering, customer, or support. Repeated themes matter more than isolated complaints. In his mobile-banking example, every person claimed their own area was healthy and pointed to a neighbor; walking the circle revealed that the problem belonged to a process or boundary between functions rather than to one individual.

The diagnosis uses several lenses on organizational health: business and money, stakeholders, the path from idea to production, technical quality, user experience, reliability and security, people, and decision tempo. The CTO needs to learn which products earn or consume money, how an idea enters development, how often changes ship, who owns operations, how incidents are reviewed, and whether observability, backups, and recovery plans are real. Urgent threats to safety, people, or business continuity require immediate action, but intervening everywhere creates distraction, signals micromanagement, and undermines team autonomy. By day 30 there should be a coherent map of people, money, flows, risks, and unanswered questions, plus a small set of hypotheses phrased as ‘if we change this, an outcome important to the mandate should move.’

Days 30–90 are for one or two bets, not a portfolio of total transformation. A good bet matters to the business, addresses visible pain, has an owner and observable outcome, does not require rebuilding the whole company first, and can show evidence within the probation period. The hypothesis should be discussed and changed when facts disagree; people stop offering honest feedback to a leader whose strong opinion never updates. A first result earns trust for the next change. By contrast, importing a grand strategy before diagnosis is dysfunction, and even a remarkably broad CTO becomes a bottleneck by centralizing everything. A leadership team is essential, combining people who know the organization with selected external experience. By day 90, the useful artifacts are a diagnosis, direction, delivery rhythm, measurable outcomes, and a team ready to continue — not a large slide deck. Reality also tests the mutual contract: the company's story may change, hidden problems may appear, the promised mandate may shrink, or sponsorship, people, and budget may never materialize. One red flag does not always require an immediate exit: name the discrepancy, leave a written trace, agree how decisions now work, and set a deadline for resolution. The core rule is that accountability must match authority. If an outcome is demanded without the corresponding levers, that gap needs to be raised before evaluation rather than explained afterward. The first 90 days are therefore a two-sided probation period. The CTO demonstrates an ability to understand the system, select changes, and produce observable results; the company demonstrates that its promises about the problem, support, and freedom to act survive contact with practice.