The title is oddly discordant with the content - all these admirable things the lead / director (let’s just say manager) is supposed to do for their team, but if they can’t do all of it you should fire them? Shouldn’t you mentor them, help them identify and improve on their weak spots? Isn’t that your role as their manager?
And besides, you might not have the luxury of much choice. You might get half of this list, hope you can improve a few other things, and accept that people aren’t perfect. Making the best of what you’ve got is also a managerial skill.
“An Engineering Lead stays calm under pressure and handles the most uncomfortable situations first”
This is one of my favorites as it’s good advice in general for people wanting to take on paths of high responsibility. Many people will say do a little, then a little more, and gradually work up to bigger challenges. That’s good in training but can be bad in production. I noticed the big problems tend to build up to be harder to take care of later or (esp if people problems) linger over the team constantly distracting them. Hitting the hard stuff, esp with people, immediately prevents that plus gives the mental boost that the rest can be a cakewalk.
One can still solve a minor problem or two first as a warm up to get going during the day. It’s probably the people who wake up to cold showers or with a Get Shit Don rush that don’t need to do that. They’re different than me.
This is one of my favorites as it’s good advice in general for people wanting to take on paths of high responsibility.
This is important.
It’s easy to add a cache to speed something up 10%. It’s hard to design a benchmark that proves that implementing correctly an appropriate data structure will yield a 25% speed-up and eliminate the need for the external dependency that is the cache.
It’s also amusing to me how sometimes executives and others higher up the totem pole will be drawn to the easiest problem to solve when you present something. They’ll focus on small details that are like a day of work instead of the “where are we going with this” big picture. Oftentimes, those folks haven’t developed the maturity or process necessary to trust the implementors and are instead focusing on something they know in order to demonstrate their prowess to their peers and reports. This is why I say that presentations to power must be polished and explicitly call out any areas that are handwavy in order to focus the audience on the end goals.
The title is oddly discordant with the content - all these admirable things the lead / director (let’s just say manager) is supposed to do for their team, but if they can’t do all of it you should fire them? Shouldn’t you mentor them, help them identify and improve on their weak spots? Isn’t that your role as their manager?
And besides, you might not have the luxury of much choice. You might get half of this list, hope you can improve a few other things, and accept that people aren’t perfect. Making the best of what you’ve got is also a managerial skill.
“An Engineering Lead stays calm under pressure and handles the most uncomfortable situations first”
This is one of my favorites as it’s good advice in general for people wanting to take on paths of high responsibility. Many people will say do a little, then a little more, and gradually work up to bigger challenges. That’s good in training but can be bad in production. I noticed the big problems tend to build up to be harder to take care of later or (esp if people problems) linger over the team constantly distracting them. Hitting the hard stuff, esp with people, immediately prevents that plus gives the mental boost that the rest can be a cakewalk.
One can still solve a minor problem or two first as a warm up to get going during the day. It’s probably the people who wake up to cold showers or with a Get Shit Don rush that don’t need to do that. They’re different than me.
This is important.
It’s easy to add a cache to speed something up 10%. It’s hard to design a benchmark that proves that implementing correctly an appropriate data structure will yield a 25% speed-up and eliminate the need for the external dependency that is the cache.
It’s also amusing to me how sometimes executives and others higher up the totem pole will be drawn to the easiest problem to solve when you present something. They’ll focus on small details that are like a day of work instead of the “where are we going with this” big picture. Oftentimes, those folks haven’t developed the maturity or process necessary to trust the implementors and are instead focusing on something they know in order to demonstrate their prowess to their peers and reports. This is why I say that presentations to power must be polished and explicitly call out any areas that are handwavy in order to focus the audience on the end goals.