Think Like a CTO: A Baseline for Small Companies

Sasha picked the book when his area of responsibility changed and he needed a wider view of its perimeter: the contents matched what a head of engineering should do. Both name the main limitation at once — the author writes from the experience of a fund that buys small companies, fixes them, and resells them in two or three years, so the advice suits crisis management with ten to thirty developers. For such companies the book sets a useful baseline, because some of their functions are simply missing; you would not walk into a large technology company with it. The first chapter, on what kind of CTO you are, is laid out by lifecycle stage and by whether you are the first director or came after someone. Sasha notes the honest observations: a title instead of a salary as an early-stage manipulation, and the direct advice to step aside if you are not coping — a nod to the Peter principle he proposes to read more gently: a mature CTO sees where his area sags and strengthens it with people.

Alexander recalls his 2021 talk "CTO from startup to IPO": every stage of a company needs a different leader, and someone who thrives in a startup may get bored during product fine-tuning or the fight over costs in a mature market. Hence his main point — to understand honestly what you want to do yourself and what the company needs right now, or one day you will not want to go to work. Sasha adds audit traps to the section on the first days in the role: the "drift toward the familiar", when a person rushes to fix a known area before seeing the full picture; the negotiation of expectations, in which the business sponsor and the teams try to hang the predecessor's ambitions on the newcomer; and the "watermelon effect", when the metrics are green and the inside is red. Alexander adds Švejk: the problem softens at every step of the report upward.

The chapter on dealing with superiors is called managing up in the original, and the participants find the translation misleading: it is about the CEO, the CFO, and shared committees, not about horizontal links with peers, which the book barely covers. Sasha breaks communication into vectors — down, to your people and skip-level; sideways, to peers and the product director; up — and adds a branch to the business sponsor that the author does not have. The part on the CFO seemed the most useful to him: for an engineer entering the role, budget management is a new area. The author proposes splitting costs into development, operations, and support, which resembles the familiar split into change and run, and recommends keeping a financial model that projects cost growth together with the customer base. Change management is skimmed, and Sasha points to Kotter's model and his iceberg book for depth; he reads the valley of despair in the book as a nod to the Gartner hype cycle, which Alexander happens to be dissecting in a draft.

Both call the chapter on long-term vision simple: it says the technology strategy must support the mission and vision but never explains how to cascade it downward, and without that a written strategy will not come alive on its own. Alexander contrasts it with Technology Strategy Patterns: speak the language of business, understand its patterns — SWOT, the BCG matrix, and the other tools the CFO and the commercial director juggle easily — and explain through them why a technical decision helps the money. Sasha notes that the author mentions "pillars in technology" without a way to choose them and suggests the DDD approaches to carving out domains and the degree of influence. They translate the "fast, good, cheap" argument into the project triangle and on to portfolio management: a strategy is executed as a set of linked initiatives with a shared budget, and that is a tool you have to know how to use — if the toolbox holds one hammer, everything around is a nail.

Both consider the three team chapters — building, interviewing, managing — written at team-lead level: a balance of competencies, the bus factor, how to write a job posting. Sasha noticed that the section on posting text is longer than the section on leadership, where the author only promises "two more books" without naming them; he also missed thinking at the level of teams rather than individuals. The one useful thread is the competency matrix, which the author returns to for hiring and evaluation. Sasha adds Tuckman's model for team dynamics, and Alexander adds his podcast with Nastya Kobicheva, where Tuckman was compared with a psychodynamic model, and an account of how evaluation at T-Bank became an employee-initiated promotion request with a package of artifacts. The chapter on technology decisions — buy or build, cloud or own servers — reduces to criteria and option comparison; Alexander, who has spoken about architecture at scale and running RFCs and ADRs, finds no process in it: a decision log, revisiting, expertise.

The chapter on development stung him most: waterfall is described from hearsay, without the feedback loops of the original articles, agile is reduced to Scrum, and there is almost nothing on quality. Instead he recommends Accelerate and books on engineering practice; Sasha suggests the novels of DeMarco and Goldratt and The Phoenix Project as a light entry. The chapters on contracts, documentation, and security go by quickly: they are hygiene, in a large company backed by lawyers, dedicated teams, and a CISO, while the author describes the level of "at least write something down before Vasya leaves". Support they retell as tiers from the first line to the team, the chapters on company growth as due diligence and the three-envelope joke. The book's last piece of advice — prepare a successor — Alexander illustrates from experience: with six hundred and fifty people and several domains, at some point you have to split the areas, and if you did not grow people in advance, the step cannot be taken. Sasha would have put this advice much earlier. The shared verdict: a contradictory book that provokes reflection, and that is its main value.