I don’t know about “most common” as I think it varies by company, but the worst one for me was allowing myself to get distracted by problems that were more rewarding in the short term, but less important or leveraged. I wrote a bit about this in Attention is your scarcest resource.
How much should I be directly coding vs “architecting” vs process management
Related to the above, you should never be coding anything that’s even remotely urgent (because it’ll distract you too much from non-coding problems). For the first while, you should probably try not to code at all because learning how not to suck as a manager will be more than full-time. Later, it’s reasonable to work in “important but not urgent” stuff in your slack time, as long as you have the discipline not to get distracted by it.
Architecting vs process management depends on what your problems are, what kind of leader you want to be and what you can delegate to other people.
How do I approach hiring?
If you are hiring, hiring is your #1 priority and you should spend as much time and attention on it as is practical. Hiring better people has a magical way of solving many of your other problems.
Hiring can also be really demoralizing (because you are constantly rejecting people and/or being rejected), so it’s hard to have the conviction to put more effort into it until you’ve seen firsthand how much of a difference it makes.
For me, the biggest hiring improvement was getting our final interview to a point where I was quite confident that anyone who passed it would be a good engineer at Wave. This took many iterations, but lowering the risk of a bad hire meant that (a) I wasn’t distracted by stressing out about tricky hire/no-hire decisions, (b) we could indiscriminately put people through our hiring funnel and trust that the process would come to a reasonable verdict. After this change, our 10th-percentile hire has been about as good as our 50th-percentile hire previously, and we went from 4 engineers to 25 in a bit over a year.
I expect the exact same thing goes for investing in people once you’ve hired them, but I’m not as good at that yet so don’t have concrete advice.
Just generally, what would you have imparted on past-you?
You suck at hiring, get better.
If you’re worried that someone is sad about something (especially something you did), ask them!
Org structure matters a lot; friction, bad execution, etc. is often downstream of a bad division of responsibility between teams, teams having the wrong goals, etc. (Matters more once you are responsible for multiple teams)
Accept that you hate telling people what to do, and manage in such a way that you don’t have to. (Perhaps specific to me.)
Great questions!
I don’t know about “most common” as I think it varies by company, but the worst one for me was allowing myself to get distracted by problems that were more rewarding in the short term, but less important or leveraged. I wrote a bit about this in Attention is your scarcest resource.
Related to the above, you should never be coding anything that’s even remotely urgent (because it’ll distract you too much from non-coding problems). For the first while, you should probably try not to code at all because learning how not to suck as a manager will be more than full-time. Later, it’s reasonable to work in “important but not urgent” stuff in your slack time, as long as you have the discipline not to get distracted by it.
Architecting vs process management depends on what your problems are, what kind of leader you want to be and what you can delegate to other people.
If you are hiring, hiring is your #1 priority and you should spend as much time and attention on it as is practical. Hiring better people has a magical way of solving many of your other problems.
Hiring can also be really demoralizing (because you are constantly rejecting people and/or being rejected), so it’s hard to have the conviction to put more effort into it until you’ve seen firsthand how much of a difference it makes.
For me, the biggest hiring improvement was getting our final interview to a point where I was quite confident that anyone who passed it would be a good engineer at Wave. This took many iterations, but lowering the risk of a bad hire meant that (a) I wasn’t distracted by stressing out about tricky hire/no-hire decisions, (b) we could indiscriminately put people through our hiring funnel and trust that the process would come to a reasonable verdict. After this change, our 10th-percentile hire has been about as good as our 50th-percentile hire previously, and we went from 4 engineers to 25 in a bit over a year.
I expect the exact same thing goes for investing in people once you’ve hired them, but I’m not as good at that yet so don’t have concrete advice.
You suck at hiring, get better.
If you’re worried that someone is sad about something (especially something you did), ask them!
Org structure matters a lot; friction, bad execution, etc. is often downstream of a bad division of responsibility between teams, teams having the wrong goals, etc. (Matters more once you are responsible for multiple teams)
Accept that you hate telling people what to do, and manage in such a way that you don’t have to. (Perhaps specific to me.)
Hiring.