Chapter 17: Building Something That Outlasts You
…the Cartographers Guilds struck a Map of the Empire whose size was that of the Empire, and which coincided point for point with it. The following Generations, who were not so fond of the Study of Cartography as their Forebears had been, saw that that vast Map was Useless…
"On Exactitude in Science," 1946
Kellan Elliott-McCrea spent five years as CTO of Etsy. He hired the engineering team, built the technical culture, and shaped the organisation that supported a marketplace used by tens of millions of people. When he left in 2015, he published a farewell post that contains the single most precise articulation of what this book has been arguing: "Successfully building a culture ensures when you leave you can hand your work off to people you trust and they will run the thing without you and make it better than you could have imagined. And building a thing that can be handed off means … you eventually hand it off."[1]
The sentence contains a paradox that every CTO will eventually confront. The measure of success is building something that does not need you. The reward for doing it well is leaving. The CTO who builds a team that cannot function without them has failed — not because the team is weak, but because the CTO confused their own presence with the system’s health. The CTO who builds a team that thrives without them has succeeded — and must accept that the success includes their own obsolescence.
This chapter is about the long view: what the CTO career looks like from a distance, what it means to build something that endures, and what comes after.
The Krieger Model
Mike Krieger co-founded Instagram with Kevin Systrom in 2010. Krieger was the engineer; Systrom was the designer. Together they built a product that reached 30 million users with 13 employees, scaled to a billion monthly active users with a team that grew from 6 engineers to over 450, and became one of the most influential products in the history of consumer technology.[2]
Krieger’s engineering philosophy — "do the simple thing first" — started as survival and became doctrine. "When there were just two of us, we didn’t have the time to do the fanciest, most complete thing," he told Fast Company. "Doing the simple thing first started as a survival tactic, and became a mantra. Today, that phrase is burned into brains of all my engineers."[3] The principle outlasted any particular technical decision. It became a cultural artefact — a way of thinking that persisted even as the people who thought it changed.
What Krieger is proudest of is not the product: "The things that I am proudest of are the team and the culture we built. We didn’t try to do everything, but to do fewer things better."[4] His description of how the engineering organisation matured reveals where the real work happened: "People often see the stage where you’re organized by platform as a necessary evil on the way to product teams. I think it’s actually when you form your engineering culture."[5] The platform stage — the unglamorous period when the team is building shared infrastructure and establishing quality standards — is where the culture that outlasts you is actually created.
In September 2018, Krieger and Systrom announced their departure from Instagram. Their joint statement was brief: "We’ve grown from 13 people to over a thousand with offices around the world, all while building products used and loved by a community of over one billion. We’re now ready for our next chapter."[6] They endorsed Adam Mosseri as their successor and stepped away.
What happened next is instructive. Instagram’s technical culture shifted. The founders’ philosophy of restraint — Krieger once described how incoming engineers from Facebook were surprised they could not "just run a 1% experiment" without scrutiny — gave way to rapid feature proliferation: Reels, Shopping, algorithmic feeds.[5] The product survived. The culture changed. The platform thrived commercially but became something different from what the founders had built.
Krieger’s assessment, years later, carries no bitterness: "Walking away is never a celebration — but it doesn’t have to be a tragedy either."[7] The sentence captures the emotional reality of Chapter 16’s argument. The CTO who builds something that outlasts them must accept that what outlasts them will not be identical to what they built. The culture they created will be adapted, extended, and in some cases overwritten by the people who come after. The test is not whether the organisation preserves the founder’s vision unchanged. The test is whether the organisation can function, adapt, and improve without the founder present. By that measure, Krieger succeeded.
|
AUTHOR: Your reflection on what you are building at CorralData that you hope outlasts your direct involvement. Is it a specific technical culture, a decision-making framework, a team structure? The reader needs to see the question being applied to a company in progress, not just in retrospect. |
Three Case Studies in Durability
Elliott-McCrea’s Etsy provides the first case study. The culture he built — "a culture of learning, a culture of generosity, a culture of values" — survived his departure. His successor, John Allspaw, continued the engineering philosophy. Many of the engineers Elliott-McCrea hired remained for years. But in 2017, activist investors installed a new CEO, Josh Silverman, who replaced both the CEO and CTO and cut 22% of the staff. Employees circulated a petition arguing that the changes represented "a move away from Etsy’s mission and values."[8] The engineering culture that Elliott-McCrea built was durable enough to survive a CTO transition but not durable enough to survive a wholesale leadership replacement by the board. The lesson: culture is resilient but not indestructible. It can be handed off. It cannot be made permanent.
Netflix provides the second case study. The culture deck that Reed Hastings and Patty McCord created in 2009 — which Sheryl Sandberg called "the most important document ever to come out of Silicon Valley" — was a codification of operating principles: freedom and responsibility, context not control, high performance.[9] McCord left Netflix in 2012. Hastings stepped back as co-CEO in January 2023. In June 2024, Netflix released Version 4.0 of the Culture Memo, with 1,500 employee comments incorporated. The culture survived both of its original architects because it was treated as a living document — revised, debated, and adapted rather than preserved as scripture. Hastings himself acknowledged the evolution: "We care about freedom when it generates excellence, not for its own sake. In hindsight, this is the draft I wish we had 15 years ago."[10]
McCord’s own departure provides the third and most paradoxical case. She had built a system that evaluated every employee — including herself — against the question of whether they were the best person for the role the company needed now, not the role it needed when they were hired. When her time came, the system worked exactly as designed. "Eventually, when we worked together at Netflix, Reed and I both had to come to terms with the fact that it was time for me to go," McCord wrote. "Walking away from an exciting future that I wouldn’t be part of was perhaps the most difficult part. But I had tremendous respect for Reed’s discipline to choose his team for the future."[11] The architect of the culture was the culture’s most consequential output. If you truly build something that outlasts you, it functions without you.
Elliott-McCrea captures the principle beneath all three cases: "Technology is the product of the culture that builds it. Great technology is the product of a great culture."[1] The code will be rewritten. The architecture will be replaced. The team will turn over. What persists — if anything persists — is the culture: the shared assumptions about quality, the decision-making norms, the values that shape how the next generation of engineers approaches problems they have not yet encountered.
Jim Collins, in his research on what makes companies endure, identifies what he calls "Level 5 Leadership" — leaders who are "incredibly ambitious, but their ambition is first and foremost for the cause, for the organization and its purpose, not themselves."[12] The distinguishing behaviour of Level 5 leaders, Collins found, is that "they set up successors for success. Many leaders fail to set their companies up for success when they depart, or pick a weak leader to replace them at the helm — after all, what better testament to your own personal greatness than that the place falls apart after you leave?"[12] The CTO who builds a team that collapses without them is not demonstrating their indispensability. They are demonstrating their failure to develop the people and systems that make the organisation self-sustaining. Collins’ language is precise: the highest level of leadership channels ambition "into something that is bigger and more enduring than they are."[12]
The ancient Greeks had a thought experiment for this. If you replace every plank in a ship, one at a time, is it still the same ship? Erik Bernhardsson, former CTO of Better and the engineer who built Spotify’s recommendation system, made the metaphor measurable. He created an open-source tool called Git of Theseus that analyses Git repositories to quantify how code decays over time, and found that code has a measurable half-life — in many mature codebases, roughly half the lines are replaced within three to four years.[13] Slack’s engineering team cited the same paradox when they rebuilt their entire desktop client incrementally in 2019: they replaced every component from jQuery to React without ever shipping a "new version," just continuously swapping planks until no original timber remained. Their question — "If every piece of JavaScript in an app has been replaced, is it the same app?" — was not academic. It was the engineering strategy.[14] The CTO who internalises the Ship of Theseus understands that the codebase they wrote at founding is not the legacy they leave. The legacy is the standard by which each plank is replaced — the engineering culture that determines whether the new timber is better or worse than what it replaces. The code is transient. The judgment embedded in the culture is what endures.
The Fifth Stage
This book’s framework, introduced in Chapter 1, describes four stages of the CTO’s evolution: Coder, Manager, Director, Strategist. Each stage requires the CTO to let go of the activities that defined the previous one. The transitions between stages are where most CTOs struggle — the subject of Chapter 13. The departure from the Strategist stage — voluntary or involuntary — is the subject of Chapters 10 and 16.
There is a fifth stage that the framework does not capture because it extends beyond any single company: the Mentor.
Brad Feld, co-founder of Techstars and Foundry Group, describes the operating principle of this stage as "Give First" — a philosophy he has practiced across four decades in technology. "The concept was that if you want a startup community to really move, you need people willing to put energy in without defining upfront what they’ll get back. It’s not altruism — they’ll get something, but they just don’t know when, from whom, over what time period, or in what form."[15] The Give First principle inverts the economics of the earlier stages, where every hour of the CTO’s time is allocated against measurable business outcomes. In the Mentor stage, the return is diffuse, delayed, and measured in the success of other people’s companies.
Jerry Colonna, who co-founded Flatiron Partners with Fred Wilson before becoming a leadership coach, models the therapeutic dimension of the fifth stage. His core question — "How are you complicit in creating the conditions of your life that you don’t want?" — has become one of the most cited diagnostic tools in startup leadership.[16] Colonna’s argument is that "better humans make better leaders" and that "the process of learning to lead well can help us become better humans."[16] The CTO who has survived the four stages has accumulated a body of knowledge that no book can fully transmit — the pattern recognition, the scar tissue, the judgment that comes from having made consequential decisions under uncertainty for years. The Mentor stage is where that knowledge becomes available to others.
Werner Vogels, who has been CTO of Amazon for more than twenty years, provides the institutional version. In 2024, he launched the "Now Go Build" CTO Fellowship — a programme that pairs experienced technical leaders with mission-driven organisations working on disaster relief, climate change, and public health.[17] His blog, All Things Distributed, has become one of the most influential technical leadership publications in existence. The Mentor stage, in Vogels’ model, is not retirement from the CTO role. It is an extension of it — the CTO’s accumulated judgment applied at a scale that no single company can contain.
CTO Craft, founded by Andy Skipper in 2017, has formalised the peer-mentoring dimension of the fifth stage. Its Mentoring Circles — year-long programmes of six to eight senior technology leaders led by experienced former CTOs — represent the infrastructure that Chapter 15 argued every CTO should build before they need it.[18] The 18,000 members of the CTO Craft community are, collectively, the fifth stage made institutional: a network of people who have done the job, who understand its specific pressures, and who are willing to share what they learned.
|
AUTHOR: Your vision for your own fifth stage — even if it is decades away. Are you already mentoring other CTOs, advising startups, contributing to the community? The reader needs to see the trajectory from their current stage toward this horizon. |
Building Your Reputation While Building the Company
The CTO who waits until they leave the role to build a professional reputation has waited too long. The attention economy does not pause for career transitions, and the CTO’s next opportunity — whether it is a larger company, another startup, a fractional practice, or an investor role — will depend on a reputation built during the years they were too busy to think about it.
Stephan Schmidt, who has coached dozens of CTOs through transitions, identifies the four factors that determine a CTO’s market position: the names of the companies they have worked for, the size of the teams they have managed, the problems they have solved, and their personal brand — what they are known for beyond their title.[19] The first three accrue naturally through the work. The fourth requires deliberate effort — and it is the one most CTOs neglect, because the effort feels self-promotional in a culture that values building over talking. The tension is real. Time spent on conference talks, blog posts, and LinkedIn is time not spent on the company. But the CTO who never surfaces beyond the company’s walls becomes invisible to the market at precisely the moment they need to be visible. Chris Reed, author of How to Become a LinkedIn Rock Star, frames the arithmetic: only 1% of users post original content, and 90% only read. The bar for standing out is lower than most CTOs assume.[20]
The practical mechanics: a quarterly conference talk at a CTO-adjacent event (LeadDev, QCon, CTO Craft); a monthly blog post or newsletter on a topic where the CTO has genuine expertise; an active GitHub presence that demonstrates technical currency; and a LinkedIn profile that reads as a professional narrative rather than a résumé. None of these requires more than five hours per month. All of them compound. The conference talk becomes a recruiting tool (every talk is an advertisement for the engineering culture). The blog post becomes a reference in a board presentation. The GitHub activity signals to the next hiring committee that the CTO has not drifted into pure management.
The Four Paths After the Title
The career paths after the first CTO role cluster into four patterns. The first is the serial CTO — doing the founding role again at a different company, deliberately choosing to operate in the 0→1 or 1→10 stage. Chapter 16 covers this path in detail through Hockey, Hediard, and others. The second is the CTO at a larger company — the seed-stage CTO who moves to a Series B or C company where the role demands less building and more organisational leadership. The skills gap is real: Ben Jones of OutStride Coaching observes that "the CTO that is perfect for an early-stage startup might be terrible for a later stage startup," and search firms like Riviera Partners evaluate candidates specifically on their ability to operate at the target stage, not just the stage they came from.[21]
The third path is the fractional CTO — working part-time for multiple companies simultaneously. Gergely Orosz profiled Sergio Pereira, a three-time founder and five-time CTO who has served as fractional CTO for more than ten companies, in The Pragmatic Engineer. The typical engagement runs 10–25 hours per week for six months to three years, at compensation between $150,000 and $300,000 annually depending on hours and equity. The fractional CTO market has grown to roughly 120,000 practitioners as of 2024.[22] Schmidt advises that a startup should hire a fractional CTO when "you’re making technology decisions without someone experienced to check them" and a full-time CTO is still 12–18 months away.[23] For the ADHD CTO described in Chapter 16, the fractional path has an additional appeal: the variety and novelty of multiple clients maps well to the attention profile, and the shorter engagement cycles reduce the risk of the boredom-driven departure that Chapter 1 described.
The fourth path is the transition to investing or advising. Mike Schroepfer left the CTO role at Facebook after a decade to launch Gigascale Capital, a climate-focused venture fund. Adrian Mendoza moved from founder-CTO to General Partner at Mendoza Ventures, where his technical background informs deal evaluation in AI, fintech, and cybersecurity.[24] The CTO-to-investor pipeline is well established: the technical judgment that made the CTO effective at evaluating architecture, assessing team capability, and identifying technical risk is precisely what makes a good VC technical due diligence partner. The less common path — CTO to CEO — is statistically rare (McKinsey data shows fewer than 15% of CEOs rose from functional leadership positions) but increasingly viable in the AI era, where technical fluency is a competitive advantage at the top of the organisation.[25]
The common thread: none of these paths requires starting over. The architectural judgment, the ability to translate between technical and business audiences, the pattern recognition for what works at startup scale — these are portable. The CTO who builds their reputation while building the company arrives at the transition with options. The CTO who does not arrives with a title and a gap on their LinkedIn.
|
AUTHOR: Your own approach to professional visibility — conference talks, blog writing, the TTNW newsletter, open-source contributions. What has worked, what you would do differently, and what advice you would give to a fellow CTO who is too busy building to think about reputation. The reader needs permission to invest time in their professional identity. |
The Role That Keeps Changing
Chapter 12 addressed AI’s impact on the CTO’s operational reality. Here, the question is different: what does the CTO role look like in five years, ten years, twenty?
The trajectory is clear even if the destination is not. Garry Tan’s observation that a quarter of current Y Combinator startups have 95% of their code written by AI signals a structural shift in what the CTO manages.[26] The CTO of 2030 will likely oversee a smaller engineering team augmented by AI systems that handle implementation at a speed and scale that human teams cannot match. Pranava Adduri, CTO of Bedrock Data, describes the emerging model: "The core job becomes deciding which problems are best solved by our skilled engineers, which can be accelerated with AI tools, and which parts of the stack we should just buy. It’s about designing the most efficient system of people and technology."[27]
The shift elevates the CTO’s strategic function while compressing the management function. Nick Durkin of Harness puts it directly: "By 2026, every engineer effectively becomes an engineering manager. Not of people, but of AI agents."[28] The CTO who once managed fifty engineers may manage ten engineers who each orchestrate dozens of AI agents. The skills that matter in that world — architectural judgment, business translation, team culture, strategic vision — are the skills this book has been describing. The operational details will change. The fundamentals will not.
What will not change is the CTO’s core responsibility: building the system — technical, organisational, cultural — that allows a company to create value from technology. The tools will change. The team structures will change. The speed at which decisions must be made will accelerate. But the question that defines the role will remain the same: are you building something that works without you?
Elliott-McCrea’s final lesson from his Etsy farewell applies beyond any single company or career stage: "Invest in your people and your ability to ask questions, not your current answers."[1]
The answers change. The technology changes. The companies change. What persists is the practice — the discipline of building teams that can think for themselves, making decisions that prioritise reversibility over elegance, communicating in the language of the people you serve, and maintaining the relationships and the health that allow you to do this work for as long as it matters.
This book began with a premise: that the startup CTO role is the most consequential and least understood position in the technology industry. The CTO who arrived in the role by accident (Chapter 2), who navigated the co-founder relationship (Chapter 3), who made technical decisions as business decisions (Chapter 4), who managed debt strategically (Chapter 5), who shipped continuously (Chapter 6), who handled the pressure to move faster (Chapter 7), who learned to work with product (Chapter 8), who measured what mattered (Chapter 9), who learned to speak the language of the business (Chapter 10), who built a team (Chapter 11), who adapted to AI (Chapter 12), who grieved the loss of their technical identity (Chapter 13), who built an operating rhythm (Chapter 14), who survived the loneliness and the burnout (Chapter 15), and who knew when to step aside (Chapter 16) — that CTO has done something rare. They have built something that outlasts them.
The work matters beyond any single company or product. The teams you build will go on to build other teams. The culture you create will shape the culture of companies that do not yet exist. The engineers you mentor will become CTOs who mentor engineers you will never meet. The decisions you make today — about quality, about people, about what kind of organisation you are building — will compound across decades and generations of builders.
That is the legacy. Not the code. Not the architecture. Not the title. The people, and what they go on to build.
You are an alchemist; make gold of that.
Timon of Athens
Frequently Asked Questions
-
What legacy should a CTO aim to leave behind?
The most lasting CTO legacy is not code or architecture — it is the team you built, the culture you established, and the engineers you mentored. Code gets rewritten, architectures get replaced, but the people you developed go on to build other teams and companies. The CTO who invests in growing leaders creates a compounding legacy that extends far beyond any single product or technology decision.
-
How do you build an engineering culture that outlasts you?
Encode your values into systems rather than relying on your personal presence. This means establishing code review standards, incident response processes, hiring practices, and promotion criteria that reflect the culture you want — and that operate the same way whether you are in the room or not. Culture that depends on a single leader is personality, not culture. Culture that is embedded in processes, rituals, and shared expectations persists after the leader is gone.
-
What makes a CTO’s impact last beyond their tenure?
The engineers you mentor become CTOs who mentor other engineers. The culture you create shapes the cultures of companies that do not yet exist. The decision-making frameworks you establish — how to evaluate trade-offs, how to communicate technical decisions, how to handle incidents — become the default approach for everyone you have trained. Impact that lasts is always about people and judgment, never about specific technologies or codebases.
-
How do you transfer knowledge when leaving a CTO role?
Go beyond documentation of systems and processes — transfer your judgment frameworks. Write decision logs and architecture decision records that explain not just what was decided but why, what alternatives were considered, and what trade-offs were accepted. Create runbooks for recurring decisions. Pair with your successor on real decisions during an overlap period. The goal is to transfer the thinking behind the decisions, not just the decisions themselves.
-
What is the most important thing a CTO can build?
A team that thinks for itself and maintains high standards without you. The ultimate measure of a CTO’s success is what happens after they leave — whether the team continues to make good decisions, maintain quality, ship reliably, and grow. If the engineering organisation falls apart when the CTO departs, the CTO built a dependency, not a team. If it thrives, the CTO built something that outlasts them.