I want to talk about something that doesn’t get discussed enough in CTO circles: the hardest part of scaling past 50 engineers wasn’t technical—it was letting go.
Letting go of direct management. Letting go of reviewing every architecture decision. Letting go of knowing every line of code. Letting go of being the most technical person in every room.
The transition from hands-on technical leader to executive building a leadership team was harder than any technical challenge I’d faced in my career. And I suspect I’m not alone.
What Worked at 20 Engineers (But Doesn’t Scale)
At 20 engineers, my leadership model was deeply hands-on:
- I reviewed every significant architecture doc personally
- I knew everyone’s code and could jump into any PR
- I made most technical decisions (with input, but ultimately my call)
- I had 1-on-1s with every engineer
- I was involved in every hiring decision
- I could keep the entire system in my head
This felt like good leadership. I was adding value. I was unblocking people. I was making sure we maintained technical excellence.
At Microsoft and Twilio, I’d seen leaders “ascend to management” and lose their technical edge. I was determined not to be one of those CTOs who became disconnected from the work.
What Broke at 50+ Engineers
By 50 engineers, my hands-on model became the bottleneck:
- Architecture docs piled up waiting for my review (I became the constraint)
- Engineers stopped making decisions and waited for “Michelle’s guidance”
- I was in 40+ hours of meetings per week, leaving no time for deep work
- My calendar was 95% booked 3 weeks in advance
- I knew some engineers’ names but not their work
- I couldn’t keep the system in my head anymore
I was the single point of failure for the entire engineering organization.
And here’s the uncomfortable truth: I was holding on because letting go felt like losing my identity.
I’d built my career on being the best engineer in the room, the person who could solve the hardest technical problems, the architect who saw the whole system. If I let go of that, who was I?
The Transition: Building a Leadership Team
The shift from managing engineers to leading leaders required three fundamental changes:
1. Building the Leadership Bench
I promoted 3 Directors of Engineering and 5 Senior Engineering Managers. Not because we needed the titles, but because we needed distributed decision-making and leadership capacity.
The Directors own:
- Architecture decisions within their domain
- Hiring for their teams
- Team process and delivery
- Technical strategy for their area
I don’t review their architecture docs. I don’t approve their hiring decisions. I don’t attend their sprint planning.
That was terrifying at first. What if they make decisions I disagree with? What if they hire the wrong people? What if the architecture diverges in ways I wouldn’t have chosen?
2. Trusting Leaders to Make Different Decisions
This was the hardest part: learning to trust my Directors to make decisions I would have made differently.
Not wrong decisions—just different ones.
Early example: One of my Directors chose to build an internal tool instead of using an off-the-shelf SaaS product. I would have bought the SaaS product. But it was his call to make, not mine.
My job changed from making the decision to ensuring there was a good decision-making process. Did they consider alternatives? Understand trade-offs? Align with business needs?
If yes, then trust them—even if I would have chosen differently.
3. Shifting Focus to Systems and Culture
My time allocation shifted dramatically:
Before (at 20 engineers):
- 60% technical decisions and architecture
- 30% management (1-on-1s, hiring, performance)
- 10% strategy and culture
After (at 50+ engineers):
- 15% technical guidance (high-level, not detailed)
- 35% leadership team development
- 50% organizational design, culture, strategy
I moved from first-order impact (writing code, reviewing architecture) to second-order impact (enabling leaders who enable teams who build products).
That required redefining what “adding value” means at the executive level.
What I Wish I’d Known
1. Delegation Is Not Abdication
I initially swung too far—from doing everything myself to completely hands-off. Neither works.
Good delegation is:
- Clear ownership and decision rights
- Context and constraints (business goals, technical principles)
- Support when needed (coaching, unblocking)
- Accountability for outcomes (not micromanagement of process)
2. Your Leadership Team Will Make Mistakes (And That’s How They Grow)
Some of my promoted Directors made decisions I had to unwind. Architectural choices that created tech debt. Organizational structures that didn’t work. Hiring mistakes.
My instinct was to step in and fix it. But that would have undermined their authority and prevented their growth.
Instead: coaching conversations, learning retrospectives, adjusting for next time. They learned more from those mistakes than from any success.
3. Letting Go of Technical Identity Doesn’t Mean Losing Technical Credibility
I worried that if I wasn’t in the code daily, I’d lose credibility with engineers. But credibility at this level comes from:
- Asking the right questions (even if you don’t know the answers)
- Understanding trade-offs and constraints
- Making engineers better through coaching and resources
- Protecting the team from organizational chaos
I’m not the best engineer in the room anymore. But I can make the engineers in the room better at their jobs. That’s a different kind of technical leadership.
My Questions for Other Leaders
For CTOs and VPs who’ve made this transition:
-
How did you identify who was ready for Director/Senior Manager roles? Our best engineers aren’t always our best managers.
-
How do you balance letting leaders grow through mistakes vs. protecting the business from costly errors? Where’s the line?
-
How did you personally handle the identity shift from “best technologist” to “leader of leaders”? What helped you let go?
-
What does “staying technical” look like at the executive level? How do you maintain technical credibility without being in the code?
-
How do you develop leadership capacity in your team? Are there specific programs, coaching, or experiences that accelerate leadership development?
This transition is lonely. You can’t really talk about it with your team (“hey, I’m struggling to let go of control”) without undermining confidence. But I suspect many of us are struggling with it.
Let’s talk about it openly.
Michelle Washington | CTO | Learning that leadership at scale is about enabling others, not doing it yourself