From Founding Engineer to Head of Engineering: The Identity Shifts Along the Way

In 2017, I joined Caffeine.tv as one of the founding engineers. It was a social live-streaming platform backed by 21st Century Fox and advised by Ben Horowitz. By the time we raised our Series D, I was Head of Engineering leading a 22-person team across backend, mobile, and QA.

That journey — from writing code in a room with 5 people to running the engineering function for a company with institutional investors and a board — was the most transformative experience of my career. It was not a promotion. It was an identity shift. And it nearly broke me before it made me better.

The Identity Crisis: Builder to Leader

For the first 10 years of my career, my identity was clear: I was someone who built things. At Amazon Lab126, I was the engineer who shipped Kindle Paperwhite 3rd Gen, Oasis, and Voyage. My value was my technical output. My self-worth was tied to the code I wrote, the systems I architected, the problems I solved with my hands on the keyboard.

At Caffeine, that identity collided with a new reality. As the company grew from stealth to Series B to Series C, the engineering team grew from a handful to 22. And somewhere around engineer number 8, I realized that the most important thing I could do was no longer write code — it was build the team that writes the code.

This sounds obvious in retrospect. It was not obvious in the moment. What it felt like was loss. I went from shipping features daily to spending my days in meetings, writing planning documents, and having difficult conversations about performance. My pull request count dropped to near zero. My calendar was full. And I felt like I was not doing anything.

When to Stop Coding

The most common question I get from founding engineers: "When should I stop coding?" The honest answer: you should stop being on the critical path for code long before you stop coding entirely.

Here is the progression I went through at Caffeine, and the progression I now recommend:

1. Engineers 1-5: Code full-time. You are the technical leader. Your code sets the quality standard. Architecture decisions flow through your keyboard.
2. Engineers 5-8: Start delegating critical path work. You still code, but nothing should block on your pull requests. Start doing more code review than code writing.
3. Engineers 8-12: Code becomes optional. You are spending 50%+ of your time on people, process, and planning. Code only in areas where your expertise uniquely adds value — architecture prototypes, performance-critical systems, tooling.
4. Engineers 12+: Stop coding on the product. Your coding should be limited to prototypes, internal tools, and exploration. If you are still on the critical path for product features, you are the bottleneck.

I made the mistake of staying on the critical path too long at Caffeine. At 10 engineers, I was still the go-to person for our real-time streaming infrastructure. When I got pulled into a fundraising cycle and was unavailable for two weeks, the team stalled. That was the wake-up call: if your absence stops the team from shipping, you have failed at the transition.

Delegation Without Abdication

The hardest skill I had to learn was delegation. Not the concept — the practice. There is a spectrum between micromanagement and abandonment, and most new engineering leaders oscillate between the extremes before finding the center.

The Micromanagement Trap

My first instinct was to review everything. Every design document, every pull request, every technical decision. I told myself this was about quality. It was actually about control. I was terrified that without my direct involvement, the quality of the codebase would degrade.

The result was predictable: I became the bottleneck. Engineers waited for my approval. Innovation slowed because people stopped taking initiative. My best engineer pulled me aside and said, "I feel like I need your permission to think."

That conversation changed my approach permanently.

The Abdication Trap

Overcorrecting, I swung to the other extreme. I stopped reviewing anything. I told the team to "own it" and stepped back entirely. Within a month, we had two significant architectural decisions made independently that were fundamentally incompatible. We lost three weeks of work reconciling them.

Finding the Center

Effective delegation is about defining the decision boundaries, not the decisions themselves. The framework I eventually developed at Caffeine and have used at every company since:

• Level 1 — Inform me: "Make the decision and tell me what you decided." For routine technical choices within a team's domain.
• Level 2 — Consult me: "Make a recommendation, discuss it with me, then decide." For cross-team technical decisions.
• Level 3 — Decide together: "Let's evaluate this jointly." For architectural decisions with company-wide impact.
• Level 4 — I decide: "I'll make this call after hearing input." Reserved for existential technical decisions — platform choices, vendor commitments, security architecture.

The key is making these levels explicit. Every engineer should know which level applies to their current decision. When I started using this framework at Caffeine, decision velocity doubled overnight because people stopped guessing whether they needed permission.

Maintaining Technical Credibility

One fear that haunts every founding engineer who becomes a leader: "Will I lose my technical edge?" The fear is legitimate. If you stop coding entirely for 2-3 years, your hands-on skills will atrophy. But technical credibility as a leader is not about being the best coder — it is about making sound technical judgments.

Here is how I have maintained technical credibility across five leadership roles:

1. Stay in the architecture reviews. You do not need to write the code, but you should be in the room when major systems are designed. Ask hard questions. Challenge assumptions. Your pattern-matching from years of building is your unique asset.
2. Read code, even if you do not write it. I spend 2-3 hours per week reading pull requests — not to approve them, but to understand how the system is evolving. This keeps me informed without being a bottleneck.
3. Build side projects. My personal projects — collectible card pricing tools, prediction market analysis, deck optimizers — keep my coding skills current. They also give me direct experience with new technologies that I can bring back to my day job.
4. Be honest about what you do not know. Nothing destroys technical credibility faster than faking expertise. When I transitioned from backend systems to Unreal Engine at Riot Games, I was upfront about my learning curve. The team respected the honesty far more than they would have respected bluster.

Building the Team from Stealth Through Series D

At Caffeine, I hired or managed the hiring of every engineer from employee 1 through 22. Each phase required a different hiring approach:

Stealth to Series A: Hire Generalists Who Ship

In the early days, you need engineers who can do everything — frontend, backend, infrastructure, mobile. Specialization is a luxury you cannot afford. The hiring bar is: "Can this person ship a feature end-to-end in a week with minimal guidance?"

Series A to Series B: Hire Specialists for Critical Systems

As the product matures, specific systems become critical. At Caffeine, real-time streaming was our technical moat. We hired a dedicated streaming engineer whose expertise was 10x deeper than anyone else's in that domain. The first specialist hire should be in the area where technical excellence creates competitive advantage.

Series B to Series D: Hire Leaders, Not Just Engineers

By Series B, you need people who can own entire problem spaces — not just write code, but define requirements, coordinate with other teams, and mentor junior engineers. This is when you start hiring senior engineers and engineering managers who bring process maturity and leadership skills.

The Mistakes I Made

Transparency matters. Here are the mistakes I made during the Caffeine journey that I would handle differently today:

1. I waited too long to hire my first engineering manager. I tried to manage 15 engineers directly. The quality of my 1:1s suffered, I missed performance issues, and I burned out. I should have hired an EM at engineer 8.
2. I did not invest in onboarding early enough. Each new engineer learned by osmosis — pairing with whoever was available, reading code, asking questions in Slack. A structured 2-week onboarding program would have cut ramp time in half.
3. I held on to technical decisions too tightly. Even after I stopped coding, I was the final approver on architecture decisions. This created a bottleneck and disempowered senior engineers who were perfectly capable of making those calls.
4. I underestimated the emotional labor. Managing people through a high-growth startup is emotionally exhausting. I did not set boundaries early enough, and the burnout compounded until it affected my judgment. Take care of yourself first — you cannot lead if you are running on empty.
5. I conflated presence with productivity. Early on, I measured my contribution by hours worked. This set a toxic precedent for the team. Shifting to output-based evaluation — for myself and the team — was one of the healthiest changes I made.

Advice for Founding Engineers Facing This Transition Today

If you are a founding engineer being asked (or asking yourself) to step into a leadership role, here is what I would tell you:

1. It is okay to grieve the loss of building. You are giving up something real. Acknowledge it. Then decide if what you are gaining — the ability to multiply your impact through others — is worth it. For me, it was. For some great engineers, it is not. Both answers are valid.
2. Get a coach or mentor. The transition from IC to leader is one of the hardest career shifts in engineering. Having someone who has been through it — who can normalize the discomfort and share frameworks — is invaluable. My time at Wharton and Harvard Business School's executive programs gave me frameworks, but the real learning came from mentors who had been in the same seat.
3. Start delegating before you are comfortable with it. If you wait until you are confident someone will do it as well as you would, you will never delegate. Delegate when they can do it 70% as well. Then coach them to 90%. They will never do it exactly the way you would — and that is fine.
4. Define your new success metrics. If your metric is still "lines of code written," you will feel like a failure as a leader. New metrics: team velocity, engineer retention, time-to-hire, percentage of milestones hit. These are your new scoreboard.
5. The transition takes 6-12 months. You will feel incompetent for the first 3 months. That is normal. By month 6, you will start to see the leverage of your new role. By month 12, you will not want to go back.

The journey from founding engineer to engineering leader is not a straight line. It is a series of identity shifts, each one uncomfortable and each one necessary. If you are in the middle of this transition and want to talk through it, I have been exactly where you are. You can see my full career arc on the Experience page, or reach out directly.