It's telling that bad leaders I've worked with exhibit opposite traits from OP's list. Off the cuff, they've had tendencies to:
- stubbornly devote majority of their time to coding, despite negative feedback of their leadership
- be consistently unaware of their calendar, to the point of developing a reputation for forgetting commitments
- insisting on being involved in every meeting, or being noticeably insecure when they weren't
- lack ability to execute on medium or long-term goals or visions
- being noticeably insecure when they were no longer the most experienced on the team
There's a time frame of forgiveness for some of that, but ultimately some degree of transition must occur for a leader to become effective. Their role, priority, and especially leverage, all change, and require corresponding changes in mindset and execution.
Good leaders I've worked for didn't just understand that, they embraced it. They also had enough supporting experience, intuition, and team respect to execute well on it. They showed not just acceptance, but perhaps later even a level of mastery, in their new role.
Which is all to say, one adapts and grows into an effective leader. And their leadership, in turn, grows into a distinguishing signal for team effectiveness, maybe even team happiness too. B/c of the teams I've worked for, I stuck w/good ones for longer than I would have expected largely due to positive environments fostered by the leaders at the time. I also left bad leaders earlier than I would have liked, despite having good relations w/teammates in general.
One reason these “bad leaders” may hit all your bullets is: the team members “call them out” for trying to operate a level above and a click longer term than the day-to-day fire fighting and grind.
The most common team expression of this is “You’re not close enough to it.” Or, “You don’t understand what it’s like.” As if “it” became different after stepping into leadership and the new leader underwent a mind wipe.
They didn’t forget what it’s like. They had derived intrinsic motivation from individual contribution, they understood it, they were great at it, and it still feels more valuable to them than the once removed levers of monkeying with ‘management’. This ‘bad leader’ who was part of the team, genuinely wants to be part of the team, but the team is rejecting their new role. So they stay operating in the trenches, at too low a level to influence the battle or the war.
On the contrary, unless the nature of tech engineering undergoes a shift, a “good leader” should not have to “be close to” the details of today’s particular glitch to remember what such glitches are like in general, and work to fix or remove that class of glitches now and for the team’s future.
Putting this in a metaphor that marries your bullets and this idea:
- Trust your team to roll the daily dice and advance their pieces around the Monopoly board
- Remain connected to whether the game is the same, mentor and advise strategies for wins, talk through whether they’re well set up to own the Orange monopolies…
- But instead of telling them how to play or — worse — grabbing the dice, work to rewrite the rules inside the Monopoly box lid to let their game be more effective and enable better outcomes
Leaders or Liaisons? If they don't have the teams respect in a technical way, are they really leaders, or are they just liaising with other teams on the unnamed true team leader's position?
I find a lot of teams have this sort of set up. It gets abused.
I've found this to be a trend across agile workplaces in general, they seem to have some hatred of outlook email/calendaring and decide to just post meetings in a slack or teams channel when they start, its infuriating.
A warning to directors of all shapes and kinds (people who manage managers, or direct their hiring/promotion): when you promote someone internally from an IC to a lead role, you're probably pushing them out of the company within a couple years.
If they fail miserably at the lead role, they will become disillusioned, maybe face a PIP if they fail bad enough, and best case will end up as a more grumpy IC that feels like the company screwed them over.
If they succeed, then you will almost certainly be unable or unwilling to pay them what some other similar company would pay them now that they have proven their ability as a lead. They will stick around for a while, but once something starts to go wrong anywhere on their team or in the company (and it will) they'll realize that it's probably going to be several years before there's any potential to climb the ladder any further, and they start to sniff around for what they should be making, and you'll lose them.
It's a valid choice to "burn" personnel this way because you need a project done and can reasonably hope that the person you're burning can get it done.
But it's generally less costly/risky to either a) fight the hard fight of getting an existing employee's salary in line with their new role immediately when they start it, or b) hire an external lead and fire quickly if they suck. The benefit of an external lead is that if they're really good, they might have director potential, which is even more valuable to promote someone into, and much more politically viable for someone who hasn't just been promoted to a lead/manager.
On that note, a warning to C-levels of all shapes and kinds: when you promote someone internally from lead to director,...
lol all of this advice is tailored towards crazy people at crazy companies. in a sane work environment it works quite logically -
1. You have an employee who has been with the company for years and thus has lots of hard won experience and knowledge about the particulars of your company
2. They have already been groomed for and shown potential to perform well in a lead role
3. You promote them to lead and pay them what they are worth, knowing that paying market wage is better than taking a gamble on a new hire and paying them market wage anyways.
its worrying that this kind of weird political shit always ends up highly voted in comment threads, because it colors your expectations. work for good, trustworthy, competent people, forget about this meta scheming bullshit and focus on doing your job well.
A common complaint is that it is too difficult to have career growth without changing companies and that promotions and raises are difficult to come by because companies don't care about developing their people. What you are saying now is that it is also bad if a company promotes people from within, since it encourages people to leave. Both options (never promote / encourage growth) can't be wrong.
IMO, this is not the way it works at any reasonable place. I've had zero engineers under me leave over the last four years and I attribute that in large part to me being able to meet their career growth goals within my team.
I don't think this is practical for any reasonably sized company to hire all their lead/manager positions from outside.
I agree, it is probably better to follow your option (a), but does not looks like companies do that proactively. Looks like the whole edifice is centered on the fact that people don't have enough time in their hands to go find a job somewhere else.
> If they succeed, then you will almost certainly be unable or unwilling to pay them what some other similar company would pay them now that they have proven their ability as a lead.
This assumes all companies are unable to pay market rate for leads. Otherwise it is mathematically impossible.
So, easy fix is raise pay for internal people when they prove themselves in new role and match market salary.
>If they succeed, then you will almost certainly be unable or unwilling to pay them what some other similar company would pay them now that they have proven their ability as a lead. They will stick around for a while, but once something starts to go wrong anywhere on their team or in the company (and it will) they'll realize that it's probably going to be several years before there's any potential to climb the ladder any further, and they start to sniff around for what they should be making, and you'll lose them.
Additionally, there also might be one or two ladder climbers in the lead's org who considered themselves "sure thing" for that lead promotion. They did not get it because you promoted someone else. They will be disillusioned and are very likely to be gone within a year. An unfortunate, but natural consequence of the fact that there are always fewer opportunities to lead than there are people looking to grow. Make sure you can handle losing the overachievers who finished in 2nd place.
If you're managing teams, a tech-lead, a manager, startup founder, or just someone who wants to learn more about owning problems, I can recommend reading or listening to "Extreme Ownership" by Jocko Willink [1] (fmr US Navy Seal)
Compared to other Audiobooks I've listened to, this one is an engaging listen, and teaches good lessons about both team management and owning problems that is practical.
It’s kinda funny to me, I had a job once full of leaders and managers who were constantly invoking Jocko, Simon Sinek and other leadership and management tomes and were just as frequently beating their chests for having read the right books on how to lead…
…meanwhile the rank and file at the company were openly (at least in multiple conversations in external chat and text message groups away from the eyes of said managers and leaders) sick of it because the same managers and leaders seemed to predictably and consistently do the exact opposite of whatever they’d gloat about reading from the Jockos and Simons during All Hands Zooms to the peril and resignation of much of the workforce this summer.
I curiously glanced at Glassdoor and chuckled seeing a few reviews bringing this up.
I really like this article. Some tech lead articles try to give exhaustive lists of everything you should know and do, this is more focused.
My 2c: tech lead is a comms channel between team and rest of org; mentor for others in the team; part time architect and also keeps an eye on processes.
My two key lessons (or advice) learned for new tech leads:
1. Find your shortcomings, and fix them. An individual contributor is great is because of his/her strength; a tech lead is great is because of he/she is well balanced. OP's list is a very good start: if you're not delegating enough, try delegate more; if you don't have a clear vision, try spend time working on it. You'll get better at them over time, to be a well balanced tech lead. prioritize on fixing shortcomings before reinforce strengths.
2. You have some authority, use it. More specifically, consider asking for resources instead of exhaust you and your team in reaching of local maximum. You're the brigade commander, you probably can't decide which battlefield you and your team are marching in, but you can try ask for more shells and airstrikes.
The 2nd point is really important for me. It took me a while to take control over certain resources and to stop asking for permission all the time.
Having the power to just do things is the trade-off you make when giving up some of your code time. I haven't asked for permission to do a thing in a long time.
None of this is to say you shouldn't plan and work with the team, but when it's clear you need a new developer PC or a cloud resource, just go pay for the damn thing and get it dealt with.
Time is money and being sensitive to this reality can make all the difference in the universe. A secondary thing to think about is "Can I undo this action?". 99% of the time in technology - the answer is "Yes". Realizing this, I try to empower others in the same way I have empowered myself.
Ugh, this role screams corporate bullshit. In 5-10 years in the role OP described you are pretty much useless. You're not 'leading' anything and you're barely 'tech' at all. You send emails and attend meetings. Once you've entered into a defending your calendar position you're done.
IMO, a tech lead position should be someone who has authority to make technical decisions such as what programming language to use, what framework, how much test code coverage should be in place, what skills need to be learned, final decision in a team dispute/decision, what CI tools are in place, when to do rewrites and when not to. Still a coder and contributor though.
One thing that maybe isn't captured in the "relationship transition" section is aside from "telling your former peers they have to do things they might not like" you have to also tell other people (your manager probably) that your former peers _won't_ do what's being asked or will do it on a later timeline. A lot of new team leads miss that part. In any sufficiently large effort, there is going to be N owners of N priorities, and all of them are going to see the single one they have as the most important and have no real incentive (in most places) against burning your team out to get their pet project done. That's where you come in.
What this typically means is the team lead thinks they're entitled to do the interesting work, like designing new features, exploring new ideas, and everyone else gets to fix the bugs and implement their half baked ideas. Then the developers push back, because no, we're just as capable as the 'team lead' and don't care what you think.
Biggest thing I learned was to just stay out of everyone's way.
Worst case for us, someone makes a horrible code change and we just revert it to a prior good state.
Very few things we do in technology are irreversible, so I don't worry about someone doing the wrong thing. I think of these mistakes as very cheap lessons now.
I recall that a musically-inclined UU minister riff'd a particular lyric off of an Eisenhower quote regarding along the lines of "If the people want peace, better get out of the way".
I also recall the meme-like time management thinking about 10 years ago regarding having a block of uninterrupted time to think and produce stuff [be it coding or otherwise]. Someone randomly dropping into your cubical all "did you get that email I just sent you" completely derailing your thought process and hard-booting you back to zero when they scuttle onward with their coffee mug thinking they did nothing wrong in being so sociable. The "I get my best work done between 3am-6am because everyone else is asleep and not in the office" thinking.
[+] [-] mzarate06|4 years ago|reply
Good leaders I've worked for didn't just understand that, they embraced it. They also had enough supporting experience, intuition, and team respect to execute well on it. They showed not just acceptance, but perhaps later even a level of mastery, in their new role.
Which is all to say, one adapts and grows into an effective leader. And their leadership, in turn, grows into a distinguishing signal for team effectiveness, maybe even team happiness too. B/c of the teams I've worked for, I stuck w/good ones for longer than I would have expected largely due to positive environments fostered by the leaders at the time. I also left bad leaders earlier than I would have liked, despite having good relations w/teammates in general.
[+] [-] Terretta|4 years ago|reply
The most common team expression of this is “You’re not close enough to it.” Or, “You don’t understand what it’s like.” As if “it” became different after stepping into leadership and the new leader underwent a mind wipe.
They didn’t forget what it’s like. They had derived intrinsic motivation from individual contribution, they understood it, they were great at it, and it still feels more valuable to them than the once removed levers of monkeying with ‘management’. This ‘bad leader’ who was part of the team, genuinely wants to be part of the team, but the team is rejecting their new role. So they stay operating in the trenches, at too low a level to influence the battle or the war.
On the contrary, unless the nature of tech engineering undergoes a shift, a “good leader” should not have to “be close to” the details of today’s particular glitch to remember what such glitches are like in general, and work to fix or remove that class of glitches now and for the team’s future.
Putting this in a metaphor that marries your bullets and this idea:
- Trust your team to roll the daily dice and advance their pieces around the Monopoly board
- Remain connected to whether the game is the same, mentor and advise strategies for wins, talk through whether they’re well set up to own the Orange monopolies…
- But instead of telling them how to play or — worse — grabbing the dice, work to rewrite the rules inside the Monopoly box lid to let their game be more effective and enable better outcomes
[+] [-] fartcannon|4 years ago|reply
I find a lot of teams have this sort of set up. It gets abused.
[+] [-] nikau|4 years ago|reply
I've found this to be a trend across agile workplaces in general, they seem to have some hatred of outlook email/calendaring and decide to just post meetings in a slack or teams channel when they start, its infuriating.
[+] [-] cornel_io|4 years ago|reply
If they fail miserably at the lead role, they will become disillusioned, maybe face a PIP if they fail bad enough, and best case will end up as a more grumpy IC that feels like the company screwed them over.
If they succeed, then you will almost certainly be unable or unwilling to pay them what some other similar company would pay them now that they have proven their ability as a lead. They will stick around for a while, but once something starts to go wrong anywhere on their team or in the company (and it will) they'll realize that it's probably going to be several years before there's any potential to climb the ladder any further, and they start to sniff around for what they should be making, and you'll lose them.
It's a valid choice to "burn" personnel this way because you need a project done and can reasonably hope that the person you're burning can get it done.
But it's generally less costly/risky to either a) fight the hard fight of getting an existing employee's salary in line with their new role immediately when they start it, or b) hire an external lead and fire quickly if they suck. The benefit of an external lead is that if they're really good, they might have director potential, which is even more valuable to promote someone into, and much more politically viable for someone who hasn't just been promoted to a lead/manager.
On that note, a warning to C-levels of all shapes and kinds: when you promote someone internally from lead to director,...
[+] [-] zaptheimpaler|4 years ago|reply
1. You have an employee who has been with the company for years and thus has lots of hard won experience and knowledge about the particulars of your company
2. They have already been groomed for and shown potential to perform well in a lead role
3. You promote them to lead and pay them what they are worth, knowing that paying market wage is better than taking a gamble on a new hire and paying them market wage anyways.
its worrying that this kind of weird political shit always ends up highly voted in comment threads, because it colors your expectations. work for good, trustworthy, competent people, forget about this meta scheming bullshit and focus on doing your job well.
[+] [-] UncleMeat|4 years ago|reply
A common complaint is that it is too difficult to have career growth without changing companies and that promotions and raises are difficult to come by because companies don't care about developing their people. What you are saying now is that it is also bad if a company promotes people from within, since it encourages people to leave. Both options (never promote / encourage growth) can't be wrong.
IMO, this is not the way it works at any reasonable place. I've had zero engineers under me leave over the last four years and I attribute that in large part to me being able to meet their career growth goals within my team.
[+] [-] metb|4 years ago|reply
[+] [-] watwut|4 years ago|reply
This assumes all companies are unable to pay market rate for leads. Otherwise it is mathematically impossible.
So, easy fix is raise pay for internal people when they prove themselves in new role and match market salary.
[+] [-] drbojingle|4 years ago|reply
[+] [-] sundae|4 years ago|reply
[+] [-] rmac|4 years ago|reply
Failing miserably is less likely given you have some "success in role" criteria they are clearly demonstrating beforehand.
Not sure I follow the burn concept here? If they are shitty why promo, unless you want the initiative to fail? If they are good see above
[+] [-] geoduck14|4 years ago|reply
Oh wow. This was the EXACT thing to happen to me.
[+] [-] ryandrake|4 years ago|reply
[+] [-] learc83|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] goldenchrome|4 years ago|reply
[+] [-] sordina|4 years ago|reply
[+] [-] hyperpallium2|4 years ago|reply
[+] [-] plasma|4 years ago|reply
Compared to other Audiobooks I've listened to, this one is an engaging listen, and teaches good lessons about both team management and owning problems that is practical.
[1] https://www.amazon.com.au/Extreme-Ownership-Jocko-Willink/dp... and https://www.audible.com.au/pd/Extreme-Ownership-Audiobook/B0...
[+] [-] dvtrn|4 years ago|reply
It’s kinda funny to me, I had a job once full of leaders and managers who were constantly invoking Jocko, Simon Sinek and other leadership and management tomes and were just as frequently beating their chests for having read the right books on how to lead…
…meanwhile the rank and file at the company were openly (at least in multiple conversations in external chat and text message groups away from the eyes of said managers and leaders) sick of it because the same managers and leaders seemed to predictably and consistently do the exact opposite of whatever they’d gloat about reading from the Jockos and Simons during All Hands Zooms to the peril and resignation of much of the workforce this summer.
I curiously glanced at Glassdoor and chuckled seeing a few reviews bringing this up.
[+] [-] bob1029|4 years ago|reply
I think the central theme of "the buck stops with whomever" is very important to take to heart, but some of the delivery is a bit over the top.
What would be more useful to me is a book that explains in painstaking detail how to inception these concepts into others on a reliable basis.
[+] [-] wsostt|4 years ago|reply
[+] [-] belter|4 years ago|reply
"Why I'm so good at coding" https://youtu.be/xqgH9j3x2OE
[+] [-] ravenstine|4 years ago|reply
[+] [-] davedx|4 years ago|reply
My 2c: tech lead is a comms channel between team and rest of org; mentor for others in the team; part time architect and also keeps an eye on processes.
[+] [-] ac50hz|4 years ago|reply
A tech lead is a team lead, a diplomat, a politician, a planner, sometimes a shoulder, a mediator, an historian, and a responsible decision maker.
They sometimes have an uncanny ability to predict behaviour, predict failures or predict the future.
Hopefully, they can bring calm, decisive behaviour and transparent mentoring.
And yes, that doesn’t leave much time for critical-path coding.
[+] [-] drran|4 years ago|reply
[+] [-] namelosw|4 years ago|reply
1. Find your shortcomings, and fix them. An individual contributor is great is because of his/her strength; a tech lead is great is because of he/she is well balanced. OP's list is a very good start: if you're not delegating enough, try delegate more; if you don't have a clear vision, try spend time working on it. You'll get better at them over time, to be a well balanced tech lead. prioritize on fixing shortcomings before reinforce strengths.
2. You have some authority, use it. More specifically, consider asking for resources instead of exhaust you and your team in reaching of local maximum. You're the brigade commander, you probably can't decide which battlefield you and your team are marching in, but you can try ask for more shells and airstrikes.
[+] [-] bob1029|4 years ago|reply
Having the power to just do things is the trade-off you make when giving up some of your code time. I haven't asked for permission to do a thing in a long time.
None of this is to say you shouldn't plan and work with the team, but when it's clear you need a new developer PC or a cloud resource, just go pay for the damn thing and get it dealt with.
Time is money and being sensitive to this reality can make all the difference in the universe. A secondary thing to think about is "Can I undo this action?". 99% of the time in technology - the answer is "Yes". Realizing this, I try to empower others in the same way I have empowered myself.
[+] [-] Graffur|4 years ago|reply
IMO, a tech lead position should be someone who has authority to make technical decisions such as what programming language to use, what framework, how much test code coverage should be in place, what skills need to be learned, final decision in a team dispute/decision, what CI tools are in place, when to do rewrites and when not to. Still a coder and contributor though.
[+] [-] dccoolgai|4 years ago|reply
[+] [-] linuxftw|4 years ago|reply
[+] [-] bob1029|4 years ago|reply
Worst case for us, someone makes a horrible code change and we just revert it to a prior good state.
Very few things we do in technology are irreversible, so I don't worry about someone doing the wrong thing. I think of these mistakes as very cheap lessons now.
[+] [-] drdeadringer|4 years ago|reply
I also recall the meme-like time management thinking about 10 years ago regarding having a block of uninterrupted time to think and produce stuff [be it coding or otherwise]. Someone randomly dropping into your cubical all "did you get that email I just sent you" completely derailing your thought process and hard-booting you back to zero when they scuttle onward with their coffee mug thinking they did nothing wrong in being so sociable. The "I get my best work done between 3am-6am because everyone else is asleep and not in the office" thinking.
[+] [-] ssss11|4 years ago|reply
[+] [-] scns|4 years ago|reply
[+] [-] Aeolun|4 years ago|reply
[+] [-] sys_64738|4 years ago|reply
[+] [-] yashwastaken|4 years ago|reply
[+] [-] LightG|4 years ago|reply
"What I Learnt Becoming a Tech Lead (as a millionaire)"
[+] [-] tommek4077|4 years ago|reply