The CTO’s First 90 Days Start Before Day One: Choosing the Role, Negotiating the Mandate, and Passing Probation

The conventional first-90-days story starts with a badge photo, introductions, and the official probation clock. That is too late for a CTO. The most consequential choices have already been made: which company transition to enter, which account of its problem to believe, whether the mandate was negotiated or left vague, and what each side now expects. A new executive does not arrive as a blank slate. They bring assumptions, promises, and omissions accumulated throughout the hiring process.

A more useful model treats market research, role selection, mutual due diligence, the commitment point, a month of observation, and two months of deliberate bets as one transition. Michael Watkins frames a transition around accelerated learning and alignment with the new environment. For an engineering executive, that learning begins with the first serious attempt to explain why the role exists now.

This changes the objective of each stage. A search becomes a portfolio of problem hypotheses rather than a contest for attractive titles. An interview becomes a two-way investigation rather than a performance designed to be liked. An offer becomes the point at which both sides should be able to describe the same job. Probation becomes a sequence of learning, testing, alignment, and change—not a hundred-day transformation sprint.

Before joining: choose and test the problem → by day 30: build the map → by day 90: present the diagnosis, first bets, and a renewed operating contract

Some transitions should correctly end before day one. Walking away after serious research is not a failed search. It is the least expensive way to avoid a company that needs a different kind of CTO, or a position where responsibility has been detached from authority.010101This book opens with a diagnosis of chaos rather than a dream of the perfect team: no owners, weak communication, a blame culture, permanent firefighting. I tell the people I mentor much the same thing — if everything were fine, nobody would have called you. The question is only whether this is the mess you want to sort out.Knizhny kub · Engineering Leadership: The Hard Parts (in Russian)

In one company, the CTO is a founder and the long-term product custodian. Elsewhere, the same title means leading hundreds of engineers. It may describe a chief architect working beside a VPE, the public technical face for enterprise customers and investors, or a transformation leader hired after uncontrolled growth damaged delivery. The business cards match; the work, authority, and success criteria do not.

“Do I want to be a CTO?” is therefore a weak career question. Better questions are: what problem do I want to solve, in what transition, at what scale, and through what kind of influence? A gifted architect may hate a job dominated by leadership hiring and investment negotiations. A strong large-organization executive may be the wrong fit when the company needs a working prototype, technical sales, and direct architectural participation.

Decompose the job across at least five axes: expected outcome, business stage, team scale and maturity, depth of technical involvement, and position relative to the CEO, product leadership, and other engineering executives. Then compare not only capability but energy. How much of the week do you want to spend on architecture, customers, leadership teams, budgets, or the board?

The practical rule is to choose the problem, not the status. 020202I wrote in the spring about the role drifting away from “the person in charge of technology” toward the person accountable for the speed and quality of decisions across the whole company. One more argument that context defines the job, not the business card.Knizhny kub · CTO 2026 and how the role is shifting (in Russian) A prestigious title can make an offer emotionally attractive; it cannot repair a mismatch between the real work and the work a person is able and willing to do. The two Think Like a CTO reviews reach a similar conclusion: the role is defined by company context and by how technology now constrains or enables the business, not by a universal responsibility list.

Deep research should not create the illusion that a company can be understood from the outside. Its purpose is narrower and more useful: form hypotheses, find contradictions, and prepare questions capable of separating evidence from a confident narrative. The output is not a dossier. It is a map of uncertainty.

Diagnose the transition before the company

Similar symptoms require different interventions. A startup that has found demand may have a technical system unable to absorb growth. A mature company may need renewal rather than scale. The departure of a founder creates a transfer of tacit knowledge and power. A period of crisis calls for restored reliability and trust. An internal promotion changes the social contract with former peers even when the company itself appears familiar.

Research then moves through layers. Start with the market: customers, competitors, regulation, and scarcity of capital or talent. Study the company’s history, ownership, public statements, vacancies, reviews, launches, and executive turnover. Reconstruct the business: who pays, for what outcome, how buying and implementation work, where margin is created, and what limits growth. Only then move deeper into technology: architecture signals, change cadence, reliability, security, and accumulated obligations.

Follow the money before the interview

A CTO does not replace the CFO, but must understand how the technical system participates in value creation. Who makes the buying decision? What does implementation require? Which revenue repeats? What erodes margin? Where does downtime or slow delivery become commercial loss? Without these answers, technical strategy deteriorates into a list of respectable engineering practices disconnected from the reason for the hire.

Technology is partly visible from the outside. Job openings reveal capability gaps and investment direction. Release frequency, incident history, API documentation, public repositories, conference talks, and leadership changes all provide signals. Keep each signal as a hypothesis: “a migration may be constraining product work; test this in interviews,” not “their architecture is bad.” Research is useful precisely because it produces sharper uncertainty.030303David Hand’s Dark Data makes the same point: decisions get made from the data you have, while the data you lack often matters more. He closes with the old joke about the man searching for his keys under the streetlight because the light is better there. I reviewed the book on my channel.Knizhny kub · Dark Data by David Hand (in Russian)

Executive candidates often spend the entire process demonstrating strength. They tell polished stories, show scale, and infer what the panel wants to hear. Yet the interview has two symmetric jobs. The company is testing whether this person can solve its problem. The person is testing whether the described problem exists, whether it is solvable, and whether the company will accept the consequences of solving it.

Begin with the role’s origin story. Why is it open now? Who performed the work before? What has already been attempted, and what happened? A concrete account contains decisions, dates, and actors. A vague one contains “move faster,” “scale,” and “bring maturity.” Vague language does not prove deception; leadership may not yet have formulated the problem. In that case, problem definition will be part of the job, and expectations need to reflect that uncertainty.

Next, gather independent versions of the same company. Ask the CEO how engineering constrains strategy. Ask product leadership where a customer commitment most often breaks down. Ask finance which technology costs or risks feel uncontrolled. Ask future reports which executive decision they have stopped waiting for. Differences between the answers reveal more than a perfectly aligned company deck.

Power rarely mirrors the org chart. A formal decision owner may still depend on a founder, a strategic customer, a tenured engineer, or a function leader controlling the budget. Do not stop at “who owns this?” Ask for the last comparable decision: who argued, who could stop it, what trade-off was made, and what followed.

Good due diligence preserves the right of both parties to say no. Request conversations with future peers and one or two engineering leaders, a product and architecture walk-through, and the story of a recent incident or contentious priority. No confidential material is necessary. You are looking for the company’s way of thinking about a real event. The interview lessons in the Managing Humans review are useful here: everyday stories expose culture more reliably than a list of declared values.040404I covered a conversation with a former member of Meta’s hiring committee: companies assess past behavior and extrapolate it forward, which is why they ask for concrete stories instead of declarations. A candidate should run the same method in reverse.Knizhny kub · behavioral interviews in big tech (in Russian)

The commitment point is where goodwill becomes a testable agreement. It is neither a legal contract nor a falsely precise hundred-day plan. It is one description of the role that the candidate, CEO, and key peers can repeat in their own words without producing three different jobs.

The contract has five parts. Outcomes describe what should be different in three, six, and twelve months. Authority defines which decisions the CTO owns, which are shared, and where vetoes exist. Resources include team, budget, access to data, and colleagues’ time. Constraints include customer commitments, regulation, legacy, deadlines, and choices the company is not prepared to revisit. Success criteria define the evidence and the way conflicts will be resolved.

The mandate must be separated from the title. If leadership redesign is expected, the CTO needs authority to assess roles, develop people, hire, and when necessary make changes. If faster delivery is the outcome, product decision-making must be within reach; engineering speed alone will not deliver it. If reliability must improve, the trade-off among availability, features, and cost has to be shared with the business.

• —What problem is the company buying by hiring a CTO now?
• —Which three outcomes would demonstrate successful probation?
• —Which decisions are inside the mandate, and which require joint commitment?
• —Which resources exist today, and which are merely expected later?
• —What will be renegotiated if the starting hypotheses prove wrong?

Test the agreement with a short written memo after the final negotiation. Summarize context, outcomes, decision rights, constraints, open questions, and the review cadence. If this document surprises either party, the commitment point has not been reached. Repairing the gap now is cheaper than discovering two months later that an outcome depends on powers no one intended to grant.050505Pavel Bezruchko’s book on writing for senior executives supplies a ready structure for exactly this memo: the recommended action and its deadline first, then alternatives with their risks, and the detailed reasoning in an appendix. I reviewed it on my channel.Knizhny kub · writing proposals for senior executives (in Russian)

Joining creates a dangerous combination: the new executive has high visibility and low context quality. A casual remark becomes policy. Interest in a topic signals an impending reorganization. A question about a person turns into a rumor about dismissal. The central discipline of the first month is to observe without promising to fix every problem as soon as it is named.

In his first-90-days guide for CTOs and VPEs, Will Larson recommends a listening tour, regular meetings with peers and leaders, participation in existing forums, customer exposure, and time with support. The point is not a full calendar. It is system coverage: executives, product and sales, finance and security, engineers, customers, data, and the artifacts of actual work.

Ask several people the same questions so their answers can be compared. What does the company promise customers? What prevents it from keeping that promise? Which decision is being deferred? Where does time disappear? What would a good quarter look like? Which risk is leadership underestimating? One question often produces four companies. The gaps expose disconnects among strategy, management systems, and everyday execution.

Walk three operating flows

Interviews provide accounts; flows provide observations. Walk the path of money from customer interest to payment and renewal. Walk the path of change from an idea through prioritization, development, release, and outcome measurement. Walk the path of an incident from signal through coordination, recovery, and learning. At each step, ask who decides, what artifact remains, where the work waits or loops back, and what the system learns.060606This is precisely the Japanese idea of gemba: to understand a process, go to the place where it happens. I once flew to Orenburg for three days to work as a bank field rep delivering products to customers, and it taught me more than any presentation about service quality ever did.Knizhny kub · gemba (in Russian)Knizhny kub · three days as a bank field rep in Orenburg (in Russian)

The exception to observation is a genuine threat: an active breach, a material security exposure, a failure with immediate financial impact, abusive behavior, danger to people, or an irreversible decision due tomorrow. 070707The first weeks establish a reputation for how you think. People remember whether the new CTO searched for a culprit, checked competing accounts, and returned with an explanation—not only which decision was made. Michael Lopp devotes a whole chapter to how convenient but inaccurate explanations spread through a company under stress. I reviewed the book on my channel.Knizhny kub · A Day in the Life of a Senior Leader (in Russian) Even then, act only far enough to stabilize the situation. Urgency does not grant permission to redesign process, architecture, and organization at the same time.

The first-month deliverable is neither a hundred-page strategy nor a reorganization. It is a map with enough truth to choose the next bets. That map should connect people, money, operating flows, technology, and risk rather than preserve five incompatible functional presentations.

A useful health snapshot uses seven lenses: business and money, stakeholders, delivery, technical quality, reliability and security, people, and pace sustainability. This set is close to the framework Larson uses and to the Engineering Executive’s Primer review. The lenses are not a maturity score. They do not make a company deficient because it lacks a fashionable practice. They reveal tensions: sales growth outrunning implementation, velocity sustained by burnout, or quality protected by a release process too slow for the market.

Attach confidence and provenance to every conclusion. “Leaders say releases are slow” is an observation. “Median time from readiness to production is eleven days” is a measurement. “Manual security approval is the cause” remains a hypothesis until actual work has been traced. This language protects the new executive from premature certainty and makes the map collaborative rather than accusatory.080808I compared Spotify’s traffic-light Squad Health Check with the more rigorous metric sets on my channel. The uncomfortable conclusion: a team survey is self-assessment, not measurement, and its conclusions turn out too vague to act on. Separating observation, measurement, and hypothesis stays manual work.Knizhny kub · Squad Health Check versus DORA, SPACE, and DevEx (in Russian)Knizhny kub · the rest of that comparison (in Russian)

End the month with a review involving the CEO and key peers. Show strengths as well as problems; those strengths will carry the first changes. Name contradictions without staging a reveal. Separate facts from hypotheses and unknowns. State which pre-join assumptions survived and which require a new agreement. This is the first time the mutual contract meets operating reality.

• —a stakeholder map including the practical centers of influence;
• —a business-model view and the three walked operating flows;
• —a seven-lens health snapshot with facts, hypotheses, and confidence;
• —a risk register with threat, likelihood, impact, owner, and next action;
• —a candidate-bet list with an explicit reason most items have not started.

A month of observation produces a long improvement list and a strong temptation to launch it all. Yet both the executive and the organization have limited transition bandwidth. Every initiative needs explanation, ownership, decisions, a new habit, and protection from competing priorities. Ten correct changes launched together will usually create nine unfinished ones.

Larson recommends limiting the initial portfolio to one or two changes unless the company is in a dire situation. This is not ceremonial slowness. It protects learning and trust. The first bet should matter to the business, be narrow enough to show movement during probation, and be systemic enough that the organization works better afterward without the CTO personally pushing every instance.

The best candidates are often operating systems rather than the most visible projects: a shared product-technology decision cadence, restored ownership for a critical service, shorter time from ready to released, a functioning incident-learning loop, or explicit expectations for engineering leaders. Such a change has a repeatable behavior, an owner, feedback, and an observable outcome.

The first result should strengthen trust, not just move a metric. The affected people should recognize the problem; the decision process should be visible; the team’s contribution should be acknowledged; side effects should be named; and learning should return to the organization. “The new CTO personally forced a release through” demonstrates heroic leverage. “The team changed the decision system and now releases predictably” demonstrates organizational leverage.090909Larson makes the same argument about strategies themselves: they need a work-in-progress limit, because an unbounded set produces negligible results on each one. And before writing anything, judge honestly whether you understand the organization well enough for the strategy to be useful. I covered that essay on my channel.Knizhny kub · when to write strategy, and how much (in Russian)

Strategy begins with diagnosis

Day 90 does not require an eternal technology strategy. It requires a defensible link from diagnosis to direction: the business constraints that matter, the capabilities to build, the order of the first bets, what is deliberately not being done, and the signals that would trigger reconsideration. If direction cannot be connected to the walked flows and health map, it is still a collection of the new executive’s preferences.

A CTO does not pass probation brilliantly by changing more than everyone expected. They do so when leadership understands reality better, the organization can see a sequence behind decisions, and the company has a credible operating contract for the next stage. The result has both a substantive and a managerial part.

The substantive part is a tested diagnosis: the central business and technical constraints, existing strengths, material risks, and causes supported by more than one source. From that comes a one-year direction with much greater precision for the next quarter. The managerial part is an operating cadence: where product-technology decisions are made, how bets are reviewed, how risks are raised, and how leadership learns that a hypothesis has changed.

The leadership team is a separate deliverable. Not every people decision needs to be completed by day 90; some require more evidence and respectful work. But there should be a position: which areas have strong owners, where development is needed, which role was designed badly, which hires are critical, and which decisions cannot wait. Engineering leaders are the CTO’s primary multiplier. Having no view of that system is more dangerous than having an unfinished architecture diagram.

Close the period by returning to the original mutual contract. What was confirmed? Where did reality change? Which powers and resources truly exist? Which success criteria should be updated because of evidence rather than convenience? This turns probation from a one-sided judgment of the candidate into a conscious renewal of mutual choice.

Red flags are often presented as a checklist of bad-company symptoms. That is not enough. The same signal can come from concealment, disorder, or honest uncertainty. Treat a flag as a discrepancy between an important promise and observable reality that could change the decision about the role.

Use a protocol, not an instant verdict

First, notice and record the signal without interpretation: “three interviews named three different owners of the budget.” Second, verify alternative explanations and the material consequences. Third, name the discrepancy to someone capable of changing it. Fourth, agree on a concrete correction. Fifth, time-box it. Sixth, escalate or leave based on the result.

Notice → verify → name → agree → set a deadline → escalate or exit

The deadline is essential. Without one, “we will fix this” can defer the decision forever while the CTO accepts responsibility for conditions they cannot influence. On the other hand, an ultimatum at the first weak signal destroys the chance to learn context. The protocol holds the useful middle: skepticism without cynicism, openness without naivety.101010For unchecked flags in their most extreme form, I reviewed the story of India’s Byju’s on my channel: a $22 billion valuation, aggressive growth, a toxic culture, and eventual bankruptcy. The signals were visible long before the end; each one just looked tolerable on its own.Knizhny kub · The Learning Trap on the collapse of Byju’s (in Russian)Knizhny kub · how the Byju’s story ended (in Russian)

Some flags do not require six steps. An illegal request, deliberate deception about material conditions, danger to people, or pressure to conceal an incident may justify an immediate stop. In most executive situations, however, a CTO’s value lies in turning vague discomfort into a testable discrepancy, a direct conversation, and a decision.

The story therefore flips a second time. Red flags do not start after joining, and the candidate is not the only party on probation. The company is also testing whether its promises, mandate, and capacity to change survive contact with reality. The first 90 days end with a renewed contract—or an honest choice not to renew it.