I Was the Bottleneck on My Own Engineering Team

Note: This story was written with AI assistance and edited by me.

Note: An earlier version of this piece, "Hiring Your First Engineering Manager: When a Founder Should Stop Managing Developers," was published on DEV.

For a long time I believed that managing the developers myself was a sign I was doing my job well. I knew every project, every deadline and every engineer's strengths. Then I started noticing a pattern. Questions piled up in my messages overnight. Good people waited half a day for a decision that took me thirty seconds once I finally saw it. One-on-ones I had promised became rushed status checks, and then they stopped happening at all. I was not leading the team anymore. I was standing in front of it.

I have lived this more than once, first as a partner at a software consulting company that grew from about $6M to $60M in under three years, and later while building a fully remote consultancy from scratch. Each time, handing engineering management to someone else was the right call, and each time I waited longer than I should have.

How to Tell It Is Time

There is no headcount rule that says when a founder should stop managing developers. The signs are about behavior, and they tend to arrive together.

Work waits for you. Code reviews, priorities, estimates and production questions all sit in your inbox. When the team moves at the pace of your calendar, your calendar becomes the ceiling.

The people conversations disappear. Weekly one-on-ones slide to monthly, and the ones that survive are about status, not about anyone's growth.

Hiring gets sloppy. There is no time to write a thoughtful job post, run consistent interviews or welcome new people properly, so new developers drift for months before they find their footing.

Nobody owns the big technical picture. Architecture is decided by whoever happened to pick up the ticket first.

Your real job gets the leftovers. Customers, product direction, partners and funding get whatever hours remain after the engineering fires. For me, that was the clearest warning.

If a few of these feel familiar, you are likely already behind.

Who to Hire First

A first engineering manager is not the same hire as a fifth. You are handing over something you built by hand, so the profile matters more than the title.

Someone still close to the code. In a small company, this person will review pull requests, help in incidents and make design calls. A manager who has not worked in a codebase for years will have a hard time earning the team's respect.

Proof of real people work. Ask for stories. A performance problem they worked through. A hire that did not work out. Two engineers who could not agree. Specific answers tell you far more than talk about "empowering teams."

Comfort building from nothing. Early companies have no playbook. You want someone who has created process from scratch and knows when to stop adding more.

Willingness to tell you no. Founders skip this one most often. A manager who only passes along your instructions is an assistant. You need someone who will push back on unrealistic dates and protect the team's focus, including from you.

Experience with your way of working. If your engineers are spread across time zones, look for someone who has already led a distributed team through written updates and video calls.

Handing Over the Keys

Most of the risk lives in the handoff. Handled carelessly, the team ends up with two bosses and slows down.

Put the handoff in writing. List what moves: one-on-ones, sprint planning, hiring decisions, release approvals, on-call. Be just as clear about what stays with you for now.

Announce it plainly. Tell the team why the change is happening and what it means for them. Say clearly that the new manager has real authority, because someone will test it.

Send people back to their manager. When a developer messages you about something you have handed over, point them to the new manager. It feels awkward for a couple of weeks. If you keep answering, the handoff never actually happens.

Meet weekly for context, not control. Share customer conversations, company priorities, budget and the things that worry you. Give your manager what you used to carry around in your head.

Give it a full quarter. Your manager will make calls you would have made differently. Judge the results over months, not days.

Stepping Back Is Part of Leading

Many founders hold on to managing engineers because it feels like proof they still understand the product. Past a certain size, it works the other way. The most useful thing you can give your developers is a manager who has time for them, and the most useful thing you can give yourself is the hours only you can spend.

Hire someone hands-on, good with people and brave enough to disagree with you. Hand off on purpose, then step far enough back that the new structure has room to work.

I took a firm from $6M to $60M in under three years.