I am extremely concerned with: > [Don't] Personally fix bugs and ship features. So, obvious but mostly irrelevant concerns: Team size. If there is only one pe

I am extremely concerned with: > [Don't] Personally fix bugs and ship features. So, obvious but mostly irrelevant concerns: Team size. If there is only one person you manage, this is likely a mistake. You don't clarify when this rule kicks in, but I assume we don't actually disagree on that point. I am also concerned that you seem to place no emphasis on engineering excellence in those who manage engineers. I've yet to see a single example of this working out well, but it could just be that you didn't mention this and the stuff you did mention paints a picture not representative of your beliefs. My primary concern isn't with making up 40 hours of management for one person, nor non-engineering managers. My concern is that I've seen excellent engineers promoted past the threshold where they're writing features like everyone else. And their responsibility to manage started trumping the professional necessity to push back on things "the management team" would give them. In one example that sticks out, he started bending rules, making them up, and breaking them anyway. I've seen well meaning people turn a blind eye to criminal fraud and people stealing from the company. You can't be an effective leader if people don't see you as part of the tribe. CTOs are often considered part of the management team, and not part of the technical team. I cannot imagine how this makes them better at their jobs -- but if they are in-group for the management team, I understand how it makes them seem like they are better at their jobs.