Chapter 13: The Day You Stop Writing Code

Charity Majors, CTO of Honeycomb, provides the most precise account of how technical skills decay under the weight of management. "Management is highly interruptive, and great engineering — where you’re learning things — requires blocking out interruptions. You can’t do these two opposite things at once."^[2] The skills do not vanish overnight. They erode gradually, as the manager’s calendar fills with one-on-ones, planning meetings, hiring calls, and executive reviews. Paul Graham named this dynamic in 2009: the maker’s schedule and the manager’s schedule are structurally incompatible. "A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in."^[3]

Majors puts a timeline on the erosion: two to three years. "The best frontline eng managers in the world are the ones that are never more than 2-3 years removed from hands-on work, full time down in the trenches."^[4] After that, the manager’s mental models become stale, their instincts become unreliable, and their ability to evaluate the team’s work begins to depend on trust and hearsay rather than direct understanding. Majors is explicit about the consequence for architects who let the gap widen too far: "`Some of the most useless people I’ve ever met were engineers who were ‘promoted’ to architect many, many years ago, and have barely touched an editor or production shell since.`"^[2]

Camille Fournier, who was CTO of Rent the Runway, frames the erosion as a feature of the role, not a bug. "CTO is not an engineering role. CTO is not the top of the technical ladder, it is not the natural progression for engineers over the course of their careers to strive to achieve."^[5] The CTO role is an executive role — defined by communication, strategy, and organisational design, not by code output. Fournier does not minimise the loss. "Eventually, even the deepest knowledge will atrophy."^[6] But she insists that the loss is the price of admission to a different kind of contribution — one that is harder to see and harder to measure, but more consequential at scale. Her advice to engineers considering the transition: spend enough time mastering the craft before making the jump. "I am a big advocate for spending the time it takes to gain mastery of programming before moving into management. For me, this took about 10 years."^[6] The depth you build before the erosion begins determines how deep you can afford to erode.

Larson provides the most honest account of what the erosion feels like from the inside. After a decade away from coding, he returned to writing pull requests and discovered something specific: the loss was not in syntax or language knowledge. It was in mental models. "Even simple fixes require an effective mental model of the codebase being worked on. My experience is that only writing software can build a truly effective understanding of unreasonable software."^[1] The CTO who reads architecture documents and attends design reviews maintains a high-level understanding. The CTO who has not touched the codebase in two years lacks the visceral, muscle-memory understanding of how the system actually behaves — the understanding that lets an engineer look at a bug report and know, before opening the code, roughly where the problem is. That understanding cannot be maintained through delegation. It can only be maintained through contact.

The emotional dimension of this transition is under-discussed in the engineering leadership literature. Most accounts focus on the practical mechanics — what to delegate, when to hire a VP of Engineering, how to stay involved in architecture. Few acknowledge what the CTO is actually experiencing: grief. The identity that brought them to the role — the builder, the coder, the person who could solve any problem by writing the solution — is being replaced by an identity they did not train for and may not yet value. Majors captures the risk of avoiding the grief: "I see lots of people who feel like they made a wrong decision somewhere along the line, who look up ten years later and feel trapped and unhappy — what they thought was a promotion was actually a career change."^[4]

The phrase "staying technical" is used so loosely in the CTO community that it has become almost meaningless. It can mean anything from "I still write production code every day" to "I read Hacker News." The useful definition is narrower and more demanding: the CTO is technical enough to make sound architectural decisions, evaluate the quality of the team’s work, and detect when something is going wrong before the metrics reveal it.

Allan Leinwand, CTO of Shopify, provides the most practical framework. His approach centres on reading rather than writing. "I spend a lot of time reading on Github. I read commits, read through the documentation, look through test results, and see if we’re releasing things properly and at the right time."^[7] He is candid about the boundary: "A large company does not want the CTO consistently pushing new code to production. As a CTO, I can fix bugs and dive into repos, but the day I’m pushing new code to production on a regular basis is probably not a good day for the company."^[7]

Leinwand’s six practices for staying technical include: attending internal technology conferences and talks, maintaining a private Slack channel with 20 senior engineering leaders (internal and external) for asking questions and being vulnerable about gaps in knowledge, reading code and documentation regularly, participating in architecture reviews, and building side projects that stay off the production critical path.^[7] The common thread: proximity without interference. The CTO stays close enough to the codebase to understand what is happening, without becoming a bottleneck on what ships.

David Singleton, CTO of Stripe, developed a practice that Sergio Visinoni, writing in his Sudo Make Me a CTO newsletter, calls an "Engineer-ication": "During a few days you block your calendar and agenda rejecting meeting invites and delegating certain tasks to other people, as if you were to go on vacations. Instead of spending that time resting and having fun in an exotic location, you join one of your engineering teams as Individual Contributor, and work on one or more software engineering tasks."^[8] The practice is not about the code the CTO produces — Visinoni estimates the CTO adds roughly 2.7% to the team’s output during an Engineer-ication. It is about rebuilding the mental model. The CTO who spends three days embedded with the team doing actual engineering work will understand the tooling friction, the deployment pain, the undocumented dependencies, and the morale dynamics in a way that no dashboard or status report can convey.

Alex Ewerlöf, a principal engineer who surveyed engineering leaders on how they maintain technical depth, found that the most commonly cited strategies were reviewing code, participating in design reviews, and reading technical content — activities that require judgment rather than sustained flow state.^[9] The least commonly cited was writing production code. The pattern is consistent across every source in the research: the CTO’s technical practice shifts from production to evaluation, from writing to reading, from implementation to judgment.

DHH provides the exception that proves the rule. He has written production code at 37signals for more than two decades and explicitly rejects the idea that the CTO should stop: "If I promote myself out of programming, I turn myself into a project manager."^[10] But 37signals is deliberately small — roughly 60 employees, no investors, no board. DHH’s model works because he has designed a company where the CTO can remain an IC. Most startup CTOs do not have that option.

If the CTO’s value is no longer in writing code, where does it reside? The research converges on a single answer: architectural judgment — the ability to evaluate trade-offs, anticipate scaling challenges, and make decisions that shape the system for years.

Grady Booch, one of the founders of modern software architecture, defines architecture as "the significant design decisions that shape the form and function of a system, where significant is measured by the cost of change."^[11] Martin Fowler, in a 2003 IEEE Software essay that remains the most cited piece on the architect’s role, channels Ralph Johnson of the University of Illinois: "Architecture is about the important stuff. Whatever that is."^[12] The implication: the CTO does not need to understand every line of code. They need to understand which decisions are expensive to reverse and ensure those decisions are made well.

Fowler draws a distinction between two archetypes of architect. The first — the Architectus Reloadus — makes all the important decisions because the team is not experienced enough to make them. The second — the Architectus Oryzus — mentors the team to make better decisions themselves. Fowler’s preference is clear: "One of an architect’s most important tasks is to remove architecture by finding ways to eliminate irreversibility in software designs."^[12] The best architect is the one who reduces the number of decisions that need to be architectural. And the golden rule: "An architect’s value is inversely proportional to the number of decisions he or she makes."^[12]

Michael Nygard’s Architecture Decision Records, introduced in 2011, provide the practical mechanism for the CTO to stay engaged with architectural decisions without being in every meeting. An ADR is a short document — title, status, context, decision, and consequences — that captures the reasoning behind an architecturally significant choice. "One of the hardest things to track during the life of a project is the motivation behind certain decisions," Nygard writes. "A new person coming on to a project may be perplexed, baffled, delighted, or infuriated by some past decision."^[13] The ADR ensures that the "why" is preserved alongside the "what." The ThoughtWorks Technology Radar lists ADRs at "Adopt" — their highest recommendation level — and notes: "For most projects, we see no reason why you wouldn’t want to use this technique."^[14]

Andrew Harmel-Law, a technology principal at ThoughtWorks, takes the principle further with the Advice Process: "Anyone can make an architectural decision," but before doing so, they must consult "everyone who will be meaningfully affected by the decision, and people with expertise in the area."^[15] Harmel-Law describes his own transition: "I stopped taking architectural decisions. Completely."^[15] The result was not chaos but better decisions, because the people closest to the implementation were making the calls — with the CTO providing context and constraints rather than directives.

Will Larson frames the CTO’s overarching contribution as engineering strategy — a document built from the patterns that emerge across individual technical decisions. "To write an engineering strategy, write five design documents, and pull the similarities out. That’s your engineering strategy."^[16] The strategy document is the CTO’s architectural fingerprint on the organisation: not a list of technologies to use, but a set of principles that guide the hundreds of decisions the CTO will never personally make.

The CTO who no longer writes production code must find a different source of technical credibility. Positional authority — "I’m the CTO, so my technical judgment carries weight" — is fragile and self-defeating. Majors states this with characteristic directness: "Any time you have to tell someone what to do using your formal authority, you have failed in some way and your actual influence and power will decrease."^[17]

The alternative is earned authority — credibility that comes from demonstrating technical judgment in the specific context the team is working in. Majors connects this directly to hands-on fluency: "Your credibility, your expertise, your moral authority to impose costs on the team are all grounded in your fluency and expertise with this codebase and this production system — and your willingness to shoulder those costs alongside them."^[17] The CTO does not need to be the best coder. They need to be fluent enough in the current system to ask the questions that reveal problems, to evaluate the answers, and to know when they are being given a confident explanation of something that is wrong.

Pat Kua, former CTO of N26, identifies the failure mode that destroys this credibility: the Ivory Tower Architect. "`If you do not spend time with the code, you run the risk of invoking the ‘Ivory Tower Architect’ anti-pattern, leading technical decisions without understanding their real implications for implementation or maintenance. This anti-pattern has numerous side effects including destroying trust with developers.`"^[18] The practitioner community has a more vivid name for this: the seagull architect — the executive who swoops into a design review, drops opinions, and leaves before dealing with the consequences. One developer’s account captures the dynamic precisely: "He swooped in, dumped a lot of poop in the form of PowerPoint pictures of the architecture, and left as soon as possible."^[19]

The CTO who avoids both extremes — neither writing all the code nor retreating to the PowerPoint layer — occupies a specific position: close enough to the system to have informed opinions, distant enough to let the team own the decisions. Fowler’s mountaineering metaphor captures it: the best architect is a guide — "a more experienced and skillful team member who teaches other team members to better fend for themselves yet is always there for the really tricky stuff."^[12]

Majors extends this to the CTO’s daily practice. The CTO needs independent technical judgment — the ability to evaluate what the team is telling them without relying entirely on trust. "This is one of the reasons that managers need to be technical — so they can cultivate their own independent judgment, instead of basing reviews on hearsay."^[17] The CTO who has lost contact with the codebase is making staffing decisions, performance evaluations, and architectural endorsements based on other people’s assessments of other people’s work. The chain of delegation is long enough to introduce significant distortion.

The practical mechanism for maintaining this proximity is the design document or RFC process. The CTO who reads every RFC — not to approve or block, but to understand the decisions being made and the trade-offs being considered — maintains a current, evolving picture of the system’s direction. Squarespace’s engineering team documents the secondary benefit: "Since the same people review them, the reviewers build up a picture of everything that’s happening in the organization, and can notice overlaps or incompatible initiatives."^[20] The CTO who participates in the RFC process is simultaneously staying technical and performing an organisational function that nobody else in the company can perform: seeing the system as a whole.

The questions the CTO asks in these reviews matter more than the answers they provide. What are the failure modes? What happens at 10x scale? What are we assuming that might change? How does this interact with the decision we made in the authentication service last quarter? These are questions that require technical depth to ask well — but they do not require the CTO to have written the code. They require the CTO to have read it, to understand the architecture, and to hold the system’s history in their head. That is the technical contribution the role demands.

For a decade, the economics of the CTO’s technical involvement pointed in one direction: away from code. Every hour spent coding was an hour not spent hiring, strategising, or communicating with the board. The ROI was unambiguous.

AI is disrupting that calculus. Tobi Lütke, CEO of Shopify, saw his GitHub contributions spike from near-zero to roughly 2,000 in early 2026. Brian Armstrong, CEO of Coinbase, posted publicly: "Beware, it’s 2026 and the CEO is back in the code base thanks to AI."^[21] Larson, after a full decade away from code, completed 104 pull requests — "more pull requests than I’ve completed combined in my prior decade of work" — largely through AI-assisted tools.^[1]

The mechanism is straightforward: AI compresses the activation energy required to engage with code. The CTO who would have spent four hours building a prototype can now do it in forty minutes. The CTO who would have needed half a day to understand a new module can ask an AI assistant to explain it in twenty minutes. The time-versus-value calculation that pushed CTOs away from code is being recalculated in real time.

Kent Beck, who has spent more time than perhaps anyone thinking about how AI changes the practice of programming, draws a critical distinction. "Vibe coding" — the term Andrej Karpathy coined in February 2025 — means accepting AI output uncritically, caring only about the behaviour of the system, not the code. "Augmented coding" — Beck’s term — means caring about the code, its complexity, the tests, and the coverage, while using AI as an accelerator. "In vibe coding you don’t care about the code, just the behavior of the system. In augmented coding you care about the code, its complexity, the tests, and their coverage."^[22]

For the CTO, augmented coding is the right model. The value is not in producing more code faster. It is in maintaining the architectural judgment and system understanding that the CTO role demands — using AI to compress the time required for that understanding. Simon Willison, creator of Datasette and co-creator of Django, captures the principle: "My golden rule for production-quality AI-assisted programming is that I won’t commit any code to my repository if I couldn’t explain exactly what it does to somebody else."^[23] The CTO’s version of this rule: do not approve, endorse, or present any technical decision if you cannot explain the reasoning and the trade-offs to both the engineering team and the board.

Karpathy himself, one year after coining "vibe coding," proposed a more mature term for the professional practice: "agentic engineering" — "agentic because the new default is that you are not writing the code directly 99% of the time, you are orchestrating agents who do and acting as oversight."^[24] The CTO’s role in the AI era is precisely this: orchestration and oversight. The tools write the code. The CTO ensures the code serves the architecture, the architecture serves the product, and the product serves the business.

Addy Osmani, head of Chrome Developer Experience at Google, provides the finding that connects this back to the chapter’s central argument: "AI tools help experienced developers more than beginners."^[25] The CTO’s decades of accumulated judgment — about system design, about trade-offs, about what will break at scale — is the context that makes AI output useful rather than dangerous. The CTO who stays close enough to the technology to provide that context is more valuable in the AI era, not less. The CTO who retreats entirely will find that the AI produces code nobody can evaluate.

Beck’s observation captures the frontier: "Gemini is fast and good for augmented coding. I’m getting done in hours what would have taken me days. It’s a little too fast, though. I need to slow it down so I can learn from what it just did. That’s the frontier of augmented development — maximizing human learning instead of code production."^[22] The CTO’s technical practice is no longer about producing code. It is about maintaining the judgment to evaluate it — and AI, used well, makes that judgment easier to maintain and more consequential to exercise.

The day you stop writing code is not a day. It is a season — a gradual shift that happens as the team grows, as the business demands more of your attention, and as the people you hired become better at the work than you are. The shift is painful because it means letting go of the identity that brought you here. It is also the prerequisite for the identity that keeps you here. The CTO who tries to remain the best coder on the team will eventually be replaced by one. The CTO who becomes the best judge of technical decisions — the guide, the translator, the person who ensures the architecture serves the business — will find that the role grows more interesting, not less, as the company scales.

Chapter 15 addresses what happens when the transition is not managed: the burnout, the isolation, and the financial illiteracy that compound when the CTO tries to do everything — stay technical, manage the team, communicate with the board, and ship the product — without the support structures that make the role sustainable.