I Was Promoted to VP Before I Was Ready
In 2004, I was promoted to Vice President of Application Development at Countrywide Financial. I had spent the previous two years as a senior developer leading the architecture for a .NET middle-tier platform that integrated with the bank’s core banking system. The work was hard, the architecture was sound, and the company decided I should run a team.
I managed thirteen people through a major core banking conversion. By most external measures, the project went fine. The work shipped. The team held together. Nobody got fired.
But I knew I wasn’t doing my best work, and I knew why. I struggled to delegate. I was still too in love with writing code. Every problem the team brought me, my instinct was to roll up my sleeves and solve it myself rather than coach the person who’d brought it. I held the standard I held as an engineer, get it right, do it well, ship it, but I was holding it for thirteen people instead of one. I hadn’t learned that the way you uphold a standard as a leader is fundamentally different from how you uphold it as an individual contributor.
I tell that story because it’s the lens through which I think about the question this post tries to answer. When a small SaaS company hits a technical leadership crisis, the instinct is to hire a CTO. Sometimes that’s right. Often it isn’t. And one of the most common mistakes, promoting the strongest engineer on the team, is the same mistake my employer made on me. They made it with the best of intentions, and they made it anyway.
The Reflex
Most companies don’t go looking for a CTO until something has gone wrong.
A customer asks for a SOC 2 report and you don’t have one. An architectural decision made eighteen months ago is now blocking the roadmap. The lead engineer leaves and nobody is left who can say with confidence whether a given design will hold up. An investor asks who owns technical strategy and there isn’t a clean answer. A production outage exposes that nobody is accountable for the thing that broke.
The reflex in all of these moments is the same. We need a CTO. One person. Senior. Accountable. Someone who will show up, take ownership, and make the problem go away.
That reflex is understandable, and sometimes it’s correct. But it skips a step. Before you decide you need a CTO, you have to be specific about what’s actually broken. CTO is the answer to a particular kind of question, and the question most companies are actually asking is something else.
The Engineer-to-Leader Trap
The most common version of the wrong answer is to promote the strongest engineer on the team.
This happens for understandable reasons. They have the deepest technical context. The team respects them. The promotion is cheap, a title change rather than a search. And the founder genuinely believes that the person who has been making the right technical calls as an engineer will continue to make the right calls as an executive.
It usually doesn’t work, and the reason isn’t that the person is bad. It’s that the job they’re being promoted into is a different job than the one they were good at.
Engineers are builders. We’re trained, hired, and rewarded for solving problems with our own hands. The job we’re being asked to do as a leader is mostly the opposite. Delegation. Coaching. Saying no. Communicating with people who don’t speak our language. Making decisions with incomplete information and living with the ambiguity instead of writing more code to resolve it. Holding the team’s quality bar without being the person who personally enforces it.
Some engineers make that transition well. Many don’t. And the ones who don’t aren’t failing. They’re being asked to be a different kind of professional than the one the company hired them to be. I lived this at Countrywide. I’ve watched other people live it since. The pattern is consistent enough that I’d treat it as the default outcome rather than the exception.
This is the first thing to check when the reflex says “hire a CTO.” If the plan is to promote internally, ask honestly. Is this person ready to stop being the best engineer in the room? Do they want to be? Have they shown signs of leadership instinct outside of the technical work, like coaching others, making business-aware decisions, communicating with non-engineers, or are those skills still theoretical?
If the answer is “they’re great at the technical part, and we’ll figure out the rest,” you’re about to repeat a mistake a lot of companies have made before you.
CTO Is a Bundle
The deeper issue is that “CTO” isn’t one job. It’s a bundle of jobs that happen to live under one title in mature companies. When a small company hires a CTO, they’re really hiring several functions they hope one person can perform.
The bundle typically includes:
- Strategic technical decisions. Build vs. buy, architecture direction, cloud strategy, security investment, scaling tradeoffs. These decisions require both technical depth and business context, and they’re usually low-frequency but high-stakes.
- Engineering management. Running the team. Standards, code review discipline, hiring, performance, and the day-to-day shape of how work gets done.
- External technical voice. Customer security conversations, board updates, partner discussions, due diligence. The credible technical adult that non-engineers want to talk to.
- Architecture and security oversight. Keeping the platform coherent over time, governing the choices that compound. Often invisible until it isn’t.
These pieces have very different rhythms. Strategic decisions might happen quarterly. Engineering management is daily. External voice is intermittent but unpredictable. Architecture oversight is continuous but often passive, the work of noticing things rather than producing them.
Once you see the role as a bundle, the question changes. It stops being “do we need a CTO?” and starts being “which of these pieces do we actually need filled, how often, and by whom?”
You Can Fill the Role With a Combination of People
For most early-stage SaaS companies, no single hire is the right answer. The work decomposes, and the people available to do it decompose along with it.
A small company often has more leadership capacity than it realizes, and it’s distributed across people who don’t carry executive titles. A senior engineer with the right temperament can cover engineering management, running the team, holding standards, and mentoring more junior developers, without being asked to do strategic technical thinking they aren’t equipped to do. A fractional CTO or experienced advisor can cover the strategic piece part-time, providing the technical judgment that comes from having seen enough to recognize patterns. A tech lead can hold day-to-day architecture and code review.
The piece that gets missed most often is the business perspective. CTO-level decisions are rarely purely technical. Build vs. buy is a financial question. Vendor selection is a contract question. Security investment is a risk-tolerance question. Technical hiring is a culture question. When the people making these decisions are all technologists, the decisions tend to prioritize technical elegance over business outcomes.
This is why the CEO often belongs in the technical leadership conversation, even at companies with technologists available to lead it. So does a non-technical operator, or a business co-founder, or a board member with relevant experience. Their job isn’t to weigh in on the technology. It’s to keep the technology decisions tied to the business they’re meant to serve.
I’d describe this as a CTO by committee, with the caveat that “committee” is doing a lot of work in that phrase. It’s not a four-person decision-making body that votes on architecture. It’s a small group, three or four people, often including the CEO, that collectively holds the work a CTO would hold in a larger company. One person runs the team. One person provides strategic technical judgment. One person ensures the technology remains connected to the business. The roles are clear, and the boundaries between them are clearer than they would be inside a single executive’s head.
I’ve spent the last decade inside a SaaS company that runs this way without anyone calling it that. For most of that time, the owner and CEO had final say and was deeply involved in architectural decisions for the core application. He knew the domain better than anyone, and a B2B SaaS platform is the kind of system where the business logic and the technical design are inseparable. I held application architecture, security, and cloud strategy. A VP of data architecture owned the data layer end-to-end, including SQL, ETL, and the integration pipelines that feed the platform. A VP of operations held the business and customer-facing perspective. Between the four of us, the work a CTO would hold at a larger company got held.
What made it work wasn’t a process. It was that we got along, we knew each other’s strengths, and there was no BS between us. When we agreed, we moved. When we disagreed, we said so. Decisions didn’t get stuck because nobody was protecting territory or scoring points. The CEO’s business filter kept technical decisions tied to outcomes. My security perspective got weighed against operational reality. The data architect pushed back when the application architecture would make his layer harder to maintain. Nobody owned everything, and nobody needed to.
It hasn’t been perfect. The clearest gap was the security program, or rather, the lack of one, for the first few years. The committee wasn’t covering it because none of us was naturally accountable for it. That changed when I took the lead, mostly because I was the one closest to it, and it became a real program with a real owner. The lesson isn’t that the model failed. It’s that distributed leadership requires someone to notice when a piece of the bundle isn’t being held, and to claim it explicitly rather than hoping it gets covered.
The model has also had to absorb a real disruption. The owner moved on, the VP of operations stepped into the CEO role, and the application architecture work the owner used to hold now sits with me and the VP of data architecture. The bundle didn’t disappear when one of the people holding it did. The rest of us absorbed his pieces, and the model kept working. That’s an underrated property of distributed leadership. When one person leaves, the company doesn’t lose the entire CTO function. It loses a slice, and the slice gets reabsorbed.
We haven’t yet hit the point where the company has outgrown this structure and needs a single named CTO. We may eventually. But “we may eventually” is a different problem than “we need one now,” and it’s worth being honest about the difference.
This works because the alternative, hiring a single person to do all of it, is hard to justify at small scale. A full-time CTO at a fifteen-person company often doesn’t have enough strategic work to fill a week, doesn’t have enough engineers to manage to be a real engineering leader, and ends up either drifting into doing the work the team should be doing or sitting in meetings that didn’t need to exist. The bundle isn’t dense enough yet to support the role.
When to Consolidate
Eventually, the bundle does get dense enough, and the seams between people start to show.
Decisions get slow because three people each hold a piece of the context and none of them holds all of it. Accountability gets fuzzy because when something goes wrong, it’s not clear which of the contributors should have caught it. Customers and partners want one technical voice, not three, and the answers they’re getting feel coordinated rather than coherent. The fractional advisor’s six hours a week no longer suffice for the strategic load. The senior engineer is ready for more responsibility than the role can give them.
These are the signals that the distributed model has run its course, and the company is ready for a single accountable executive. The signals are concrete. Company size has crossed a threshold (often somewhere around twenty to thirty engineers). The technology is becoming complex enough that strategic decisions are made weekly rather than quarterly. The regulatory or compliance environment is demanding a single named owner. Or the company is heading into a fundraising or acquisition cycle where investors want to meet the CTO.
When those signals arrive, hiring a full-time CTO is the right call. But the company is now in a much better position to make that hire than it was at the time of the original reflex. It knows what the work actually is. It knows which pieces are heaviest. It knows what kind of person fits its culture because it has already been working with people in those roles. The job description writes itself, and the candidate evaluation has concrete reference points rather than generic executive criteria.
A Better Question
If you’re a founder asking, “Do we need a CTO?”, the answer you’ll get from most people is some version of “it depends.” That’s honest but not useful. The question itself is the problem.
A better question is this. What CTO-shaped work do we need done, and what’s the right configuration of people to do it? That question has a specific answer for most companies, and it almost always involves more than one person, at least in the early stages, and sometimes for longer than expected.
Sometimes the answer is a senior engineer, a fractional CTO, and a CEO who’s willing to engage on the business side of technical decisions. Sometimes it’s a tech lead plus an experienced advisor. Sometimes it’s the existing team, plus a clearer set of decision rights, so the work no longer falls through the cracks. Sometimes, eventually, it’s a full-time CTO, hired with confidence because the company has earned the clarity to know what they’re hiring for.
The reflex to hire one person who solves everything is appealing. It’s also what got me promoted to VP at Countrywide before I was ready. The companies I’ve watched make better decisions on this question are the ones that resisted the reflex long enough to ask what they actually needed, then built the answer from the people they had, plus, when needed, the people they brought in part-time to fill the gaps.
That answer isn’t always a CTO. Often, it’s something better.