I built Xcellerant Ventures' AI product team from a handful of engineers to seventeen people across four products, and the hardest part was never the hiring. It was noticing, uncomfortably late, that the habits which made me effective at five people were actively slowing down seventeen.
The habit that doesn't scale
At a small team, staying close to the details is a superpower. You catch the wrong assumption before it ships, you can personally unblock anyone in an hour. At seventeen people across four products, the same habit means you've become the bottleneck every decision routes through, and the team has quietly learned to wait for you instead of deciding without you. I noticed it first as a feeling (exhaustion that didn't match the actual hours) before I noticed it as a pattern in the data: review cycles that used to take a day were taking three, not because the work got harder, but because everything funneled through one inbox.
If the team's speed is capped by your calendar, you haven't built a team. You've built a queue with extra steps.
What actually had to change
- Hiring and coaching PMs, designers, and engineers who could own a full outcome, not just execute a spec. That meant writing fewer specs myself, on purpose, even when mine would have been faster to produce.
- Replacing my presence with a decision log. Most of what people actually needed from me wasn't my judgment in the moment, it was knowing what judgment I'd apply, written down clearly enough that they could apply it themselves.
- Making "disagree and commit" real rather than a phrase. The first few times I let a lead ship a call I'd have made differently, it felt like a mistake. It was usually fine, and when it wasn't, it was cheaper to fix than the alternative: a team of seventeen people afraid to decide anything without me.
The smaller lesson from Hexkode
Leading a five-person team into two new ventures in West Africa, in a market none of us knew, was the opposite scale problem and taught the mirror-image lesson: at five people, you can and should stay close to the details, because there's no layer of management to delegate through yet. The mistake isn't "stay close" or "let go" as a universal rule. It's applying the five-person instinct at seventeen-person scale, or the inverse, assuming a small team needs the same structural distance a large one does.
The clearest signal I now watch for isn't velocity. It's how often a decision reaches me that genuinely needed my judgment, versus one that reached me because the team wasn't yet trusted, or trusting itself, to make it without me.
What I'd tell myself earlier
Staying close to the details isn't a virtue or a flaw. It's a tool sized for a specific team size. The job, as the team grows, stops being "get closer to the work" and starts being "build the judgment and the trust that let other people get close to the work instead." That transition is uncomfortable precisely because the skill that got you promoted isn't the skill the new size requires.