Chapter 11: Building the Team
If you want to build a ship, don’t drum up people to collect wood and don’t assign them tasks and work, but rather teach them to long for the endless immensity of the sea.
Citadelle, 1948 (paraphrased)
David Mack, co-founder and CTO of SketchDeck, a Y Combinator-backed startup, wrote a retrospective after several years in the role that captures something most CTO guides skip entirely. "No matter how many times I’ve read about how a company’s most important asset are the people, it never prepared me for how exhausting and excruciating hiring is. To anyone new to hiring: you probably need to spend more time hiring and reject more people. You probably need to filter more stringently. I never could have guessed how rare the perfect startup team member is, nor how much time and effort would be needed to find them."[1]
The exhaustion is not incidental. It is the job. The startup CTO who spends 20% of their time on hiring — Patrick McKenzie’s recommended minimum for founders — is doing the single most consequential activity available to them.[2] The code the CTO writes will be rewritten. The architecture they design will be refactored. But the people they hire will hire the next people, who will hire the people after that. Patrick Collison, co-founder of Stripe, makes this explicit: "You aren’t just hiring those first ten people, you are actually hiring a hundred people because you think each one of those people are going to bring along another ten people with them."[3]
This chapter is about how to hire those first ten people, how to organise them into a team that ships, and how to build the culture that sustains the team after the CTO is no longer the person writing most of the code. Chapter 10 argued that the CTO’s biggest threat is a communication gap. This chapter applies that insight to the most consequential communication challenge: articulating what the team should be, who belongs on it, and how it should work — in language that both engineers and the business can evaluate.
Competing Without Brand, Salary, or Perks
The startup CTO is recruiting against companies that can offer twice the salary, a recognised name on the CV, and an infrastructure team that handles everything the engineer does not want to think about. The startup can offer none of this. What it can offer — and what the research shows actually motivates the engineers worth hiring — is something else entirely.
Michael Roach and Henry Sauermann, in a study published in Management Science in 2023 that tracked more than 2,300 science and engineering PhDs over their early careers, found that high-ability graduates who join startups earn roughly 20% less than peers who join established firms. They join anyway. The motivators are autonomy, the opportunity to work on problems that matter, and the scope of impact: "For some high-ability tech workers, there’s more significance to being employee number 20 than employee number 2,000."[4]
The CTO who leads with salary will lose every negotiation. The CTO who leads with the problem — the specific, concrete, technically interesting problem the company is solving and the engineer’s role in solving it — is competing on the axis where the startup has an advantage. Collison describes Stripe’s approach: the first five hires took almost two years because the bar was not just technical ability but alignment with the problem the company was trying to solve.[3] Joel Spolsky’s hiring framework, first published in 2000 and still cited two decades later, reduces the evaluation to two questions: "Smart, and gets things done." Smart alone produces engineers who think but do not ship. Gets-things-done alone produces engineers who ship but accumulate debt. The intersection is rare — which is why the hiring process is exhausting.[5]
The practical mechanics of early-stage hiring are unglamorous. There is no recruiter. The CTO is the recruiter. McKenzie’s approach at MakeLeap in Tokyo is instructive: he started a Hacker News meetup, held 50 events, and eventually found five hires for a total cost of $300 — compared to $25,000 per placement through a recruiting firm. Matasano Security created the Cryptopals cryptography challenges, which took two weeks to develop and surfaced candidates from unexpected backgrounds, including a chemistry teacher who solved the problems in Excel.[2] The common principle: build a channel that attracts people who are interested in the problem your company solves, and hire from the community that forms around it.
Eric Feng, former CTO of Flipboard, provides the funnel math that every startup CTO should internalise: to hire a single engineer, start with roughly 64 candidates at the top of the funnel.[6] At a company with no brand recognition, the funnel is even wider. The CTO who expects to post a job listing and receive qualified applicants is operating with a model that works for Google and fails for everyone else.
Gergely Orosz, surveying startup founders and former big-tech engineers for The Pragmatic Engineer, documents a specific hiring trap: the temptation to recruit from FAANG companies based on pedigree. One anonymous founder of a data startup describes the result: "Some of our hires from Google wanted to replicate all Google’s processes and culture, and completely failed. One staff engineer was the worst hire I can remember." A former Google engineer who made the transition observes the gap from the other side: "Most FAANG engineers I’ve met do years of work without ever talking to a customer."[7] The startup CTO is not hiring for the ability to operate within Google’s infrastructure. They are hiring for the ability to operate without it — to build systems from scratch, to talk to customers, to make decisions with incomplete information, and to ship with a sense of urgency that most large-company environments actively discourage.
The cost of getting this wrong at the early stage is disproportionate. A bad hire on a six-person team represents 16% of the entire workforce. They do not just underperform — they reshape the culture, consume the CTO’s management capacity, and demoralise the engineers who are performing. Sam Altman’s advice from his time as president of Y Combinator is blunt: "Fire quickly. Everyone knows this in principle and no one does it."[8] The emotional difficulty of firing someone the CTO personally recruited, in a team small enough that everyone eats lunch together, is one of the hardest experiences in the role. Mack’s reflection applies: "If you feel uncertain if you need to hire a particular role, it’s probably too early."[1]
|
AUTHOR: CorralData’s hiring experience — how did you find your first engineers? What worked, what did not? In healthcare B2B, the talent pool has specific constraints: compliance familiarity, domain knowledge, willingness to work with healthcare data. What was the recruiting channel that actually produced hires? |
Org Design Is System Design
In 1968, Melvin Conway submitted a paper to the Harvard Business Review arguing that the structure of an organisation determines the structure of the systems it produces. HBR rejected it on the grounds that he had not proved his thesis. The paper was published in Datamation instead, and the principle it described — "Any organization that designs a system will inevitably produce a design whose structure is a copy of the organization’s communication structure" — became one of the most cited observations in software engineering.[9]
Fred Brooks named it Conway’s Law in The Mythical Man-Month in 1975. Martin Fowler, writing in 2022 after decades of observing the principle in practice, states: "If there is one thing they all agree on, it’s the importance and power of Conway’s Law. Important enough to affect every system I’ve come across, and powerful enough that you’re doomed to defeat if you try to fight it."[10]
The implication for the startup CTO: the team you build literally determines the architecture you ship. A team of three generalists working in one room will produce a monolith. A team split into frontend, backend, and data will produce three services with an integration layer. Neither is inherently wrong — what matters is that the CTO is making the organisational choice consciously, understanding that it is simultaneously an architectural choice.
The Inverse Conway Maneuver, coined by Jonny LeRoy and Matt Simons at ThoughtWorks in 2010, takes this further: rather than letting the org chart dictate the architecture, deliberately structure teams to produce the architecture you want.[11] Nicole Forsgren’s DORA research validated this empirically: "Organizations should evolve their team and organizational structure to achieve the desired architecture."[11]
Jeff Bezos institutionalised this principle at Amazon with the two-pizza team: autonomous groups of fewer than ten people, small enough to be fed with two pizzas. The logic was not about pizza. It was about communication overhead. Bezos, as documented in Brad Stone’s The Everything Store, argued that "Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way."[12] The two-pizza team was designed to minimise the communication paths that Conway’s Law says will be reflected in the system architecture.
Will Larson provides the most practical team-sizing guidance for startups. His principle: "Teams should be six to eight during steady state. To create a new team, grow an existing team to eight to ten, and then bud into two teams of four or five. Never create empty teams." His warning about small teams is emphatic: "I’ve sponsored quite a few 1-2 person teams, and each team I’ve regretted. To repeat: I have regretted it every single time." Teams of fewer than four, Larson argues, are "a sufficiently leaky abstraction that they function indistinguishably from individuals."[13]
Matthew Skelton and Manuel Pais, in Team Topologies (2019), formalised the types of teams that a scaling organisation needs: stream-aligned teams (focused on a single flow of work, such as a product feature or user journey), platform teams (providing internal services that stream-aligned teams consume), enabling teams (helping other teams adopt new capabilities), and complicated-subsystem teams (owning components that require deep specialist knowledge). Fowler’s assessment: "All models are wrong, some are useful. Thus Team Topologies is wrong — complex organizations cannot be simply broken down into just four kinds of teams and three kinds of interactions. But constraints like this are what makes a model useful."[14]
The Spotify squad model — which organised engineers into cross-functional squads within tribes, with chapters and guilds providing cross-cutting alignment — became the most imitated organisational structure in tech after Henrik Kniberg documented it in 2012. It also became one of the most cautionary tales. Jeremiah Lee, a former Spotify employee, published a detailed critique in 2020: "Spotify tried a long-lived matrix team structure with unusual word choices. It did not work well."[15] Joakim Sundén, a Spotify agile coach from 2011 to 2017, was more pointed: "People have really struggled to copy something that didn’t really exist."[15]
The lesson for the startup CTO is not that squads are bad or that two-pizza teams are good. It is that organisational structure is not something to borrow from a company blog post. It is something to design for the specific communication patterns the CTO needs, understanding that those patterns will be reflected directly in the system the team produces.
|
AUTHOR: How CorralData’s team is currently structured — and how that structure reflects the product architecture. Is there a one-to-one mapping between team boundaries and system boundaries? Has Conway’s Law been visible in your experience? The healthcare B2B context may introduce specific organisational constraints: a dedicated compliance function, a data engineering team handling HIPAA-governed pipelines. |
The First VP of Engineering Hire
There is a moment in every startup’s growth when the CTO realises they are spending all their time on management and none on technology. Daniel Doubrovkine, CTO of Artsy, created a public Slack channel logging his weekly activities and discovered that the vast majority were consumed by people management and product coordination. "I was not able to make time to raise my head and to look at anything further on the horizon," he wrote. "I needed help."[16]
That help is a VP of Engineering. The role is the CTO’s complement: the CTO owns the technical direction; the VPE owns the team that executes it. Fred Wilson, co-founder of Union Square Ventures, provides the canonical distinction: "A VP Engineering is ideally a great manager and a great team builder. A CTO is ideally the strongest technologist in the organization." The ideal: "When a company has a strong CTO and a strong VP Engineering that trust, respect, and like each other, you have a winning formula."[17]
Mark Suster, a venture capitalist at Upfront Ventures who was twice a startup founder, provides the timing guidance: "If I were a pure startup with 5 people I’d want a Chief Architect. As the company and therefore the team size grew I’d want a VP of Engineering. For me the inflection point is usually when you have 5+ developers."[18] Most practitioners cite 10 to 25 engineers as the range where the hire becomes urgent. Fred Wilson’s test is simpler: "When you feel you aren’t managing your eng team well enough."[17]
The hire can go wrong in specific, predictable ways. Julia Austin, a former VP of Engineering who teaches at Harvard Business School, describes the pattern: "A company I advise wanted to understand how their VP Engineering hire could be let go after only one quarter. They hired a deep technology-focused leader when they needed an empathetic people leader to scale the organization."[19] The mistake is hiring a second CTO when the company needs a people manager. Cheryl Liew, who worked at Riviera Partners, a technical executive search firm, documents the extreme case: at Clinkle, a startup that raised a $25 million seed round, VP of Engineering Chi-Chao Chang quit after less than 24 hours because the company was too secretive about the state of its product.[20]
Camille Fournier, who was CTO of Rent the Runway and later wrote The Manager’s Path, provides the most important warning for the CTO making this hire. Many CTOs, she observes, give up all management responsibilities to their VPE, "sometimes going so far as to not even have the VPs reporting to them." The consequence: "It is incredibly difficult to maintain influence and effectiveness as an executive with no reporting power. If you give up management, you’re giving up the most important power you ever had over the business strategy."[21]
The VPE hire is not a delegation of authority. It is a division of labour. The CTO retains accountability for the technical direction, the architecture, and the strategic communication with the board. The VPE takes ownership of team health, recruiting operations, process design, and execution cadence. Doubrovkine’s approach was deliberate: he catalogued his activities, identified the ones that a great people-and-process leader could own, and hired specifically for those. His Artsy colleague received an internal announcement that made the division explicit.[16]
Brad Feld, co-founder of Foundry Group, provides the complementary warning from the investor’s perspective: "The great CTO’s usually can’t manage their way out of a paper bag, but have huge vision, the ability to pull an all-nighter and crank out a rough prototype of the thing they are thinking about."[22] The investor is not insulting the CTO. The investor is observing that the skills that made the CTO effective at five people — deep technical ability, the willingness to build everything personally, the instinct to solve problems in code — are not the skills that make the CTO effective at fifty. The VPE hire is the structural acknowledgment of that transition.
|
AUTHOR: CorralData’s experience with this transition — have you hired (or considered hiring) a VPE? At your current stage, what does the division of labour look like? What would change if you had a strong people-and-process leader on the team? The reader at your stage needs to see the decision being considered, not just the theory. |
Managing Engineers Who Are Smarter Than You
Allan Leinwand, CTO of Shopify, asks the question that every growing CTO confronts: "How do I gain the credibility of the really smart people on my team who are far more technical and detailed than I am, in order to lead them?"[23] His answer begins with an uncomfortable admission: "I hate to break this to you, but when you climb the CTO ladder you’re not going to be pushing new code to production very much, if ever."[23]
The CTO’s technical skills erode as their management responsibilities expand. Charity Majors, CTO of Honeycomb, describes this as a law of the role: "Your technical skills stop advancing when you become a manager, and instead begin eroding. Two years in, you aren’t the effective tech lead you once were; your information is out of date and full of gaps."[24] This is not a failure. It is the expected trajectory. The CTO who tries to remain the best coder on the team is competing with their own engineers rather than enabling them.
The goal — the sign that the CTO is succeeding — is a team where multiple engineers are technically stronger than the CTO in their respective domains. The CTO’s value shifts from producing code to producing the conditions under which the best engineers can do their best work. Leinwand’s observation is worth internalising: "ICs also have a lot of influence and power — at times, I actually think that ICs have more power than those of us in leadership roles."[23]
Will Larson’s Staff Engineer identifies four archetypes for senior individual contributors: the Tech Lead, who guides one team’s approach and execution; the Architect, who owns technical direction across a critical area on a multi-year horizon; the Solver, who troubleshoots the hardest problems and then transitions solutions to other teams; and the Right Hand, who serves as a strategic advisor to senior leadership.[25] The CTO’s relationship to each archetype is different. The Tech Lead needs autonomy within a defined scope. The Architect needs alignment on the long-term vision. The Solver needs access to the hardest problems. The Right Hand needs trust and context.
Tanya Reilly’s concept of "glue work" — the invisible labour of coordination, documentation, onboarding, and cross-team facilitation — is essential to how the CTO thinks about senior IC contributions. “Your job title says ‘software engineer’, but you seem to spend most of your time in meetings,” Reilly writes. "Congratulations: you’re the glue." The danger: glue work is the difference between a project that succeeds and one that fails, but it is systematically undervalued because it does not produce code.[26] The CTO who evaluates engineers solely on code output will lose the engineers who make everyone else productive. Dan North’s observation from Chapter 9 applies directly: "Your highest-value developers are 10x by enabling other developers. Often the least useful thing they can be doing is producing code themselves."
Pat Kua, former CTO of N26, provides the structural framework: the Trident Model, which defines three career tracks — Management, Technical Leadership, and Individual Contributor. The key insight is the middle track. Kua argues that the "IC track" label is misleading because most organisations need technical leadership, not just individual contribution. "People in this track must have relevant hands-on technical skills and experience. They should have good but not necessarily the best skills in the team they are leading."[27] The CTO who builds a technical leadership track — distinct from both the management track and the pure IC track — creates a path for the engineers who want to lead without managing, which is the path that most of the strongest engineers prefer.
Fournier identifies the failure mode that the CTO must avoid in themselves: the "alpha geek" — "someone who values intelligence and technical skills above all other traits, who always makes it seem like they have all the right answers." The alpha geek CTO cannot lead engineers who are smarter than them because the CTO’s identity is built on being the smartest person in the room. The secure CTO — the one who has internalised that their value is in judgment, context, and communication rather than raw technical output — can hire engineers who are better than them and be genuinely delighted about it. That delight, more than any hiring framework or org chart, is the signal of a CTO who has made the transition from builder to leader.[21]
|
AUTHOR: Your experience managing engineers who are stronger than you in specific technical domains — at CorralData or in prior roles. How do you evaluate work you can no longer do yourself? How do you maintain credibility? The reader who is transitioning from "best coder" to "leader of coders" needs to see this done in practice. |
Culture Is a System
Kellan Elliott-McCrea spent five years as CTO of Etsy. When he left in 2015, he wrote a retrospective that reframes culture in terms that every engineer should recognise. "Technology is the product of the culture that builds it. Great technology is the product of a great culture." His approach was to treat culture as a system — a series of hypotheses to be tested, iterated on, and refined. "The goal was always to build a culture — a culture of learning, a culture of generosity, a culture of values. Culture infects everyone. 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."[28]
That last sentence is the chapter’s thesis: the CTO’s job is to build a team that ships without them. Elliott-McCrea achieved this by treating culture not as a set of values to be declared but as a set of behaviours to be designed. "Culture is what you do, not what you say. It starts at the top. It affects everything. You have a choice about the culture you promote, not about the culture you have."[28]
Ron Westrum’s typology, which the DORA research adopted and validated, provides the diagnostic framework. Organisations fall into three cultural categories: pathological (power-oriented, where messengers are shot and failure is punished), bureaucratic (rule-oriented, where messengers are tolerated and failure triggers process), and generative (performance-oriented, where messengers are trained, failure triggers inquiry, and novelty is implemented).[29] The DORA data shows that generative cultures consistently outperform the other two on software delivery metrics — which means culture is not a soft, unmeasurable concern. It is a leading indicator of engineering performance.
The practical implication for the startup CTO: the culture is forming whether the CTO designs it or not. Jason Fried, co-founder of Basecamp, puts it directly: "You don’t create a culture. Culture happens. It’s the by-product of consistent behavior."[30] The CTO who does not make deliberate choices about how the team communicates, how decisions are made, how failures are handled, and how recognition is distributed will end up with the culture that forms by default — which is usually the culture of the loudest or most political person on the team.
Netflix’s culture deck, which Sheryl Sandberg once called "the most important document ever to come out of the Valley," provides one model: radical transparency, high performance expectations, and generous severance for adequate performers. The model produces extraordinary output and, as Harvard Business School researchers documented, a state of paranoia among some employees about being terminated.[31] The CTO should study it as an existence proof — culture can be engineered — not as a template. Netflix was a mature company when it published the deck. A five-person startup that fires people for "adequate performance" will have no people left.
Molly Graham, who helped scale Google from 25 to 125 people in nine months and later served as COO of Quip, articulates the specific emotional challenge of culture during rapid growth: “As you add people, you go through this roller coaster of, ‘Wait, is that new person taking my job? What if they don’t do it the right way? What if they’re better than me at it?’” Her advice: "If you personally want to grow as fast as your company, you have to give away your job every couple months."[32] The CTO who hoards responsibilities — who remains the sole code reviewer, the sole architecture decision-maker, the sole point of contact for the CEO — is not protecting quality. They are creating a bottleneck that will break when the company outgrows their capacity.
Claire Hughes Johnson, who was COO of Stripe during its growth from 200 to more than 7,000 employees, frames the cultural infrastructure as an "operating system" — the set of norms that outline how the company functions, including mission, long-term targets, key values, and team charters.[33] The CTO does not need to build this alone. But the CTO needs to ensure that the engineering team’s operating system — how code is reviewed, how decisions are documented, how on-call rotations work, how technical debt is prioritised — is explicit rather than implicit. Implicit norms work at five people. They break at fifteen. They are lethal at fifty.
The mechanism of failure is specific: during rapid hiring, new employees learn culture from other recently hired employees who may not have had time to learn the actual culture themselves. Mudassir Sheikha, co-founder of Careem, describes the result: "As you hire rapidly, new hires learn culture from other recently hired staff who may not have had time to learn how things work at your company. Instead, they transmit values they learned in previous roles."[34] This is culture dilution — and the only defence against it is making the culture explicit enough that a new hire can absorb it from documentation and observed behaviour rather than from the person who joined two weeks before them.
|
AUTHOR: CorralData’s culture — what are the explicit norms? How do you handle failure, recognition, and decision-making? Is the culture documented or implicit? A specific example of a cultural norm that you designed deliberately — and one that formed without your input — would ground this section. |
Building for the AI Era
Chapter 12 examines the AI transformation in full. Here, the concern is specific: AI is changing what the CTO should hire for.
Garry Tan, CEO of Y Combinator, reported in early 2025 that for roughly a quarter of the current YC batch, 95% of code was written by AI. Companies are reaching $10 million in revenue with teams of fewer than 10 people.[35] Revelio Labs data, reported by CNBC, shows that median headcounts at similar-stage startups have dropped 17.5% — from 57 to 47 employees — while median funding per employee has roughly doubled.[36] The Leonis AI 100, benchmarking the most important AI startups of 2025, found that 86% of founders across the top 100 AI companies are technical — compared to 59% in the previous generation of unicorns.[37]
Tobi Lütke, CEO of Shopify, made the organisational implication explicit in an internal memo shared publicly in April 2025: "Using AI effectively is now a fundamental expectation of everyone at Shopify. Teams must demonstrate why they cannot get what they want done using AI before asking for more headcount and resources."[38]
The hiring implication is not that the CTO should hire fewer engineers. It is that the profile of the engineer worth hiring has shifted. Kent Beck, describing his own experience with AI coding tools, frames the change: "I make more consequential programming decisions per hour, fewer boring vanilla decisions."[39] The engineer who thrives in the AI era is not the one who writes the most code. It is the one who makes the best decisions about what to build, how to structure it, and when the AI’s output needs to be overridden.
Laura Tacho, CTO of DX, provides the most rigorous data on what this looks like in practice. Across 180 companies and 67,000 developers, her research shows that AI-authored code now makes up roughly 27% of all production code, and onboarding time for new engineers has been cut in half — measured by time to the tenth pull request.[40] But the outcomes diverge dramatically by team: "Some companies are dealing with twice as many customer-facing incidents, while others see a 50% drop. The difference comes down to how AI is used."[40]
That divergence is a hiring signal. The CTO is no longer hiring engineers who can write code. They are hiring engineers who can evaluate, direct, and override AI-generated code — which requires stronger architectural judgment, deeper domain knowledge, and better communication skills than the pre-AI era demanded. Beck’s observation about junior engineers is counterintuitive and important: "The junior bet has gotten better. Not because juniors have changed, but because the genie, used well, accelerates learning."[39] The junior engineer who can collaborate effectively with AI tools compresses their ramp dramatically. The one who cannot is producing AI-generated debt at scale.
|
AUTHOR: How AI has changed hiring at CorralData — are you looking for different skills than two years ago? Has the team size changed relative to what you would have expected without AI tools? In the healthcare context, domain knowledge may have become more important relative to raw coding ability, since AI can handle the code but cannot handle the compliance judgment. |
Hire Slowly, Fire Fast
The phrase is a cliché because it is correct. At a ten-person startup, one bad hire is ten percent of the company. At IBM, one bad hire is a rounding error. The mathematics of small teams means that every hiring mistake has an outsized impact on culture, velocity, and morale — the wrong person does not simply underperform, they change the behaviour of everyone around them. Sam Altman’s guidance to YC companies is characteristically blunt: "Don’t compromise on the quality of people you hire. Everyone knows this, and yet everyone compromises on this at some point during a desperate need. Everyone goes on to regret it, and it sometimes almost kills the company."[8]
The "hire slowly" half means resisting the urgency that every startup feels. The temptation is to fill the seat — any seat — because the team is overwhelmed and the backlog is growing. The CTO who hires the first person who clears a low bar has solved the headcount problem and created a culture problem. Altman again: "Good and bad people are both infectious, and if you start with mediocre people, the average does not usually trend up. Companies that start off with mediocre early employees almost never recover."[8]
Known Quantities
One of the strongest advantages the founding CTO has is their professional network. People you have worked with before — former colleagues, collaborators, engineers from previous companies — are a known quantity in a way that no interview process can replicate. You have seen how they handle pressure, how they communicate under ambiguity, whether they ship or merely discuss shipping. The reduced risk of a network hire is real: you are betting on observed behaviour rather than interview performance, and those are very different things.
The caveats are equally real. First, you must still interview them. The relationship should not bypass the process. The person you knew as a brilliant engineer at your last company may not be the right engineer for your current company — the stage is different, the domain is different, and the role may require skills you never saw them exercise. Second, if you and the candidate are too close — friends, former housemates, the kind of relationship where objective evaluation is compromised — bring in a neutral third party to run the technical interview. Pay an external interviewer if you need to. The cost of a clean read is trivial compared to the cost of a bad hire you made because you could not bring yourself to see the red flags in a friend. Third, and most importantly: hiring exclusively from your network reproduces your demographics, your perspectives, and your blind spots. The CTO who builds a team entirely from former colleagues has built a team that thinks like them — which is comforting in the short term and dangerous in the long term, because the problems the company will face are not the problems the CTO has already solved.
|
AUTHOR: Your experience hiring from your network at CorralData. Have you brought in former colleagues? How did you handle the interview process with people you already knew? Any examples where the known-quantity advantage played out — or where familiarity blinded you to a mismatch? |
Trusting Your Gut — and Checking It
Altman offers the sharpest hiring heuristic in the startup canon: "Trust your gut on people. If you have doubt, then the answer is no."[8] The principle is sound. Experienced managers develop pattern recognition about fit that operates faster than conscious analysis — a sense that something is off, a feeling that the person will not thrive, an instinct that the interview performance does not match the real capability.
The problem is that gut instinct encodes every bias the CTO carries. The engineer who does not make eye contact may be neurodivergent, not disengaged. The candidate who seems "not a culture fit" may simply not look or sound like the rest of the team. The woman who asks about work-life balance may be doing exactly what a man with the same question would be praised for: establishing healthy boundaries. The CTO who trusts their gut without examining what their gut has been trained on will build a team that reflects their biases rather than their values.
The practical solution is not to ignore the gut but to interrogate it. When you feel doubt about a candidate, write down the specific behaviours or responses that triggered it. If you cannot articulate the concern in concrete terms — "they could not explain how they would approach the data migration problem" rather than "something felt off" — the doubt may be bias rather than signal. Structured interviews with consistent questions and rubrics help here: they force evaluation against criteria rather than against the CTO’s unconscious model of what a good engineer looks and sounds like.
When It Is Not Working
The "fire fast" half is where most CTOs fail. The pattern is always the same: the CTO senses within the first month that a hire is not working out. They wait. They hope it will improve. They give the benefit of the doubt. They tell themselves the person needs more time. Three months pass. Six months pass. The underperformance is now visible to the entire team, and the team is watching to see whether the CTO will act.
Kim Scott’s Bob story from Radical Candor — already cited in this chapter — is the canonical cautionary tale. But the cost is not just the underperformer’s output. The cost is what happens to everyone else. The team sees the standard being lowered. The high performers start wondering whether excellence is rewarded or merely expected while mediocrity is tolerated. The cultural message is unambiguous: performance does not matter here as much as the CTO says it does. One person in the wrong seat at a ten-person startup produces the same cultural damage as a hundred people in the wrong seats at a thousand-person company — because at a startup, everyone can see everything.
Altman’s advice is simple: "Fire quickly. Everyone knows this in principle and no one does it. Also, fire people who are toxic to the culture no matter how good they are at what they do."[8] The word "quickly" requires qualification. It does not mean firing without process or without giving the person a fair chance to course-correct. It means having the conversation — "here is what I am seeing, here is what needs to change, here is the timeline" — within weeks, not months. If the conversation produces improvement, excellent. If it does not, the decision should already be clear. The CTO who waits six months to fire someone they knew was wrong at six weeks has not been kind. They have been unfair — to the person, who deserved honest feedback early enough to act on it, and to the team, who deserved a leader willing to maintain the standard they were hired into.
|
AUTHOR: A firing story from CorralData — or from a previous role. The reader needs to see the emotional reality: the dread, the conversation, the aftermath, what you learned. This is one of the hardest parts of the job and one of the least discussed. |
The First Ninety Days
The CTO who hires well has solved half the problem. The CTO who onboards well has solved the other half. A brilliant engineer who spends their first month confused, unsupported, and unable to ship is not a bad hire — they are a badly onboarded hire. And at a startup, where there is no dedicated HR team, no learning and development programme, and no twenty-page onboarding handbook, the CTO is the onboarding system.
Lara Hogan, former VP of Engineering at Kickstarter, frames the first thirty days as "sponge mode" — the new hire’s primary job is to absorb information, not to produce output. "These first 30 days are the biggest opportunity you’ll ever have in this role to build trust with your teammates," Hogan writes.[41] At a startup, sponge mode is compressed. The luxury of thirty days of pure observation does not exist when the team has five people and every pair of hands matters. But the principle is sound: the new hire who ships a PR on day three without understanding why the system is designed the way it is has produced code without context. The new hire who spends week one understanding the product, the customer, and the codebase before writing a line has produced something more valuable: judgment.
A lightweight 30-60-90 plan for an engineering hire at a small startup:
Days 1–30: Orient. Set up the development environment and ship a small, low-risk change — a bug fix, a documentation improvement, a minor feature — within the first week. The goal is not the output; it is the feedback loop. The new hire learns how the team works: how code is reviewed, how decisions are made, what "done" means. They meet every member of the team individually. They sit in on a customer call or watch a recorded demo. They read the existing documentation — and, more importantly, they identify the documentation that does not exist but should.
Days 31–60: Contribute. The new hire takes ownership of a project — a feature, a migration, a piece of technical debt reduction — with clear scope and a defined endpoint. They participate in sprint planning and architecture discussions. They begin building relationships with non-engineering colleagues: the CEO, the sales team, the customer success lead. By the end of month two, they should be able to explain the product’s value proposition to a customer without using technical language.
Days 61–90: Own. The new hire operates independently. They make architectural decisions within their area of responsibility without requiring the CTO’s approval. They participate in code review as a reviewer, not just a reviewee. They contribute to prioritisation discussions with opinions grounded in their accumulated context. At the end of ninety days, the CTO can answer the question: is this person a multiplier? If the answer is not clearly yes, the CTO must revisit the hiring decision — which is why the 30-60-90 plan doubles as an evaluation framework.
Assign every new hire an onboarding buddy — not their manager, but a peer who can answer the questions the new hire is embarrassed to ask the CTO. "Where is this documented?" "Why does this service exist?" "Is it always this chaotic, or is this week unusual?" The buddy is the new hire’s guide to the informal knowledge that no documentation captures. At a five-person startup, this is one of the other four people. At a twenty-person startup, it should be someone who has been through the same onboarding recently enough to remember what was confusing.
|
AUTHOR: How onboarding works at CorralData today. Do you have a 30-60-90 plan? What does the first week look like? What’s the time-to-first-PR? How has onboarding changed as the team has grown? Any stories of onboarding done well or badly? |
Evaluating the Team You Built
The CTO who builds a team must also evaluate it — and at a startup, this is harder than it sounds. Corporate performance review systems — annual cycles, forced ranking, multi-page rubrics — were designed for organisations with hundreds of employees, dedicated HR departments, and stable role definitions. A startup with ten engineers has none of those things. The roles change quarterly. The CTO is both evaluator and peer. And the entire exercise can feel, as Buffer’s Chief of Staff Carolyn Kopprasch put it, "silly to do something that felt ‘corporate’ and unnecessary."[42]
The alternative — no reviews at all — is worse. Max Ventilla, founder of AltSchool and a former Google product manager, rebuilt Google’s performance system for startup scale. His warning: "`I’ve seen a lot of companies that really hit the wall around three, four, five years in. Many times you have a real star performer who has done great work and gotten clear praise for years. Then you hire someone over them, and pretty justifiably they say, ‘What the hell?’`"[43] The absence of a formal system does not mean the absence of evaluation. It means the evaluation is happening informally, inconsistently, and in ways the CTO cannot defend when challenged.
The practitioner consensus on cadence is narrow: twice a year, supplemented by continuous feedback in 1:1s. Ventilla runs quarterly reviews at roughly two hours per employee and five hours per manager per cycle. Molly Graham, who has designed review systems at companies from five to five thousand employees, recommends a heavy cycle and a light cycle: "Once per year is too infrequent for how fast our industry moves, but quarterly is overkill."[44] Sam Altman’s guidance to YC companies is simpler: "An important component of creating pathways is performance feedback. It can be light, but it should happen frequently."[45]
Giving Reviews to Engineers
The CTO’s dual challenge is evaluating both the technical output — code quality, architectural judgment, delivery speed — and the non-technical dimensions that matter just as much: communication, initiative, reliability, collaboration with non-engineers. Camille Fournier identifies the common failure mode: "Many new managers are comfortable giving technical feedback, and uncomfortable giving other kinds of feedback. They freely criticize the design and technical work of their team, but they don’t challenge their team members on other growth areas like collaboration, communication style, or project ownership."[46]
Fournier’s solution is concrete: anchor every piece of feedback in a specific example. "If you can’t use a concrete example to support a point, ask yourself if the point is something you should be communicating in the review."[46] The principle scales down to a five-person team: the CTO who tells an engineer "you need to communicate better" has given feedback that cannot be acted on. The CTO who says "in last week’s sprint review, you described the caching change in technical terms that the sales team couldn’t follow — next time, lead with the user impact and add the implementation detail after" has given feedback that can be acted on immediately.
At small teams, peer feedback is the strongest complement to the CTO’s assessment — but it must be designed carefully. Lenny Rachitsky warns: "Some of the highest performers I’ve worked with ruffle feathers on occasion to deliver the right outcome — which can lead to negative peer feedback."[47] Will Larson, whose first year as CTO of Calm involved running the entire review process from a spreadsheet, notes that peer feedback quality varies enormously: "I’ve managed teams who feel peer feedback is too uncomfortable to give honestly, and those teams have provided useless peer feedback."[48]
Dave Smith, Engineering Director at HireVue, provides a model that works for small teams: three questions via a shared form — "What should this person continue doing? What should this person start doing? What should this person stop doing?" — non-anonymous, delivered in person. The result: "Feedback is 95% positive and team members usually leave the feedback session feeling energized."[49] The non-anonymous design is the key. At a five-person team, anonymity is a fiction — everyone knows who wrote what — and the pretence of anonymity licenses dishonesty.
Kim Scott’s Radical Candor framework provides the behavioural principle beneath all of this: feedback should be "humble, helpful, immediate, in person — in private if it’s criticism and in public if it’s praise."[50] Lara Hogan, former VP of Engineering at Kickstarter, offers the most actionable micro-framework for delivering it: the feedback equation. Step one: state the observed behaviour — just the facts, no interpretation. Step two: describe the impact — and pick the impact the recipient will care about most. Step three: ask a genuine question or make a request. "When you presented the migration timeline to the CEO without caveats, it set an expectation we can’t meet, which puts engineering’s credibility at risk. Can we talk about how to frame estimates with the right confidence level?" That is the equation in practice. Hogan’s diagnostic is equally useful: "If a report was surprised by what’s in their review — their manager hasn’t done the work of making their feedback direct and specific."[51]
Adil Ajmal, a serial CTO whose companies include TenMarks (acquired by Amazon) and Posterous (acquired by Twitter), distils the evaluation itself to two dimensions: "Did the person do what they agreed to do or were expected to do? (The ‘What’) How did they go about doing it? (The ‘How’)." The second dimension is where most startup CTOs under-invest: "I would never rate an engineer very highly if their deliverables were great but they burnt through a lot of people or systems to get there."[52]
Scott’s cautionary tale is the one every CTO should read before their next review cycle: after avoiding hard feedback with an underperformer named Bob for ten months, she finally sat down to fire him. "`Bob pushed his chair back, looked at me, and said, ‘Why didn’t you tell me? Why didn’t anyone tell me?’`"[50] The kindest thing the CTO can do is tell people the truth early enough that they can act on it.
Jason Fried, co-founder of 37signals, takes the most radical position: no formal reviews at all. Instead, a single binary question applied at the one-year mark: "`Knowing what I know now, would I hire them again? And that answers pretty much every question. Answers every question about performance, about attitude, culture fit, all the stuff.`"[53] This independently parallels Netflix’s keeper test. The CTO at a five-person startup may find Fried’s approach sufficient. The CTO at a twenty-person startup will not — but the question remains a useful private diagnostic even when a formal system is in place.
|
AUTHOR: How you handle reviews at CorralData. What’s the cadence, the format, the tool? Have you had a "Bob" moment — a time when you waited too long to give hard feedback? What did you learn? |
Receiving Reviews from a Non-Technical CEO
There is a gap in the literature that this chapter is uniquely positioned to fill: no CEO has published a detailed account of evaluating their CTO, and no CTO has published a detailed account of receiving a formal review from a non-technical CEO. The silence itself is revealing. The CEO-CTO evaluation dynamic is asymmetric in a way that no other executive relationship replicates: the CEO cannot directly assess the CTO’s core technical work, and the CTO often has no clarity on what criteria are being used.
Aviv Ben-Yosef, a tech executive consultant who has coached dozens of CTOs, names the vacuum: "Many CTOs and VPEs I speak to have no real clarity about how they are measured. I’ll reveal that many CEOs aren’t sure about how they measure the engineering org."[54] His advice to CTOs is uncomfortable but correct: define your own evaluation criteria before the CEO does it for you. "Even if you don’t have a formal yearly review, you can use this mindset to turn the discussion more business-oriented with the CEO and take control of how you’ll be measured and viewed."[54]
The translation problem — this book’s throughline — applies with full force here. Ben-Yosef is blunt: "In an ideal world, a CEO never hears words like refactoring or tech debt. These are implementation details."[54] The CTO who presents their performance in engineering terms — DORA metrics, test coverage, deployment frequency — is speaking a language the CEO does not evaluate in. The CTO who presents their performance in business terms — revenue impact of shipped features, cost of downtime avoided, hiring velocity relative to plan, customer retention tied to product quality — is speaking the language the CEO uses with the board.
Etienne de Bruin, a practicing CTO, captures the lived frustration: "`I’ve just explained why we can’t ship the feature they want by Q1. I’ve laid out the technical constraints, the architectural implications, the testing requirements. It’s airtight. It’s logical. It’s right. The CEO sighs. ‘Can we just get a rough estimate?’`"[55] His solution — creating shared vocabulary by distinguishing "rough estimate" (30% confidence), "estimate" (70% confidence), and "commitment" (90% confidence) — applies not just to project planning but to performance evaluation. The CTO and CEO must agree on the language before they can agree on the assessment.
Adelina Chalmers, whose data on CTO firing already anchors Chapter 10, provides the stakes: founding CTOs removed from their own companies despite unquestioned technical competence, for reasons that were "arrogant — showing disdain towards board and ELT members who were non-technical; alienating the board with geek speak; not talking about the business outcomes of tech."[56] The CTO who treats their review as a technical report card is optimising for the wrong audience. The CTO who treats it as a business conversation — here is what engineering delivered, here is the impact, here is what I need to deliver more — is managing their own survival.
|
AUTHOR: How your CEO evaluates you. Is there a formal review? What criteria? How do you translate your technical work into language the board understands? The reader who is a solo CTO reporting to a non-technical CEO needs to see this dynamic described honestly, because nobody else has written about it. |
Career Ladders: Start Lighter Than You Think
The performance review only works if there is a shared understanding of what "good" looks like at each level. At a five-person startup, this understanding is implicit — everyone knows what everyone else does. At twenty people, it is not. The career ladder is the document that makes the implicit explicit.
Will Larson recommends writing a lightweight ladder before the first hire into a given role — not because the ladder will be complete, but because the act of writing forces the CTO to articulate what they value.[57] Camille Fournier, reflecting on ten years since publishing the Rent the Runway engineering ladder — one of the first public engineering ladders — offers two warnings. First, do not let HR write it: "It’s really not their job to define expertise in your functions." Second, do not over-engineer it: "You should not try to create a ladder that functions as a pure checklist or scorecard that guarantees promotion if people check enough boxes." But also do not under-engineer it: "When you roll out a half-assed engineering ladder, this new structure may actually make your life harder, because now you’re going to have to negotiate with engineers eager to debate the finer points of broad and vague language."[58]
The practical minimum for a startup with fewer than fifteen engineers: three levels (junior, mid, senior) with two to three sentences per level describing what each looks like across two dimensions — technical ability and scope of impact. The Medium engineering team’s Snowflake model, open-sourced in 2017, maps progress across sixteen tracks with milestone points determining level. Its creators explicitly rejected the language of hierarchy: "Talking about ladders with ‘higher’ and ‘lower’ rungs felt out of tune … this framework should be about growth, not leveling."[59] For a startup, that framing matters — engineers at small companies chose startups partly to escape the corporate ladder, and presenting a growth framework rather than a ranking system respects that choice.
The site progression.fyi curates dozens of public engineering career frameworks — from Rent the Runway to CircleCI to GitLab — and is the best starting point for a CTO building their first ladder.[60] Copy someone else’s structure. Adapt the language to your context. Share it with the team and iterate. The ladder is not a contract. It is a conversation tool — a way to ensure that when the CTO says "senior engineer" and the engineer hears "senior engineer," they are picturing the same person.
One trap to avoid: title inflation. At startups where everyone is "senior" by default — because the title was part of the offer letter that closed the hire — the ladder becomes meaningless before it begins. Larson’s principle applies: "Compare against ladder, not against others."[57] The question is not whether an engineer is better than their teammates. The question is whether they are operating at the level described in the framework. This distinction is what makes reviews defensible when someone is promoted over someone else — the moment Ventilla warned about.
Separate Pay from Performance
One final structural decision: whether to combine compensation conversations with performance conversations. The practitioner argument for separating them is strong. When compensation is on the table, the engineer stops listening to feedback and starts calculating their raise. The review becomes a negotiation rather than a growth conversation.
Buffer, which publishes its salary formula publicly, has fully decoupled the two: salaries change only due to market adjustments or career progression, never as a direct result of a performance review.[61] Christina Wodtke, author of Radical Focus and the leading voice on OKRs, is explicit: "Keep OKRs separate from individual performance reviews."[62] The logic extends to compensation: if pay is tied to the review rating, the engineer optimises for the rating rather than for the work.
The counterargument is equally honest: at a startup with five engineers and no HR department, the CTO is conducting both conversations whether they are formally separated or not. The engineer knows that the person evaluating their performance is also the person who determines their salary. The separation is structural, not psychological. The practical recommendation: hold the performance conversation and the compensation conversation at least two weeks apart. Discuss growth, feedback, and expectations in the first meeting. Discuss pay in the second. The temporal gap creates space for the engineer to absorb the feedback without filtering it through the compensation lens.
|
AUTHOR: How you handle the pay-performance link at CorralData. Are they combined or separated? Has the approach changed as the team has grown? |
‘’’’’
The team the CTO builds is the most consequential decision they make. More than the stack, the architecture, or the deployment pipeline — all of which can be changed — the first ten hires define the culture, the communication patterns, and the system architecture for the next hundred. Conway’s Law ensures that the team structure is the system structure. The VPE hire determines whether the CTO can sustain the role as the company scales. The culture — designed or defaulted — determines whether the team ships with trust or with fear. The hiring discipline — slow in, fast out, honest always — determines whether the team stays strong as it grows. The onboarding — structured enough to orient, lightweight enough to not suffocate — determines whether great hires become great contributors. And the review system — even a lightweight one — determines whether the people the CTO hired know where they stand, where they are going, and whether anyone is paying attention to the difference.
Elliott-McCrea’s formulation is the test: can the CTO hand the work off to people they trust, and will those people run the thing without them and make it better than the CTO could have imagined? If the answer is yes, the CTO has built a team. If the answer is no, the CTO has built a dependency — and Chapter 15’s burnout chapter is the inevitable consequence.