CTO playbooks from industry leaders

Two short posts took off this week because they solved the same problem in plain English: what a new chief technology officer should actually do before they start “transforming” anything. Rajiv Pant published a reading guide on April 8, 2026 that pulls together nearly two decades of notes on product, design, and engineering leadership, and Ben Johnson’s post distilled the first 90 days into a simple sequence people could use immediately. (rajiv.com, x.com) A chief technology officer at a growth-stage company usually inherits two messes at once: software that grew faster than its blueprint, and teams that grew faster than their management habits. That is why the first 90 days matter so much: a new leader can break trust in a week by reorganizing before they understand the business. (moderncto.io, theartofcto.com) Johnson’s version starts with listening instead of fixing. The point is simple: before you change the engine, you talk to the people driving the car, the people repairing it, and the people paying for the fuel. (x.com, theartofcto.com) The next step is mapping the architecture, which means drawing the real shape of the software as it exists today, not the shape shown in old diagrams. At many companies, the most important system is not the one with the cleanest documentation but the one everybody is afraid to touch on a Friday afternoon. (x.com, moderncto.io) Then come quick wins. A quick win is not a grand rewrite; it is a visible fix like reducing outages, speeding up releases, or removing one approval bottleneck that everybody hates. (x.com, clickup.com) Only after that does the plan accelerate. By then, the new leader has enough facts to decide which systems need investment, which managers need support, and which promises to the chief executive officer are realistic. (x.com, moderncto.io) Pant’s notes zoom out from the first 90 days to the machine a chief technology officer is supposed to build. His core idea is “product, design, and engineering” as one combined organization, which means the people deciding what to build, how it should feel, and how it should work should not operate like three rival countries. (rajiv.com) He calls that combined model PDE, short for product, design, and engineering. Pant says he used it across roles at Knight Ridder, The New York Times, The Wall Street Journal, Hearst, Conde Nast, and Reddit, which gives the framework weight beyond one startup or one software cycle. (rajiv.com, weforum.org) A big part of Pant’s writing is career ladders. His argument is that strong technologists should not have to become managers just to earn more money or gain status, so companies need parallel tracks for management and technical growth. (rajiv.com) He also gets very concrete about org design. In his guide, he links models for medium-size departments, larger departments, and a “three dimensions” approach that balances product teams, partner relationships, and professional disciplines, which is a fancy way of saying a company has to decide whether people are organized around what they build, who they serve, or what craft they practice. (rajiv.com) Put the two playbooks together and you get a sequence that feels obvious only after someone writes it down: first learn the people and the systems, then earn trust with a few visible fixes, then build a structure where product, design, and engineering stop pulling in different directions. That is why these posts spread so fast: they turned a vague executive job into a checklist. (x.com, rajiv.com)