What I Learnt Becoming a Tech Lead
tomgamon.com
tomgamon.com
- 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
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.
I find a lot of teams have this sort of set up. It gets abused.
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.
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.
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.
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
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.
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,...
PIP = Performance Improvement Plan
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
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.
Oh wow. This was the EXACT thing to happen 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.
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.
Given high turnover, that is probably most people though.
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.
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.
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.
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.
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.
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...
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.
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.
Give them credit for even doing as much as they did, to be honest.
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.
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.
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.
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.
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.
"Why I'm so good at coding" https://youtu.be/xqgH9j3x2OE
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.
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.
... is called product owner.
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.
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.
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.
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 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.
"What I Learnt Becoming a Tech Lead (as a millionaire)"
it seems like "staff" or "principal" roles are the real "seniors"
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.
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.
> 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.
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.
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?
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.
Titles are the exact time we should do some gatekeeping. Being called a “senior engineer” with only 2-3 years is frankly a joke.
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 :|
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.
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.