“If you mean being the primary implementer of features, then probably not. If you mean being an integral part of how your team produces code, then yes, absolutely. I recommend it highly.”
In my opinion, being able to code is a good start, but not enough. I think that having doing coding is especially important for the managers that DON’T itch to do it - who are drifting away slowly.
Your questions are great ones, but I feel that the answer to them doesn’t change from yes to no immediately. It takes years, and they get ‘turned off’ one by one.
The only solution imo is not just being part of producing code (like code reviews and pair programming) but writing it yourself. Not in the critical path, and not even every sprint or month - a day every 3-4 months is better than nothing.
For example if your team codes with Cursor and you never experienced it yourself - that’s a problem.
Agree with the final sentence 100%. It’s similar to the idea that you should sleep in your own guest room once before having guests too. Walking a mile in your team’s shoes will give you firsthand experience in their day to day workflow and help you understand what they value and what adds friction to their day.
Great article, but I’d caution against getting too into the code and inadvertently becoming the team tech lead. Then you’ll become both a bottleneck and hinder growth of your team and people!
Could you please speak to this? When EMs get involved in the nitty gritty of the tech design details and code reviews on a day to day basis, it leaves very little room for a Sr. Engineer and Tech leads to grow and "lead" the team w.r.t technical conversations. It team meetings and design discussions, it feels like speaking with an EM who is still uncomfortable to give up their (previous) tech lead role. There is also the aspect of "trust", the team can feel as if the EM doesn't trust their team with day to day tech execution and deliverables.
I can see where you are coming from in your argument which is the theory that the manager hogs all of the space that the senior ICs could reside in, and maybe does so in a way that is meddling.
However, I guess I'd go back to first principles here and ask the question: what exactly would be happening in a team, and with the manager themselves, if the manager being close to the details would somehow make things... worse?
Is that not an indicator of some wider (and more important) dysfunction such as inability to collaborate? It's totally possible to have senior ICs drive technical discussions _with_ managers also part of that conversation.
Or is the manager just not that great at their job?
Similarly: how could a manager competently being in the details somehow diminish trust? Again, it feels like a dysfunctional manager that needs to learn how to collaborate better, or actually bring something of value to the table rather than just poking around.
I've had the opposite experience: having your manager close, truly present and effective means they can support you more, bring their experience and improve things, and concurrently be able to see your true impact (great for performance reviews!).
I'd hope my directs over the years have also found my own being in the details to be a good thing too: I think I bring something valuable to the table in technical discussions.
Great article. I think the key part is:
“If you mean being the primary implementer of features, then probably not. If you mean being an integral part of how your team produces code, then yes, absolutely. I recommend it highly.”
In my opinion, being able to code is a good start, but not enough. I think that having doing coding is especially important for the managers that DON’T itch to do it - who are drifting away slowly.
Your questions are great ones, but I feel that the answer to them doesn’t change from yes to no immediately. It takes years, and they get ‘turned off’ one by one.
The only solution imo is not just being part of producing code (like code reviews and pair programming) but writing it yourself. Not in the critical path, and not even every sprint or month - a day every 3-4 months is better than nothing.
For example if your team codes with Cursor and you never experienced it yourself - that’s a problem.
That's a really insightful comment. Thank you!
Agree with the final sentence 100%. It’s similar to the idea that you should sleep in your own guest room once before having guests too. Walking a mile in your team’s shoes will give you firsthand experience in their day to day workflow and help you understand what they value and what adds friction to their day.
Great article, but I’d caution against getting too into the code and inadvertently becoming the team tech lead. Then you’ll become both a bottleneck and hinder growth of your team and people!
James,
Could you please speak to this? When EMs get involved in the nitty gritty of the tech design details and code reviews on a day to day basis, it leaves very little room for a Sr. Engineer and Tech leads to grow and "lead" the team w.r.t technical conversations. It team meetings and design discussions, it feels like speaking with an EM who is still uncomfortable to give up their (previous) tech lead role. There is also the aspect of "trust", the team can feel as if the EM doesn't trust their team with day to day tech execution and deliverables.
Hello!
I can see where you are coming from in your argument which is the theory that the manager hogs all of the space that the senior ICs could reside in, and maybe does so in a way that is meddling.
However, I guess I'd go back to first principles here and ask the question: what exactly would be happening in a team, and with the manager themselves, if the manager being close to the details would somehow make things... worse?
Is that not an indicator of some wider (and more important) dysfunction such as inability to collaborate? It's totally possible to have senior ICs drive technical discussions _with_ managers also part of that conversation.
Or is the manager just not that great at their job?
Similarly: how could a manager competently being in the details somehow diminish trust? Again, it feels like a dysfunctional manager that needs to learn how to collaborate better, or actually bring something of value to the table rather than just poking around.
I've had the opposite experience: having your manager close, truly present and effective means they can support you more, bring their experience and improve things, and concurrently be able to see your true impact (great for performance reviews!).
I'd hope my directs over the years have also found my own being in the details to be a good thing too: I think I bring something valuable to the table in technical discussions.
But, of course, YMMV. :-)