These are the most important things I learned about engineering management after five years of doing it. There are lots of subtleties between the lines, so let me know if anything feels vague and I'll try to clarify it.
"If you find yourself blaming someone, you’re probably wrong. Nobody wakes up and tries to do a bad job. 95% of the time you can resolve your feelings by just talking to people."
That could just be a general statement that would do wonders for people to think about.
> [Don't] Personally fix bugs and ship features. You have to write code to remain an effective tiebreaker, but that’s where your coding responsibilities end.
How do you write code without fixing bugs and shipping features? What do you mean by tiebreaker?
> How do you write code without fixing bugs and shipping features?
What I meant here is that you have to fix an occasional bug and ship an occasional feature, but only in order to remain an effective tiebreaker. Fixing things is no longer your primary job. During crunch time new managers often feel that the best way to help the team is to dig in and fix things themselves, but in reality they can help much more effectively by doing other things.
So fix an occasional bug, but remember, you're only doing it to stay in tune with the codebase, not to ship things faster.
> What do you mean by tiebreaker?
I'm talking about making decisions when half the team thinks "we should do X" and the other half thinks "we should do Y". If the team can't reach consensus someone has to decide, and as a manager, that's you.
No, it's a spectacularly bad thing. Unfortunately most dev cultures assume that it will always be necessary. In pretty much all cases it's a management failure.
But yet there's a day when you're ready to release, and therefore need to coordinate with engineers on monitoring the release and fixing last-minute bugs and dependencies, with ops on deploying the release, with marketing on writing a blog post, and with sales on communicating the features to the customers.
This day could be called "crunch time" even if no external deadline is handed down.
My only advice would be to try to be more effective with your points. While you seem to have a lot of knowledge, giving the reader so much at once makes it feels like nothing is important.
I would remove a lot of the redundant or obvious points and try to consolidate others. I like the idea I just think asking someone to read 44 points and remember any significant portion is too much.
I enjoyed the article, I just don't know how much I would remember if asked about it tommorow. I imagine it would be a very valuable tool for newly hired managers inside and outside of engineering though.
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.
I you are a manager that codes and only manages one person then your title does not reflect the fact that you are actually a lead engineer and not a manager. I don't think it is a problem if your title is non-descriptive, but I would not expect all management advice to be applicable to engineers.
Thanks - again - your 57 startup lessons is one of the best posts about startups I've read (http://www.defmacro.org/2013/07/23/startup-lessons.html)
I understood most of the points deeply only after failing in almost all of them.
Same applies here. Many seem to object to #7, but I totally agree with you. A great engineering manager is there to support the team to do their best work and the authority is not gained by writing code, but by making the hard decisions and solving people issues. Manager should only write code to be better in supporting the team by not slowly turning to a pointy-haired boss.
I'd like a more actionable list. Its good to be reminded of what the right actions are; but when and where are what distinguish great managers from ordinary. Fire somebody after two reprimands? After behavior rises to what bar? And so on.
These are the most important things I learned about engineering management after five years of doing it. There are lots of subtleties between the lines, so let me know if anything feels vague and I'll try to clarify it.