3 ms·

Answer from a different side of the fence: As an executive who elected senior engineers into engineering managers three time in different companies, there are

Answer from a different side of the fence: As an executive who elected senior engineers into engineering managers three time in different companies, there are three challenging areas for even the most fit for the job engineers: - understanding that soft skills and understanding company politics now matter not as much, but more than detailed technical skills. focusing on eliminating weaknesses in this area is that pareto-ean 20% of effort that makes the rest 10x easier. - it's now about eliminating weaknesses, not growing strengths: what you tolerate slows down and makes everything toxic, while what you preach is a second-order problem for a while. it evens out, and later on you can focus on growing strengths, but only after a while. - you own consistency of engineering culture, not your piece of code and responsibility, now. which makes figuring out internal feeling of "I'm doing it right" twice as hard.

nython 9y ago
Could you give an example for the 'eliminating weaknesses is more important than growing strengths' part? I think I've encountered this before - where letting an incompetent developer go would have accelerated a project much more than hiring a very competent one.
- ninegunpi 9y ago
  It's true, but real leader is responsible for his people and the team as much as for success. Team has to see that leader puts significant effort into making weaker people become stronger before actually letting them go. This way, healthy mutual respect arises instead of hostility and fear, because letting underperformers go always leads to fear, unhealthy competition, intra-team political games which are just a waste of human time and nerves.
wruza 9y ago
I’ve read first two -points about four times, but still have no idea what these are about (usual thing when talking to completely “other side of fence” minded people). Can I ask for some examples in context?
- clevergadget 9y ago
  yeah I think it is a suggestion to immediately fire the weakest co-worker when you get promoted? great morale advice for the rest of the culture <3
- ninegunpi 9y ago
  Sorry, English is not my primary language, so the grammar constructions might get odd from time to time, this might have been the cause. Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex-engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to-date-ness in latest technology. Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success. Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.

nython 9y ago

Could you give an example for the 'eliminating weaknesses is more important than growing strengths' part? I think I've encountered this before - where letting an incompetent developer go would have accelerated a project much more than hiring a very competent one.

ninegunpi 9y ago
It's true, but real leader is responsible for his people and the team as much as for success. Team has to see that leader puts significant effort into making weaker people become stronger before actually letting them go. This way, healthy mutual respect arises instead of hostility and fear, because letting underperformers go always leads to fear, unhealthy competition, intra-team political games which are just a waste of human time and nerves.

wruza 9y ago

I’ve read first two -points about four times, but still have no idea what these are about (usual thing when talking to completely “other side of fence” minded people). Can I ask for some examples in context?

clevergadget 9y ago
yeah I think it is a suggestion to immediately fire the weakest co-worker when you get promoted? great morale advice for the rest of the culture <3
ninegunpi 9y ago
Sorry, English is not my primary language, so the grammar constructions might get odd from time to time, this might have been the cause. Point 1. Good engineer should know how to code, and how to cooperate with fellow engineers well. This means healthy balance of "hard" (engineering) and "soft" (communication) skills. When engineer becomes tech lead or engineering manager, being able to communicate, understand other people's behavior, lead them, communicate situation up and down the chain,- soft skills start to matter way more. If there are serious skill gaps in soft skills (and all ex-engineers have ones when they start to grow in this area), addressing them is more important for engineering manager's career than addressing lack of up-to-date-ness in latest technology. Point 1, Example: when I first got to manage a small team, me not understanding power distribution between younger and more experienced engineers (I came from latter category) led to mass extinction of juniors: the way important decisions were made (with more contribution from senior engineers) was good for the company, but the way it was presented (We The Elders Made Crucial Decision) pissed youngsters off, made them feel incapable of making valuable contributions and they quickly left. After understanding the reason (which took hours of mentoring from CTO, a very experienced manager), I had to really work hard on creating the atmosphere where, even when the decisions were made by seniors, the ownership and responsibility for actual implementation of these decisions was distributed among the teams and everybody could contribute to mutual success. Point 2, with examples already: It kinda continues point 1, but bridges from personal scale to team scale. Process is as good as it's bottleneck. Team is as fast/writes as quality code, as it's weakest members. If you tolerate them, they constrain the process. Your goal is to spot weaker people / weaker engineering decisions and put reasonable amount of effort to either make them better or make them live. As an engineering manager (e.g. manager that comes from engineering, not from fancy MBA factory), you actually can tell the slacker from person who wasn't properly integrated into the process. As an engineering manager, you can tell that the decision to make blocking tests stop CI on the first failure is a poor decision and having a proper failure log of all tests is crucial for speed of bug fixes, not fixing them faster or with better method. Basically you are responsible for the failure (even if you're formally not), because you're the focal point of knowledge and power that can prevent them, put slower people to speed, put processes to full power.