[mzanchi]

This has been in my mind recently. I am head of development at a startup and have something like 30 direct reports. I don't want to be doing this job for a long time, and am maneuvering the team structure to make myself redundant with the following actions: - I am trying to convince the execs and HR to increase pay transparency and to reward people who want to progress in their careers as engineers more than those who want to become managers. - I have promoted one person with more leadership skills (and less technical ability) to be a dev lead; essentially a mentor, gathering feedback from the team and helping them solve process and communication issues, and keeping track of OKR metrics. - I hired a department assistant, to do resource allocation, manage Jira permissions, tidy up boards, etc. - We have 1 project manager who is responsible for our three internal development projects, controls our budget and fights with other PMs for resources. - All others are Developers and QA. Some are more senior, so they have architecture roles. Everyone gets to give their voice, but one of them has an official role of architecture lead, who has the final say, but that's mostly cerimonial.

My role is to help them focus when they start to drift, shield them from politics, and most importantly give a cerimonial ratification on their ideas, if they match the values of the company.

So all 4 non developers are essentially assistants. I hope to soon be able to step out and leave the team working happily with a 10 to 1 ratio of dev to non-dev.

[nilkn]

30 direct reports is an astonishing number, and it makes me feel like you're either onto something brilliant or are crazy and this structure is going to crash and burn once things get really complicated and fast-paced. I suppose it depends on how routine a lot of the work is. You'd be spending a minimum of 15 hours a week just on 1:1s, but I could see that being as high as 20 or 30 hours; 15 is already two full days out of the week. That is, unless you just don't do 1:1s at all, which seems incredibly risky long-term.

Given a six-month check-in and annual review once a year for each report, you'd have a total of 60 such events a year, meaning you'd have at least one annual review or six-month check-in every single week. You'd have to keep up with the unique performance characteristics of 30 different people in order to conduct these reviews in any reasonably useful and professional way that actually encourages real growth. If there's any sort of interpersonal conflict or unexpected project complexity, this could easily burn through enough of your time that you'd have to blow off nearly 30 people in the meantime.

[mzanchi]

Yeah, I started doing 1-on-1 with all of them when the team was about half size. The reason I got one of the guys "promoted" as dev lead is so he can take most of the mentoring and feedback gathering. He is not their boss though, with no authority to assign work or make demands.

Nowadays I do 1-on-1s with the dev lead, the assistant, and the product owners (senior devs and architects), so only 5 people.

Still, that would mean the dev lead would need to do 25 1-on-1s, so we have a structure of peer mentorship, with two phases: a formal and an informal. The formal is to maintain quality of information gathering and fairness. The informal is to allow for rapport and flexibility in the part of the mentor. We started this recently, we'll see how it goes.

[jl2718]

This solution sums up the problem. When you have many of those dev leads, the least capable among them will be promoted to be their leader. This is human nature in group formation.