What I Learnt Becoming a Tech Lead(tomgamon.com)
tomgamon.com
What I Learnt Becoming a Tech Lead
https://tomgamon.com/posts/things-i-have-learned-new-tech-lead/
103 comments
> be consistently unaware of their calendar
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.
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.
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 find a lot of teams have this sort of set up. It gets abused.
I don't think effective leadership requires that you be highly respected for your technical skills. Leadership requires that you're at least competent in technical understanding, but also competent across multiple domains too.
They don't have to be the most technical, but have enough chops to smell BS when it's being sold.
A good comparison would be how a good military captain or general doesn't have to be the best marksman, medic, or radioman, but they should know enough to coordinate those roles and understand how they should work.
They don't have to be the most technical, but have enough chops to smell BS when it's being sold.
A good comparison would be how a good military captain or general doesn't have to be the best marksman, medic, or radioman, but they should know enough to coordinate those roles and understand how they should work.
There's truth to what you're saying, but good leadership means different things in different contexts/teams.
The teams I oversee have a comfort aspect to knowing that I can drop onto any situation and set the proper direction both from a political and technical standpoint. I don't think I'd feel comfortable with my role if I didn't have the technical knowledge to get __very__ specific on what direction to take. I try to be clear when I'm discussing a general best direction versus my personal preference, the latter arising usually when we're discussing subject matters I'm not as familiar with. When I am more confident in the way I think is ideal to handle something and have a specific desired outcome, I present more direct instruction. When we're exploring new territory for the team, then I try to share how I would approach this new territory so my team can have a place to start, and this seems to bring a lot of comfort to my newer team members.
A lot of people in management (general "management") treat the role like a position that tells people general guidelines on what to do, and that's when there are issues; "fix the problem" is of course a clear enough outcome, but it's still vague on how to get there or what the fix looks like. More specific instructions or guidance on different ways to get there and suggestions as to how to understand the problem scope that are digestible for your team is far more important than stating the obvious of "we need to get X resolved by Y date."
The example of a military hierarchy I get, and there is a value to it, but for me, leadership is about setting your team up to let them shine and helping to shield them from the elements that just drag them down or dull their senses.
The teams I oversee have a comfort aspect to knowing that I can drop onto any situation and set the proper direction both from a political and technical standpoint. I don't think I'd feel comfortable with my role if I didn't have the technical knowledge to get __very__ specific on what direction to take. I try to be clear when I'm discussing a general best direction versus my personal preference, the latter arising usually when we're discussing subject matters I'm not as familiar with. When I am more confident in the way I think is ideal to handle something and have a specific desired outcome, I present more direct instruction. When we're exploring new territory for the team, then I try to share how I would approach this new territory so my team can have a place to start, and this seems to bring a lot of comfort to my newer team members.
A lot of people in management (general "management") treat the role like a position that tells people general guidelines on what to do, and that's when there are issues; "fix the problem" is of course a clear enough outcome, but it's still vague on how to get there or what the fix looks like. More specific instructions or guidance on different ways to get there and suggestions as to how to understand the problem scope that are digestible for your team is far more important than stating the obvious of "we need to get X resolved by Y date."
The example of a military hierarchy I get, and there is a value to it, but for me, leadership is about setting your team up to let them shine and helping to shield them from the elements that just drag them down or dull their senses.
What you call “a comfort aspect” is something experienced ICs think of “micromanagement.” It does not bring me comfort when a lead decides to “get __very__ specific on what direction to take.” On the contrary, it makes me feel like they do not trust my judgment, which is an uncomfortable feeling indeed.
It is hard not to notice that the entirety of this response is about YOUR personal comfort level and YOUR perceptions as lead, with an afterthought noting that your newest team members seem to find comfort in it. You must recognize that your working relationship with them involves a marked power differential. Your junior employees are unlikely to voice any disagreement with your management style, but that does not imply it is a good style of leadership.
There is no mention of how you manage your more seasoned team members. Is that because there aren’t any left? This style of management often leads to retention problems as employees mature and realize there are more satisfying ways for them to work.
It is hard not to notice that the entirety of this response is about YOUR personal comfort level and YOUR perceptions as lead, with an afterthought noting that your newest team members seem to find comfort in it. You must recognize that your working relationship with them involves a marked power differential. Your junior employees are unlikely to voice any disagreement with your management style, but that does not imply it is a good style of leadership.
There is no mention of how you manage your more seasoned team members. Is that because there aren’t any left? This style of management often leads to retention problems as employees mature and realize there are more satisfying ways for them to work.
Sure, in the military, where disobedience is severely punished, you can think of your team like that.
I don't think that applies to just the military. If you actively disobey your boss' direction and do something completely opposite, I'm sure you'd be dismissed or punished for that too.
I really hope you don't actually believe that!
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
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
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,...
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.
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.
If you’re in high tech (FAANG) the salaries have been going up so quickly year by year since 2000 that staying in one company for more than a few years is often irrational if you’re trying to maximize salary. Companies will gladly pay you an extra 50-100k a year just to steal you from a FAANG.
Your points make total sense though. Companies lose out by not having employees who have built up institutional knowledge, but in today’s market most of the people who companies want the most are likely to leave for greener pastures in 2 years.
Your points make total sense though. Companies lose out by not having employees who have built up institutional knowledge, but in today’s market most of the people who companies want the most are likely to leave for greener pastures in 2 years.
The thing is: not everyone wants to be a “leader”, and rejecting a promotion is basically saying “goodbye” to be company that is offering you the promotion. I was in this exact same situation: I ended up quitting because I’m not a “leader”.
> all of this advice is tailored towards crazy people at crazy companies.
Given high turnover, that is probably most people though.
Given high turnover, that is probably most people though.
This, frankly, seems ridiculous.
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.
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.
Have you also been able to adjust their salaries accordingly? My interpretation is that rather than saying, "don't promote internally from IC to Lead" GP is saying "here are some pitfalls with that approach" and suggests that it can work fine if you can bring their compensation up fast enough that the money isn't greener elsewhere by the time they can spin their newfound leadership experience into a job offer.
Extra responsibility/accountability/risk without corresponding compensation reads like a promotion to some folks, but to other folks it looks more like a pay cut.
Extra responsibility/accountability/risk without corresponding compensation reads like a promotion to some folks, but to other folks it looks more like a pay cut.
The problem with offering promotions to people already in your company is: what if they don’t actually want the promotion? (Promotions involve more responsibilities and not everyone wants that). And usually, Rejecting a promotion is seen as a bad thing (“oh, Joe doesn’t look ambitious enough!”).
In practice it isn't supposed to be like this. You should be working with your manager over 2 to 8 quarters or more to plan the promotion. The promotion will be won from a committee by your manager. The expectations should be clear.
You obviously talk to them first.
Rejecting a promotion can be seen as bad in toxic places or for junior engineers, but I actually like hearing this from my reports because it means that I don't need to make changes to accommodate their growth.
Rejecting a promotion can be seen as bad in toxic places or for junior engineers, but I actually like hearing this from my reports because it means that I don't need to make changes to accommodate their growth.
>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.
Oh wow. This was the EXACT thing to happen to me.
Oh wow. This was the EXACT thing to happen to me.
Haha, this also happened to me.
Although in my defense, I was actually thinking of leaving the company before becoming lead. In fact I probably stayed longer than I would have otherwise due to the opportunity.
Although in my defense, I was actually thinking of leaving the company before becoming lead. In fact I probably stayed longer than I would have otherwise due to the opportunity.
This has happened to me twice as well, which is why I raised it. I've also seen it happen to people I've promoted and was unable to get up to market rate, who I had extremely honest conversations with as they became disillusioned and ultimately supported as they left for greener pastures, and that's when I realized it's a systemic problem. I'm not being cynical or scheme-ey bringing this up at all, it's just the (bigco, mostly) reality, and directors need to be aware of it.
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.
Your company promotes directly from tech lead to director?
I'm now at a startup, so no (director == founding exec until you reach a certain size). But yes, for some definition of "lead" which involves managing a bunch of people as well, and director, which involves managing a bunch of managers, that's something that happens.
Small team tech-only leads who are not managing people will not typically be promoted to director levels at most big companies, but if you're actually managing people and your skip-manager loves you, it's totally possible even if your team is small.
Small team tech-only leads who are not managing people will not typically be promoted to director levels at most big companies, but if you're actually managing people and your skip-manager loves you, it's totally possible even if your team is small.
What’s your final advice about C-levels? Looks like you ended the comment early. Thanks.
Manager => director has a lot of the same pitfalls as IC => manager/lead. I was trying to imply that this is a recursive problem.
And who is that external lead? The guy your describing but from company b.
But that person can be paid what they're worth without Politics and horse trading because it's a hire (The Market, etc), not a promotion.
Give them some meaningful compensation in options.
Sorry, what does IC and PIP mean in this context?
Individual Contributor (primarily makes stuff directly rather than working through other people) and Performance Improvement Plan (supposedly a plan to improve performance, but often actually just HR making sure they have watertight documentation justifying sacking the person).
IC = Individual Contributor
PIP = Performance Improvement Plan
PIP = Performance Improvement Plan
And more realistically Paid Interview Practice.
Individual Contributor and Performance Improvement Plan
What's the alternative? If they are really good they will leave anyway, so challenge and coach them until they do.
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
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
If they are really good then either figure out how to pay them (a lot) more, or don't put them in a higher responsibility role. Promotion without a pay bump equivalent to what they'll get from a move to another company might as well be a firing.
> 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.
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.
[deleted]
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.
both a and b involve paying more
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.
[1] https://www.amazon.com.au/Extreme-Ownership-Jocko-Willink/dp... and https://www.audible.com.au/pd/Extreme-Ownership-Audiobook/B0...
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...
I was told to read this by one of my investors.
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.
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.
Thanks for the recommendation. Just purchased the audiobook.
Anecdote wrapped in a non-sequitur:
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.
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've never had a manager who "owned" anything, let alone to an "extreme" degree. It's ICs who are responsible for shipping quality work on time, sometimes at the expense of their health and personal lives. And it's ICs who take the heat when projects go off-track.
That sucks if that’s your reality. It means you’ve never had a manager that protects their team and sets them up for success.
If my teams are struggling it’s my fault in the eyes of external stakeholders and I own that. If my direct reports cause an issue I expect them to fix it, but that isn’t used as a reason for the failure outside the team.
If my teams are struggling it’s my fault in the eyes of external stakeholders and I own that. If my direct reports cause an issue I expect them to fix it, but that isn’t used as a reason for the failure outside the team.
I've had a couple who came very close, circumstance and the usual bureaucracy precluded their ownership reaching the top of the 'extreme' spectrum.
Give them credit for even doing as much as they did, to be honest.
Give them credit for even doing as much as they did, to be honest.
I'm going to stand next to you and roll my eyes with you before sharing the other thought :D
I've recently made a transition from a senior-level IC (think ~Principal/Staff level) to leading a small team of primarily fresh grads. While I haven't explicitly mentioned any of the Extreme Ownership stuff to them, I did take a lot of his points to heart when I first listened to the book. I feel like actually using and embodying those principles has worked out really well so far, especially from a lead-by-example perspective.
Ideas like:
- Managing up and down the chain of command. They've seen it in action where I'm taking their ideas and feedback upwards to try to figure out how to line up senior management's plans with the junior folks' good ideas. They do the same thing with me; if there's something missing in what I'm giving them (either an understanding of intent, or some kind of technical resource, or equipment, or whatever), they quickly and consistently let me know about it.
- Owning mistakes. I have fucked up. I publicly admit when I fuck up in meetings with my peers and the broader leadership in the company. If one of my subordinates fucks up, I own that too, along with, if asked, an explanation of how we've modified our processes to mitigate similar mistakes in the future. My subordinates immediately come and tell me when they screw up. It's super refreshing. One of the fresh grads smoked $10,000 worth of electronics by hooking the power supply up wrong. He came and found me while I was on a smoke break to tell me.
- Owning cross-team mistakes, sort of. There are other teams in the company that are notorious for shipping half-baked code or hardware designs. These are peer teams so while I can offer up design/implementation ideas, I have no authority myself to require them to listen to me. Where the issues end up manifesting themselves is during the system integration; the APIs between our stuff generally works, but their side of it has a habit of being flaky. To have overall successful outcomes, we try to "own" this by: a) pushing for early integration smoke testing early, b) pushing very hard for all code to be pushed to Bitbucket early (in which we also lead by example), and c) rolling up our sleeves and doing what we need to do to have a successful outcome (whether this is helping them debug/redesign, or doing code reviews, or whatever). Organizationally, I think my peers and layers above me have a pretty solid understanding of what my team contributes to the overall success.
- Commander's intent. When upper management asks for something, whether or not it makes sense at first blush, I try to dig into the rationale behind it and how it fits into the bigger picture. On the other side of this, I don't just throw tasks or projects at the team; we sit down, I explain how it fits into the bigger picture, how it's likely to evolve based on my understanding of the situation, etc. And in return, they generally do superb work that doesn't really require much rework. While not implementing all of the "maybe happening in the future" features (thank God, that would take forever), the designs and implementations they come up with have the future plans in mind. I don't think we've ever had to scrap a module and rewrite it from scratch, because they design things with just enough flexibility given the bigger context.
- "My Shit Umbrella". There's a lot of behind the scenes chaos that goes on, and I do my damnedest to isolate the members of my team from it so that they can focus on getting their jobs done. If there's a shit storm coming I let them know about it early and we brainstorm ways we can try to prevent it.
- Disagree and Commit. I absolutely understand that my ideas/plans will not always be the direction we go, and I'm ok with that. During the planning stages with my peers and upper management, I will quite vocally express myself if something seems like a bad plan for whatever reason, but ultimately it's not my decision. If the CEO decides to go a direction I disagree with, I set aside my ego and do my damnedest to execute on his plan. The same goes with my team. The shit umbrella isn't 100% impermeable, and when push comes to shove, my team will push back on bad ideas, but if I do decide to pull rank and say "just do it", they roll up their sleeves and do it at full effort. This, along with "Commander's Intent" and other ideas, is very much a lead-by-example thing.
I've recently made a transition from a senior-level IC (think ~Principal/Staff level) to leading a small team of primarily fresh grads. While I haven't explicitly mentioned any of the Extreme Ownership stuff to them, I did take a lot of his points to heart when I first listened to the book. I feel like actually using and embodying those principles has worked out really well so far, especially from a lead-by-example perspective.
Ideas like:
- Managing up and down the chain of command. They've seen it in action where I'm taking their ideas and feedback upwards to try to figure out how to line up senior management's plans with the junior folks' good ideas. They do the same thing with me; if there's something missing in what I'm giving them (either an understanding of intent, or some kind of technical resource, or equipment, or whatever), they quickly and consistently let me know about it.
- Owning mistakes. I have fucked up. I publicly admit when I fuck up in meetings with my peers and the broader leadership in the company. If one of my subordinates fucks up, I own that too, along with, if asked, an explanation of how we've modified our processes to mitigate similar mistakes in the future. My subordinates immediately come and tell me when they screw up. It's super refreshing. One of the fresh grads smoked $10,000 worth of electronics by hooking the power supply up wrong. He came and found me while I was on a smoke break to tell me.
- Owning cross-team mistakes, sort of. There are other teams in the company that are notorious for shipping half-baked code or hardware designs. These are peer teams so while I can offer up design/implementation ideas, I have no authority myself to require them to listen to me. Where the issues end up manifesting themselves is during the system integration; the APIs between our stuff generally works, but their side of it has a habit of being flaky. To have overall successful outcomes, we try to "own" this by: a) pushing for early integration smoke testing early, b) pushing very hard for all code to be pushed to Bitbucket early (in which we also lead by example), and c) rolling up our sleeves and doing what we need to do to have a successful outcome (whether this is helping them debug/redesign, or doing code reviews, or whatever). Organizationally, I think my peers and layers above me have a pretty solid understanding of what my team contributes to the overall success.
- Commander's intent. When upper management asks for something, whether or not it makes sense at first blush, I try to dig into the rationale behind it and how it fits into the bigger picture. On the other side of this, I don't just throw tasks or projects at the team; we sit down, I explain how it fits into the bigger picture, how it's likely to evolve based on my understanding of the situation, etc. And in return, they generally do superb work that doesn't really require much rework. While not implementing all of the "maybe happening in the future" features (thank God, that would take forever), the designs and implementations they come up with have the future plans in mind. I don't think we've ever had to scrap a module and rewrite it from scratch, because they design things with just enough flexibility given the bigger context.
- "My Shit Umbrella". There's a lot of behind the scenes chaos that goes on, and I do my damnedest to isolate the members of my team from it so that they can focus on getting their jobs done. If there's a shit storm coming I let them know about it early and we brainstorm ways we can try to prevent it.
- Disagree and Commit. I absolutely understand that my ideas/plans will not always be the direction we go, and I'm ok with that. During the planning stages with my peers and upper management, I will quite vocally express myself if something seems like a bad plan for whatever reason, but ultimately it's not my decision. If the CEO decides to go a direction I disagree with, I set aside my ego and do my damnedest to execute on his plan. The same goes with my team. The shit umbrella isn't 100% impermeable, and when push comes to shove, my team will push back on bad ideas, but if I do decide to pull rank and say "just do it", they roll up their sleeves and do it at full effort. This, along with "Commander's Intent" and other ideas, is very much a lead-by-example thing.
Yeah no don't get me wrong, I served in the Armed Forces and I like you recently intentionally stepped back from leadership back to being an IC. Decided it's just not for me and I'd much rather not ever do it again, or if I am going to do it, it will be when I start my own business (whenever that happens).
Jocko has a lot of really valuable insights on running a good team and being a good servant leader, as much as I sometimes genuinely loath the co-opting of certain bits of military lingo and phraseology in the corporate world, it can't be ignored that Jocko has some good thoughts
And while I roll my eyes at some of them, I roll my eyes harder when I see leaders acting like varsity braggarts, quoting (often misquoting) the likes of Jocko and Mattis in an attempt to be "inspirational" to the workforce while their consistent and predictable actions make it painfully obvious they either missed the point of the military men they're quoting, or they're deliberately putting on a show.
So to your point, yeah, actually embodying the principles works out really well.
Which is the exact challenge it seems like a lot of the types of leaders who just want to beat the drum and not march with the formation.
Jocko has a lot of really valuable insights on running a good team and being a good servant leader, as much as I sometimes genuinely loath the co-opting of certain bits of military lingo and phraseology in the corporate world, it can't be ignored that Jocko has some good thoughts
And while I roll my eyes at some of them, I roll my eyes harder when I see leaders acting like varsity braggarts, quoting (often misquoting) the likes of Jocko and Mattis in an attempt to be "inspirational" to the workforce while their consistent and predictable actions make it painfully obvious they either missed the point of the military men they're quoting, or they're deliberately putting on a show.
So to your point, yeah, actually embodying the principles works out really well.
Which is the exact challenge it seems like a lot of the types of leaders who just want to beat the drum and not march with the formation.
“Do not give dogs what is sacred; do not throw your pearls to pigs. If you do, they may trample them under their feet, and turn and tear you to pieces.”
Matthew 7:6
Someone who lacks character and won't admit it is not going to be improved simply by making resources available. They'll just integrate those resources into their already flawed character, digging the flaws even deeper.
It's that fun conundrum where those who can best apply the advice often don't need it, and those that need it are incapable of applying it.
Matthew 7:6
Someone who lacks character and won't admit it is not going to be improved simply by making resources available. They'll just integrate those resources into their already flawed character, digging the flaws even deeper.
It's that fun conundrum where those who can best apply the advice often don't need it, and those that need it are incapable of applying it.
Yeah, hahaha that's where the eye rolling comes in. When I first read the book I was working at a different company and recommended it pretty broadly as a set of principles that would help us in dealing with a specific frustrating customer and another organization that they had partnered with.
To their credit, I believe the entire C-suite did actually read/listen to the book after I recommended it. And talked the talk quite a bit, but continued things exactly how they had been before.
To their credit, I believe the entire C-suite did actually read/listen to the book after I recommended it. And talked the talk quite a bit, but continued things exactly how they had been before.
+1
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.
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.
Team lead is known as "project manager". Tech lead is just the most experienced person on the project.
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.
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.
A great article on the same topic, read it just days ago: https://www.dein.fr/2014-01-29-learnings-from-six-months-as-...
As an aside I wanted to say I love the theme used by this blog.
There is only one Tech Lead:
"Why I'm so good at coding" https://youtu.be/xqgH9j3x2OE
"Why I'm so good at coding" https://youtu.be/xqgH9j3x2OE
9 month into the job. Maybe put a "junior" into the headline.
Gatekeeping like this doesn't do anyone any benefit, aside from trying to inflate your ego at the expense of others. If you feel the need to make snarky comments like this, it may be a good moment to stop and ask yourself why.
This isn't gatekeeping, this is signaling that the lead might lack experience to even live through consequences of his processes and decisions.
If you've never finished a project, lived through political, technological and social consequences of your actions, what use is your experience? You could make any decisions and you wouldn't know if they're worth anything.
Doesn't mean his post is useless or worthless - but it does give important context to his writing.
If you've never finished a project, lived through political, technological and social consequences of your actions, what use is your experience? You could make any decisions and you wouldn't know if they're worth anything.
Doesn't mean his post is useless or worthless - but it does give important context to his writing.
That's a good comment. A lot of people who give advice have never had to live through the long term consequences of their decisions. I have delivered systems that I thought were really well architected at the time but it turned there were a ton of problems and mistakes that cost us dearly years later.
The whole point of titles is to signal some kind of useful information about competence level, etc.
Titles are the exact time we should do some gatekeeping. Being called a “senior engineer” with only 2-3 years is frankly a joke.
Titles are the exact time we should do some gatekeeping. Being called a “senior engineer” with only 2-3 years is frankly a joke.
It does serve to benefit the reader.
Knowing if someone is new to what they are discussing makes the reader less likely to take what they say at face value.
While you should still be critical of people who have experience, it probably will hurt you less or give you different insights if what they are saying comes from experience.
For example, I'm fairly certain the world of web programming would be way better off if lots of those tutorials had some sort of "I didn't know what HTTP or arrays were a couple of weeks ago" disclaimer :|
Knowing if someone is new to what they are discussing makes the reader less likely to take what they say at face value.
While you should still be critical of people who have experience, it probably will hurt you less or give you different insights if what they are saying comes from experience.
For example, I'm fairly certain the world of web programming would be way better off if lots of those tutorials had some sort of "I didn't know what HTTP or arrays were a couple of weeks ago" disclaimer :|
I have a guy at my job talking about himself as a senior devops engineer when he has like a few months of data engineering experience and comes from an analytics background.
why is this, it feels like every other person is a senior nowadays. does it even have any meaning anymore?
it seems like "staff" or "principal" roles are the real "seniors"
it seems like "staff" or "principal" roles are the real "seniors"
The problem is that companies with less-experienced upper management think that they can save money by handing out awesome new titles instead of more money. In the short term, they’re right, it’s an old trick that will always work… on certain people. But the people that works on are the kind of people you probably don’t want to retain. Often this happens at companies that have a small software team, but are not primarily software or even technology companies.
I’ve interviewed “Principal Software Engineers” whose understanding of software engineering and computer science were minimal, and it’s because of this phenomenon. Just last week I talked to one who couldn’t explain what what makes an interface RESTful. They had no idea how Git works beyond commit and push. They wrote a unit test that did the exact same stateless thing twice, and asserted that the results were identical. They wanted $250K/yr.
I’ve interviewed “Principal Software Engineers” whose understanding of software engineering and computer science were minimal, and it’s because of this phenomenon. Just last week I talked to one who couldn’t explain what what makes an interface RESTful. They had no idea how Git works beyond commit and push. They wrote a unit test that did the exact same stateless thing twice, and asserted that the results were identical. They wanted $250K/yr.
It's because we started giving people senior titles at 6 months or a year of experience. I'm not saying there's a clock running until you can call yourself senior, but if you're doing it with less than 6-8 years of experience it should absolutely make people's eyebrows go up. How many projects can you really work on ideation, design, development, deployment, short-term maintenance and long-term maintenance in 2 years?
Just because the JS framework you're working with is 3 years old doesn't make you a senior because you have 2.5 years of experience with it. There's a lot more to the job than that.
Just because the JS framework you're working with is 3 years old doesn't make you a senior because you have 2.5 years of experience with it. There's a lot more to the job than that.
Maybe that comes from job ads? Most companies want people with a few years of experience so that they've been "validated" by someone else, so they use the term "senior" to say "not junior".
Because, as the other poster put it, we're now "gatekeeping" if we don't put a big title badge on anyone with a few months of work behind them and willingness to talk big.
senior is 4-5 years of XP... staff and principal are real leadership roles. senior is short for more seniority than junior.
If a working career is 35-40 years, and most people will be ICs or low-level management for their entire career (meaning, most people won't ever be a Director or VP of anything), it seems unlikely that you can reasonably be considered "senior" after having completed about 10% of your career unless it's a transient thing.
Maybe the real problems are: the lack of advancement opportunities and lack of a real meaningful and achievable tech ladder at most companies.
You have maybe a 40 year career. If you get the "senior" title 2 years into it, odds are you'll have the same title for the next 38 years. That's kind of demoralizing if you're a "ladder climber" personality.
I remember quite clearly sitting in an office back in 2006 or so as a young punk but with enough years behind me to have already reached the salary plateau. Looked around me and saw a guy in his late 50s doing the exact same thing I was doing, with the exact same title, and probably making pretty close to what I was making. It filled me with existential dread! The realization that this industry hardly has any avenues for growth as an IC once you become "senior" and hit that salary plateau. If you don't want to be a people-manager, you're likely going to wander from company to company as a perpetual "Senior Software Engineer" until you are elderly and retire.
There are a handful of companies that have those "staff engineer" and "principal engineer" and "fellow" titles that come with actual salary growth, but they constrain those roles so severely, that most people won't get into the club. Just like most managers will not get into the Director or VP club. And these titles are not meaningful across the industry: If you do make "principal engineer" at your medium-sized startup, nobody else cares: when you get hired at Google, you'll be back to "Senior Software Engineer" and on the treadmill again.
It's kind of a reality that us worker-drones need to just accept and deal with. Companies don't seem to be motivated to provide actual, achievable growth paths that are transferrable from company to company.
You have maybe a 40 year career. If you get the "senior" title 2 years into it, odds are you'll have the same title for the next 38 years. That's kind of demoralizing if you're a "ladder climber" personality.
I remember quite clearly sitting in an office back in 2006 or so as a young punk but with enough years behind me to have already reached the salary plateau. Looked around me and saw a guy in his late 50s doing the exact same thing I was doing, with the exact same title, and probably making pretty close to what I was making. It filled me with existential dread! The realization that this industry hardly has any avenues for growth as an IC once you become "senior" and hit that salary plateau. If you don't want to be a people-manager, you're likely going to wander from company to company as a perpetual "Senior Software Engineer" until you are elderly and retire.
There are a handful of companies that have those "staff engineer" and "principal engineer" and "fellow" titles that come with actual salary growth, but they constrain those roles so severely, that most people won't get into the club. Just like most managers will not get into the Director or VP club. And these titles are not meaningful across the industry: If you do make "principal engineer" at your medium-sized startup, nobody else cares: when you get hired at Google, you'll be back to "Senior Software Engineer" and on the treadmill again.
It's kind of a reality that us worker-drones need to just accept and deal with. Companies don't seem to be motivated to provide actual, achievable growth paths that are transferrable from company to company.
Honestly I think places constrain those upper echelon titles so much because there really isn't that much work to be done at that level, and the vast majority of people just aren't that good at it.
> Companies don't seem to be motivated to provide actual, achievable growth paths that are transferrable from company to company.
The cynic in me says why would they if they're getting what they need without it? But taking a step back, most companies don't have any work worthy of someone who actually deserves a Principal or Fellow title. Even Staff doesn't mean much when you work at a logistics company with 10 developers - you're just a glorified manager at that point.
> Companies don't seem to be motivated to provide actual, achievable growth paths that are transferrable from company to company.
The cynic in me says why would they if they're getting what they need without it? But taking a step back, most companies don't have any work worthy of someone who actually deserves a Principal or Fellow title. Even Staff doesn't mean much when you work at a logistics company with 10 developers - you're just a glorified manager at that point.
Inflation
Seniority shouldn’t be time served. I’d have no problems with someone being a senior whatever if they walk the walk.
I’m in data engineering myself these days but if I jumped into some other area, even one I didn’t know from previously, I’d set out to walk the walk there too. It’s not like “We know you’re staff now, but that is backend, so we’ll make you an associate front end dev” or whatever?
I’m in data engineering myself these days but if I jumped into some other area, even one I didn’t know from previously, I’d set out to walk the walk there too. It’s not like “We know you’re staff now, but that is backend, so we’ll make you an associate front end dev” or whatever?
I'm considered a senior engineer by the company I work for and my peers, however it makes me cringe to write or say it. I think it comes across as pretentious.
Sounds like a mix of impostor syndrome and recognizing the absurdity of hierarchical labels and ranks.
Labels are a leaky abstraction, genuinely useful for those who don’t (want to) care and know. But useless, maybe harmful, when it comes to difficult problems, conflict and subtle interactions. In these cases we need to recognize that the map is not the territory.
Labels are a leaky abstraction, genuinely useful for those who don’t (want to) care and know. But useless, maybe harmful, when it comes to difficult problems, conflict and subtle interactions. In these cases we need to recognize that the map is not the territory.
I love titles. They're made up bullshit but people assign value to them.
If I meet someone with 8 years of experience that is not confident to tell me they're a senior engineer, I won't hire them.
If I meet someone with 2 years that tells me they're senior. I'll listen to what they say carefully and judge if they can do the job.
Titles are useful labels that compress a lot of info. It's not about how accurate they are, is about trying to differentiate quickly.
If I meet someone with 8 years of experience that is not confident to tell me they're a senior engineer, I won't hire them.
If I meet someone with 2 years that tells me they're senior. I'll listen to what they say carefully and judge if they can do the job.
Titles are useful labels that compress a lot of info. It's not about how accurate they are, is about trying to differentiate quickly.
I’ve been in tech lead roles for many years now and I agree with almost everything in this post. 80% of Insights often come early after transition because you can more clearly see the contrast. The other 20% usually comes much later with deep reflection and when you’ve been distanced from the work.
I think the word "becoming" covers that.
This sounds familiar. Aside from the part where he tells the PM that something is going to be delayed because of a tech decision.
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 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.
*Mods, please update title to its actual title:
"What I Learnt Becoming a Tech Lead (as a millionaire)"
"What I Learnt Becoming a Tech Lead (as a millionaire)"
Delegate. Delegate. Delegate.
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.
In my experience, that's more likely to happen if the team lead _doesn't_ take an active role in defending the team's ability to do "interesting" work. I think the "do it all yourself" fallacy was covered in the article (which I found to be very well-written on the whole).
you forgot as a millionaire part.
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.
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.
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.
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.
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.
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.
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.