4 ms·

I don't agree with this. I enjoy management and coding. However, when I'm in a manager role, I consider contributing with coding to be an essential part of the

by gfodor 6y ago

I don't agree with this. I enjoy management and coding. However, when I'm in a manager role, I consider contributing with coding to be an essential part of the job, to maintain my ability to lead the team with credibility, truly understand what their job is like, and differentiate myself relative to other managers, who by and large have bought into the narrative they can't and shouldn't try to code. This cuts directly against the narrative by the article, and the narrative of the article is the common one. The argument seems to be "you just don't have enough time to do both well!" but in general, there's no free lunch here, you are choosing between different trade-offs. Management is hard no matter what, but if you already have the skill to contribute to a team's efforts, you're not just leaving money on the table you're lighting it on fire by abandoning it by letting yourself atrophy into becoming a manager who's skill stack is shallowly scoped to people management and leadership skills. Whenever you see a commonly held narrative like this that has clear negative consequences to those acting on it, all other things being equal it pays to be contrarian as long as you don't fall into the obvious traps, since you're going to differentiate yourself. I'm surely not the best manager and I'm sure I suck at a lot of it, but everyone does somehow. I'll go head to head anytime with an engineering manager who doesn't ship anything anymore any day of the week in terms of who engineers would rather have as their leader when building something difficult.

humanlion87 6y ago
I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really like. But if you don't spend enough time on the growth of your reports (amongst other responsibilities of a manager), why bother becoming a manager? Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)
- gfodor 6y ago
  Yeah I think this just shows the trade-offs. The path forward for your manager here is to grok they need to turn the dial, at least in their relationship with you. What I reject is the idea that the dial needs to be dialed all the way away from coding, especially permanently, or that doing so is not without immense costs. It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process. Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.
  - humanlion87 6y ago
    I agree with you that I don't want my manager to completely stop coding (especially if it is something they like a lot). I just want them to realize that there are higher priority items on their list of things to-do. And spend at least some amount of time figuring out how to help their reports grow. Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly. That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.
    - Aeolun 6y ago
airhead969 6y ago
A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs. An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively. An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.
- gfodor 6y ago
  You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.) Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.) It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another. I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.

by gfodor 6y ago

humanlion87 6y ago

I would like to add my perspective as an IC who is reporting to a technically-focused manager. I feel frustrated that my manager does not spend even 10% of the time they spend coding on coaching/guiding/giving feedback to me. I feel that part is more important aspect of being a manager compared to churning out code. I understand the need to keep on top of the codebase, especially when coding is something you really like. But if you don't spend enough time on the growth of your reports (amongst other responsibilities of a manager), why bother becoming a manager? Edit: Just to clarify, the question in my post is kind of directed to my manager and not to parent commenter :)

gfodor 6y ago
Yeah I think this just shows the trade-offs. The path forward for your manager here is to grok they need to turn the dial, at least in their relationship with you. What I reject is the idea that the dial needs to be dialed all the way away from coding, especially permanently, or that doing so is not without immense costs. It certainly makes the job of a manager harder when you are forced to reckon with the fact that you can't just throw out coding without it undermining your ability to be a good manager. In practice, I would try to ebb-and-flow with the teams' needs - it's a dynamic, challenging process. Also, there's a tricky issue of, as a report, being able to identify what is intentional vs unintentional. Your manager is probably failing you, but there's also a chance they are forcing you to grow by disengaging a bit and letting you fall into a few ditches. Sometimes a good coach will just shut up and let you make mistakes. Until you see the net effect of their behavior on you over an extended period, you can't know if you have a good coach who is pushing you in a way that you can't see, or a bad coach who is just failing you. A lot of people with good coaches resent them in the early days for being too hard, too disengaged, or other things, which forces them to push themselves harder.
- humanlion87 6y ago
  I agree with you that I don't want my manager to completely stop coding (especially if it is something they like a lot). I just want them to realize that there are higher priority items on their list of things to-do. And spend at least some amount of time figuring out how to help their reports grow. Also, this depends on the experience level of a manager's reports as well. If all of them are quite experienced and have clear goals regarding their career, the manager does not have to spend much time on career coaching. They can focus most of their time on coding. But if that is not the case, then they'll have to balance their time accordingly. That's a good point you make regarding intentional vs unintentional. This point had not occurred to me earlier. After thinking about it though, I am confident that its not applicable for my scenario :0. I will have this in mind for future situations so that I don't come to wrong conclusions.
  - Aeolun 6y ago

airhead969 6y ago

A lot of technical leads who become managers assume they're doing a good enough job on the management side and that they have to master every technical detail, when the truth is they're only convincing themselves that their split allegiances, attention, and priorities aren't a problem of trying to work two jobs. An engineering manager who was technical, listens to their staff, and delegates can still be respectable and has the time and focus to help the team in a greater capacity with non-technical things proactively rather than reactively. An engineering manager who can setup an HA database is as useful as a fireman who can play chess. It's all well-and-good, but it doesn't add value to the management of the team if someone else has that duty. Technical leads yes, but not managers.

gfodor 6y ago
You've clearly stated an opinion, but not an argument. You've also smuggled in the claim that an engineering manager who ships stuff is performing two jobs. I argue that engineering managers who cannot ship stuff are performing half a job. (I don't really, but you can see why this is a fallacy in both directions: it's an argument around definitions.) Your opinion is the same on made in the article and is the consensus view. To me, the consensus view is there for a lot of reasons, one of which is that it's a common anti-pattern for formerly technical engineers to become managers and let themselves get drawn into the code at the cost of management. In all things, balance. The other, more general anti-pattern is to see a failure mode and then presume the diametrically opposed opposite is the global optimum. If engineers are prone to be bad at management because they get sucked into building stuff, then whatever benefits may come from that should to be ignored: they should abandon it altogether. (This is a common error in other domains, like the canards "ideas are nothing execution is everything", "you should never pick stocks, and only invest in index funds", etc.) It also turns out it's much easier to believe that engineering managers who ship code are worse managers, because it means that you can feel good about deciding you're going to stop coding: you're doing it to do your job better. You already have so little time anyway. But what if it turns out being able to ship stuff actually helps you in being a manager? Now it's harder: you have to decide where to draw the line. And so, it's a much more difficult thing to come to terms with since it means there are no easy choices and you actually have to live with the fact you are always going to suck at this in one way or another. I argue that, all other things being equal, having the ability to ship with the team makes you a better manager. The question is if that is true or not, and if so, at what point does the trade-off stop making sense to maintain that ability. Creating false hypothetical situations like "setting up an arbitrary HA database" doesn't prove much of anything about the actual, local, domain knowledge I'm referring to that you get by continuing to perform IC-like work alongside the team you manage.