The paradox: the 90 days begin before the employment contract
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.
It is worth being honest about what is borrowed here. The paradox itself — that a transition begins long before day one — is Watkins’s. The transition typology this essay builds later (diagram 04) overlaps his STARS model in three of its five types: startup growth, renewal of a mature company, and recovery from a crisis were described there long before this text; “founder departure” and “internal promotion” are this essay’s additions. What differs is not the diagnosis but the protocol: verifying the company before the offer, with a real option to walk away; a written memo at the commitment point; red flags as a discipline that runs from the first conversation through day 90; and a probation that the company serves, not only the candidate. Watkins wrote for any leader in any transition; this essay narrows the same frame to a single role — which is what lets it afford more specificity.
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.01This 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)
Why the CTO title guarantees almost nothing
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. 02I 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.
How to research the market, company, business, and technical system
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.
The internal move is its own case
An internal promotion looks like the easy version and is underestimated for exactly that reason. Market and company research genuinely can be shortened, but that saving creates the central trap: familiarity with people gets mistaken for understanding of the system. You know how your previous area works, and you quietly extrapolate the rest of the company from it. Walking the three operating flows matters here as much as it does for an outsider, and takes more discipline, because skipping the obvious is more tempting.
What changes is not the company but the social contract. Yesterday’s peers become reports, one of them may have wanted the role, and informal understandings suddenly carry the weight of decisions. Name this in the first weeks: what stays as it was, what changes, and why. Silence here reads as avoidance rather than tact.
There is also a hidden gap: an internal candidate usually has no commitment point. The role arrives by announcement, without a negotiation about outcomes, authority, and resources — and six months later it turns out the parties understood it differently. The mutual contract from the next section is needed more in an internal move, not less. You will simply have to start that conversation yourself, because nobody will offer it.
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.03David 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)
How to turn the interview into mutual due diligence
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.04I 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)
What belongs in the mutual contract before joining
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. Today’s archetypal vague mandate is “do AI for us”: those three words can mean anything from a couple of pilots to rebuilding how the company makes decisions at all. Until the request is unpacked into outcomes and authority, it is not a mandate — it is a fashionable word in an offer.
- 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.05Pavel 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)
How to run a listening tour and see the company that actually exists
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.06This 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. 07The 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.
What should exist by the end of the first month
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.08I 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.
How to choose the first one or two systemic bets
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.
Here I am deliberately stricter than my source, and that is worth saying plainly. The difference is not about when to start: Larson allows launching one or two bets within the ninety days themselves. The difference is that he does not require their results by day 90, and I do — as material for the probation verdict. The reason is simple: the decision about you is made by people who cannot observe the quality of your learning, only whether things became clearer and calmer for them. If your probation is assessed formally, against criteria agreed in advance, Larson’s model is the safer one — take it.
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.09Larson 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.
What to present at the end of probation
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.
| Area | Day 30 | Day 90 |
|---|---|---|
| Company picture | A map of stakeholders, money, delivery, and material risks | A tested diagnosis with priorities and explicitly named unknowns |
| Relationships | Working trust with executives, peers, and engineering leaders | A durable cadence for decisions, feedback, and escalation |
| Changes | Only genuine threats stabilized; other ideas remain hypotheses | One or two systemic bets with owners, measures, and early results |
| Strategy | An initial map of tensions across business, product, people, and technology | A one-year direction, an ordered set of bets, and an explicit not-now list |
| Leadership team | A view of strengths, gaps, and actual areas of ownership | A leadership plan covering growth, hiring, role changes, and decision rights |
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.
Which red flags appear at each stage, and how to respond
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.
How to read the matrix
Read each row from left to right. A row is one kind of discrepancy; the columns are transition stages at which it becomes observable.
? is a hypothesis to investigate; ! is a confirmed discrepancy; !! is a material risk to the commitment, mandate, or decision to stay. A dot means the signal is barely observable yet.
Color repeats the symbol: blue means investigate, amber means name the discrepancy and agree on a response, and red means do not postpone the decision.
This is neither a probability estimate nor a score to total. Read the pattern over time: an early question left untested becomes a more expensive choice after joining.
There are five recurring types: the story changes, the mandate is vague, data is hidden, the sponsor disappears, urgency appears without a cause. The matrix cuts them by type, the table below by stage, which is why “mandate is vague” appears there twice: of the five, its cost grows fastest over time. And urgency without a cause gets no row at all — it is not a standalone signal but a lever used to compress a decision at any stage. The response is always the same: ask what specifically happens if the decision moves by a week. If there is no clear answer, the urgency exists to stop you checking the other four flags.
| Stage | Signal | Response |
|---|---|---|
| Before interviews | “Story changes”: the role cannot be explained without abstractions, and its origin story keeps shifting | Collect independent accounts and test which problem the company is actually hiring to solve |
| During interviews | “Data is hidden”: future peers are off limits, and questions about money or authority never land | Request specific meetings, examples, and decisions; do not turn missing evidence into optimism |
| At commitment | “Mandate is vague”: outcomes are promised but the authority to change people, process, or budget is not | Write down the mutual contract and surface the gap before signing |
| After joining | “Sponsor disappears”: data, resources, or executive access described in the process are unavailable | Size the gap, renegotiate the mandate, and put a deadline on correction |
| By day 90 | A vague mandate surfacing late: probation criteria move once the work is already done | Return to the original contract, present evidence, and choose escalation, a new contract, or exit |
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.10For 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.
What to do when leaving is not an option
Everything above quietly assumes you have an alternative. Often you do not: the visa is tied to the employer, the niche is small, the mortgage does not ask about your mandate, and the option cliff is six months out. “Name the discrepancy and walk” is useless advice in that position, and sometimes harmful — it asks you to stake something you are not prepared to lose. That does not leave you with nothing. The protocol stays the same; what changes is what you risk at step six.
First, bring accountability back in line with the authority you actually hold — in writing, without an ultimatum. “With the decisions I currently own, I am accountable for release timing but not for product priorities” is not a refusal to work. It is an honest map, and it protects you later, when someone asks for a result you were never given the means to produce.
Second, keep a written trail. A short memo after every significant agreement costs ten minutes and changes the conversation six months on. Third, narrow your commitments to what is achievable inside the mandate you have, and say so in advance rather than at review time. Fourth, build the alternative in parallel — keep your network and your sense of market value current, because negotiating power comes from having a second option, not from courage.
And separately: a job that requires all of this can still be a reasonable choice for a year. Staying is not the failure. The failure is staying while calling a forced arrangement a decision. The difference shows in one test — do you know the condition under which you would leave, and have you named it, at least to yourself?
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.
Five ideas that stand on their own
- 01The first 90 days begin when you choose the problem and form the first testable hypotheses about the company—not when HR starts the clock.
- 02The CTO title does not define the job. Before committing, align on outcomes, authority, resources, constraints, and evidence of success.
- 03The first month is for building a truthful company map. Move quickly only against a genuine and irreversible threat.
- 04By the end of probation, a tested diagnosis, one or two systemic bets, an operating cadence, and trust in your decision process matter more than a long initiative list.
- 05A red flag is neither an automatic verdict nor something to tolerate silently. Verify it, name it, turn it into a dated agreement, then escalate or leave.
Books, author reviews, and practical models
Executive transition
- Will Larson · Your first 90 days as CTO or VP Engineeringseven diagnostic lenses, the listening tour, and limiting early changes
- Michael Watkins · The First 90 Daysthe transition model, accelerated learning, and expectation alignment
The engineering executive’s work
- The Engineering Executive’s Primer · a Book Cube reviewbusiness, stakeholders, delivery, quality, and sustainability
- Think Like a CTO · part I · a Book Cube reviewthe ambiguity of the CTO role and working with company context
- Think Like a CTO · part II · a Book Cube reviewstrategy, the technical system, and executive collaboration
Interviews and people
- Managing Humans · a Book Cube reviewinterviews as evidence about culture and everyday work
- Alexander Polomodov · How to hire technical managersan author framework for assessing context, scope, and mutual fit