Growing from a founder-led engineering team to engineering managers

A B2B SaaS company has fourteen engineers and one decision maker. Every pull request, every sprint plan and every production issue passes through the CTO. She is brilliant and exhausted. Her best senior engineer says he would like to lead a team. She wants to say yes and she also worries: if I give him the job, who writes the code, and will he be any good at it?

This is the common crossing point for founder-led engineering teams. This post sets out how to choose first-time engineering managers, define the role, and support them in the first year.

• Every technical decision waits for the founder or CTO.
• Code reviews pile up and releases slip.
• Engineers ask who decides priorities and who reviews their work.
• One-to-one conversations and growth plans are not happening.
• New hires take too long to become productive.

If several of these are true, the team has outgrown a single decision maker. A common marker is a team of six to eight people reporting to one person. Treat that as a guide, not a rule, because the right number depends on the work and the people.

Many companies promote the best engineer and hope. Management is different work. It means setting priorities, giving feedback, hiring, handling conflict, reporting up and protecting the team's time. Write a one-page role description that says what the manager owns, how much they still code, who they report to and what decisions they make alone.

Decide whether the role includes writing code. A mixed role may suit the first few months, but a manager who keeps a full coding load often fails at both. Say what share of time you expect to be on people work and revisit it every quarter.

Look for people who already help others: they mentor juniors, explain decisions, notice conflict and care about delivery more than the code they personally write. Ask candidates for the role what they would do in the first month. Invite the interested engineer to try the work in a small way, such as leading a project or running the sprint, before making the change formal.

Offer the choice, not a trap. Some strong engineers do not want to manage. A senior technical track with its own growth path keeps them. Plan that track at the same time.

1. 1

   Write the manager role

   One page covering ownership, decisions, reporting line, coding share and the people the manager will lead.

2. 2

   Pick a trial period

   Agree a period with a review point where either side can say it is not working, without losing standing. Document it.

3. 3

   Hold the first conversation

   Tell the person why you chose them, what changes and what support they will have. Tell the team too.

4. 4

   Set the first thirty days

   Plan one-to-ones with every report, a review of current projects and a list of decisions the new manager now owns.

5. 5

   Train the basics

   Cover one-to-ones, feedback, delegation, hiring and difficult conversations. A structured manager development programme helps.

6. 6

   Review at the trial point

   Gather views from the manager, the team and you. Decide to confirm, extend or return to the earlier role.

The CTO must delegate, or the new manager becomes a messenger. List the decisions you now make and mark which can move: sprint scope, code review standards, hiring interviews, leave approval and technical design for their area. Move them one group at a time, state the boundaries and the point where they should consult you.

Tell the team who decides what. Engineers will try to go around a new manager at first, so redirect them kindly and consistently.

Tell the engineers what is changing before the announcement spreads on its own. Explain why a manager is being added, what the person will own and how decisions will be made. Invite questions. Peers of the new manager may feel passed over, so speak to them one to one and describe their own path. A respectful conversation now saves months of quiet friction later.

New managers often fall into one of two traps. Some keep doing the engineering work because it feels safe, and the team gets no direction. Others become distant and pass messages up and down without adding judgement. Watch for both. Ask the team in a short check-in, a month after the change, what has improved and what has got worse.

Look at concrete signs: are one-to-ones happening, are reviews quicker, do engineers know their priorities, and are problems reaching you early? If not, talk about it kindly and soon. Most early problems are about habits and clarity, not ability.

• Weekly one-to-one with you, with a standing agenda.
• A peer group of other managers, even if it is only two.
• Training on feedback, delegation and hiring.
• A clear way to raise people issues with you early.
• A review of the role at six months.

Role description signed and shared.
Trial period and review date agreed.
Decisions delegated and decisions still shared.
One-to-one calendar with each report.
Feedback and growth plan for each report.
Hiring process and who interviews.
Escalation route for people issues.
Training plan for the first six months.

Your new managers will need to hire. See the scorecard and skills test for developers for a process they can follow. For how HR needs change as B2B product companies grow, see the B2B SaaS page.