“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.
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.