It's interesting how one of the first things they mention is that you won't be expected to code. That may be true in some orgs but not others.
In my org team leads are the managers as well as the technical leads and wear the Scrum Master hat too.
Most of the other advice is still sane if you ask me but personally I do like oue mix of coding and other challenges. Keeps things interesting and you don't get too bored of one side of things. Also, it's much easier to see if one of your 'stars' is actually one or is just the loudest. If you don't really know the code base yourself that can be a little harder to figure out and message. And you don't have to work on the large, important critical path user stories either. Just fixing bugs from time to time is enough to learn their tools, their conventions, keep current, be seen as competent by them (helps tremendously with being listened to in my experience) and still have time to actually do your other jobs properly, because coding comes last but not least.
In my last job, the company didn't appreciate me getting involved in my project-teams work. Instead of spending time in useless meeting, I preferred to work with my team and take ownership of certain tasks.
Issue was that my loudest peers got promoted, while I kept delivering products and improving processes.
It’s almost universally a very bad sign if managers are significantly contributing code. I agree with you that occasional bug fixes or small tweaks would be fine, but anything beyond that and it means the manager is taking time away from support and setting others up for success, which is way harder and requires much more vigilance.
A manager should not be making tactical implementation decisions - they should trust their team to make those decisions, and offer higher level architecture & product guidance about the problems worth solving, the context and the constraints. Managers should be somewhat like 1/3 principle engineer, 1/3 product manager and 1/3 personnel / recruitment / rewards manager.
The absolute worst is when a company very openly embraces “team lead” or “player coach” roles, which are essentially an unspecified dumping ground of any arbitrary, flailing responsibility from any domain, with no clarity and with unrealistic expectations of “wearing many hats” and getting no staffing or team growth yet still being expected to deliver high project throughput and still somehow manage personnel issues, compensation, team building and so on.
“Team lead” is a bad cop out by senior leaders who are too weak to defend org structures they designed. They want to have their cake (take credit for constant reorgs) and eat it too (drop in to any part of a reorg that’s not succeeding and arbitrarily redefine a team lead role to mean whatever they want it to mean at that moment, for political convenience).
Even though it might be fun to still do coding, your life as a manager is so much better if you refuse anything like “team lead.” Don’t do it. Only accept roles with super explicit clarity that your job is to be a manager, not an implementer, and require a company culture that really backs this up and affirms it.
You are maybe being a bit drastic and that's probably alright given the experience that speaks from behind what you're writing there.
I can see some of what you are saying happening at my org too. I'm fighting it with I think enough success to be comfortable. What I mean is that my boss has recently tried to get me to commit to more coding and I refused. It makes zero sense to me to have a team lead commit to coding a specified "amount" (good luck measuring that properly anyway). It will only lead to "sorry nope can't help you, gotta make my own quota" type behaviour, which is definitely not what you want to encourage.
Fixing bugs to help the team out and having them concentrate on delivering the user stories in sprint while actually having some fun debugging sessions for a change? Awesome! :)
4 comments
[ 4.1 ms ] story [ 18.1 ms ] threadIn my org team leads are the managers as well as the technical leads and wear the Scrum Master hat too.
Most of the other advice is still sane if you ask me but personally I do like oue mix of coding and other challenges. Keeps things interesting and you don't get too bored of one side of things. Also, it's much easier to see if one of your 'stars' is actually one or is just the loudest. If you don't really know the code base yourself that can be a little harder to figure out and message. And you don't have to work on the large, important critical path user stories either. Just fixing bugs from time to time is enough to learn their tools, their conventions, keep current, be seen as competent by them (helps tremendously with being listened to in my experience) and still have time to actually do your other jobs properly, because coding comes last but not least.
Issue was that my loudest peers got promoted, while I kept delivering products and improving processes.
A manager should not be making tactical implementation decisions - they should trust their team to make those decisions, and offer higher level architecture & product guidance about the problems worth solving, the context and the constraints. Managers should be somewhat like 1/3 principle engineer, 1/3 product manager and 1/3 personnel / recruitment / rewards manager.
The absolute worst is when a company very openly embraces “team lead” or “player coach” roles, which are essentially an unspecified dumping ground of any arbitrary, flailing responsibility from any domain, with no clarity and with unrealistic expectations of “wearing many hats” and getting no staffing or team growth yet still being expected to deliver high project throughput and still somehow manage personnel issues, compensation, team building and so on.
“Team lead” is a bad cop out by senior leaders who are too weak to defend org structures they designed. They want to have their cake (take credit for constant reorgs) and eat it too (drop in to any part of a reorg that’s not succeeding and arbitrarily redefine a team lead role to mean whatever they want it to mean at that moment, for political convenience).
Even though it might be fun to still do coding, your life as a manager is so much better if you refuse anything like “team lead.” Don’t do it. Only accept roles with super explicit clarity that your job is to be a manager, not an implementer, and require a company culture that really backs this up and affirms it.
I can see some of what you are saying happening at my org too. I'm fighting it with I think enough success to be comfortable. What I mean is that my boss has recently tried to get me to commit to more coding and I refused. It makes zero sense to me to have a team lead commit to coding a specified "amount" (good luck measuring that properly anyway). It will only lead to "sorry nope can't help you, gotta make my own quota" type behaviour, which is definitely not what you want to encourage.
Fixing bugs to help the team out and having them concentrate on delivering the user stories in sprint while actually having some fun debugging sessions for a change? Awesome! :)