Three engineers. One founder. Every pull request waited for my approval before it touched production.
It felt responsible. I had built the first version of the product myself. I knew which tables were fragile and which endpoint would fall over if someone changed the wrong thing. Reviewing everything felt like the last safety net between a good team and a bad Tuesday.
Then a Slack message from one of the engineers, sent at 6:40pm on a Thursday: "Still waiting on you for the pricing fix. Should I just start something else?"
I looked at my queue. Four pull requests, two of them two days old. My calendar had eaten the review slots I used to protect every morning. The engineer who wrote the message was good. He had shipped the fix in an afternoon, then sat idle, or drifted onto lower-priority work, ever since.
The details below are a composite, drawn from several early-stage companies I have advised and from my own habits earlier in my career. No single founder or team in this story is real, but the pattern is one I have seen often enough to describe from the inside.
The Real Problem: I Was the Only Quality System in the Company
The instinct to review everything is not vanity. It is usually correct, in the narrow sense that matters: if the founder stops checking and nothing else checks, quality drops. The mistake is not caring about quality. The mistake is being the only mechanism that produces it.
At ten people or fewer, most startups have exactly one quality system, and it is a person. There is no test suite worth trusting, no second engineer with enough context to catch a bad assumption. So the founder reads every diff, because the founder is the only one who can.
That works until the founder's calendar fills up. Then the bottleneck is not "the founder is careful." It is "the company has stopped being able to ship without the founder in the room." Those are different problems, and only one gets fixed by working longer hours.
What It Looked Like From the Engineers' Side
I did not see the cost of this until I asked, directly, what the last month had felt like from their side.
The queue became the real backlog. The team's actual constraint was not writing code. It was waiting. Finished work sat untouched for two or three days at a time because the only approver was in fundraising meetings. Ask your team this week: how many finished changes are waiting on you right now, and for how long?
Idle time got disguised as busywork. When a pull request sits, a good engineer does not sit with it. They start something else, half-finished, to avoid feeling stuck. Three weeks in, five branches sat open, none merged, and nobody had a clear picture of what was actually done. Check: count the open branches older than a week. That is the true size of your bottleneck.
Nobody escalated it. The engineers did not tell me the queue was the problem. They assumed it was intentional, or that raising it would sound like a complaint about their boss. Ask: when did someone last tell you, plainly, that they were blocked on you specifically?
The Moment It Broke
A customer had asked for a small change before a renewal call: a hardcoded setting needed to become configurable. The engineer finished it the same day.
It sat in my queue behind three other changes while I was in back-to-back investor conversations for most of a week. The renewal call happened without the feature. The customer did not churn over one missing setting, but the account manager had to explain, live, why something simple had not shipped. That was the conversation that made the cost visible to me in a way the Slack message alone had not.
Nothing about the code was the problem. The team had the skill and the time. The constraint was entirely mine, and it was invisible until it showed up in front of a customer.
What We Do Differently
The fix is not "let go and hope." Letting go without replacing the quality system just moves the risk from "founder is slow" to "founder is blind." The order matters, and skipping steps is how delegation goes wrong.
Automated checks come first. Before touching who could approve what, we put in place what a computer catches every time without getting tired: linting, type checks, a test suite for the paths that had actually broken before, and a required check before anything merged. This is the least glamorous step, and the one founders skip most, because it does not feel like leadership. It is the foundation everything after depends on.
Review rules come second. Not "everyone reviews everything." A rule: changes to billing, auth, and the database schema require a named second reviewer before merge. Everything else can merge on a passing check and one reviewer who is not the author. Ask which parts of your system would actually hurt the business if they broke, and write down who is allowed to touch them without you.
Delegation with defined limits comes last. Once checks and rules were in place, the two most senior engineers got standing approval authority for anything outside the named high-risk areas: a specific, written scope, not "use your judgment" with no boundary. Defined limits make delegation feel safe to hand out and safe to receive.
This is close to what I now do as a fractional CTO for early teams: come in as the second reviewer and the person who builds the checks, so the founder is not the only thing standing between the codebase and a bad Tuesday.
What Changed, in Terms You Can Observe
I will not hand you a percentage. The honest before-and-after numbers belong to the specific companies they happened at, not to a composite story. What I can tell you is what changed in a way anyone on the team would recognize without a dashboard.
The pile of open branches emptied out most weeks instead of growing. The Thursday-evening "still waiting on you" message stopped happening, because nothing sat long enough to prompt it. New engineers merged their first real change without it ever touching my queue, because the rules told them exactly what they could do alone. And the account manager stopped having to explain, on a customer call, why a finished feature had not shipped.
The Counterintuitive Part
I expected to catch fewer problems once I stopped reviewing everything. The opposite happened. I caught more, and caught them earlier.
Reviewing every diff had made me a bottleneck, but it had not made me a good reviewer. Tired, context-switching, skimming a diff at 9pm between calls, I approved things I should have questioned and missed things a fresh set of eyes would have caught immediately. Once automated checks handled the mechanical failures and a named second reviewer handled the high-risk paths, my own attention went to the smaller number of changes that actually needed a founder's judgment: pricing logic, anything customer-facing on a renewal, anything touching data we could not easily undo. I reviewed less. I caught more, because what I reviewed was chosen on purpose instead of by whatever landed in front of me that day.
Founders resist this because reviewing everything feels like diligence. It is not. It is a single point of failure wearing diligence as a costume, and the team almost always sees it before the founder does. I have written before about why leading people, not managing resources, decides whether a project succeeds, and this is one of the clearest cases: the founder was managing a queue when the team needed a leader who built the system and stepped out of the way.
If this pattern sounds familiar, that is the first thing worth discussing on a diagnostic call.
What to Do Tomorrow
-
Count your queue. Look at every open pull request, ticket, or approval waiting on you right now, and note how old the oldest one is. That age is your real bottleneck, not your intention to "get to it."
-
Write down the three things that would actually hurt the business if they broke. Everything outside that list can be delegated with a rule, not a judgment call, starting this week.
-
Ask one engineer, directly, what they are waiting on you for. Not in a survey. In a real conversation. Their answer will tell you more than your own sense of how things are going.
Frequently Asked Questions
How do I know if I am the bottleneck instead of a careful reviewer? Check your queue's age, not your intentions. If finished work regularly sits for more than a day waiting on you specifically, and nothing else in the company can approve it, you are the bottleneck regardless of how good your reviews are. A careful reviewer with a healthy system has a short queue. A careful reviewer who is the only system has a growing one, a pattern close to what why smart people are not productive describes from the other side of the desk.
Isn't delegating code review risky for a small startup with no technical co-founder? It is riskier to keep the founder as the only quality gate, since that gate disappears every time the founder is in a meeting, a fundraise, or asleep. The safer path is building checks and rules before delegating, not skipping them because no one else is technical yet. That gap is exactly what a fractional CTO is meant to close.
What if my engineers are too junior to review each other's work? Then the second reviewer, at first, should not be a peer. It should be someone senior, even part-time, whose only job is catching what automated checks cannot. That is close to what happens when a technical co-founder cannot scale with the company: review capacity has to grow with the team, or it becomes the ceiling on how fast the team moves.
How is this different from just "letting go" as a leader? Letting go without a replacement system is how founders end up blind instead of slow: nothing catches the mistakes, and the team absorbs the risk. The fix is not disengagement. It is replacing yourself as the review mechanism with a system that does the mechanical part better than you did. The same habit of building a small, strict system instead of running everything by feel is what separates a three-person startup with the right amount of process from one drowning in borrowed ceremony, and it is the foundation for leading engineers when you cannot read their code.
If you recognize yourself as the bottleneck in your own company, a diagnostic call is the place to start, and Fractional CTO & Technical Advisory is where we build the system that replaces you as the only checkpoint.