4 ms·

> There are broadly 3 experience levels: > Senior: creates the plan. > Mid-level: follows the plan. > Junior: needs to be taught to follow the plan. This pers

by mlthoughts2018 6y ago

> There are broadly 3 experience levels: > Senior: creates the plan. > Mid-level: follows the plan. > Junior: needs to be taught to follow the plan. This person is a horrible leader and failure if they think this way. This tells you all you need to know about the rest of the article. And indeed: > “The ideal team would be one that has all disciplines covered at a senior level with multidisciplinary people working in just one team, and with enough overlap to avoid a bus factor of one. Additional people will bring additional capacity.” It’s just the tired old foolish mirage of fungible full-stack teams where there’s no such thing as specialization of labor. This article is basically a farce of bureaucratic management mediocrity.

jacquesm 6y ago
It's a programmer that approaches people management with the same level of empathy that he would normally apply to lines of code or database records.
Noumenon72 6y ago
Is your complaint that instead of looking to see "who are my mid-levels who can create a plan", he just assumes by their level that they cannot create a plan? Without detailed knowledge, I think most places hire senior/mid/junior based on exactly the criteria he describes. Every team is fungible in the long run. If you have someone who is specialized labor, either they handoff to someone who is non-specialized now, or they do it later when they leave the company. Edit: I think your response to dmak covers this, thanks.
dmak 6y ago
Could you share more about your opinion on why this makes a horrible leader?
- mlthoughts2018 6y ago
  Some of the best product strategy in my org has consistently come bottom up from junior and mid level engineers. Some of the most out of touch product strategy has come from principal / staff engineers and senior product managers. All engineers, whether junior or senior, need lots of autonomy to propose and try plans. No engineers needs to be “taught to follow the plan” - that is career death. Meanwhile, the risk of political motives and malicious intent or self-preservation is much higher among senior staff, especially as they become ex-technical. Finally, many products need teams of specialists in various areas, and their team structures don’t resemble fungible full-stack wishful thinking. A good leader tries much harder to give them what they need instead of imposing the fiction they are fungible. So, overall the leader of this post is - overly reductionist - failing to protect autonomy - failing to protect specialization - failing to deal with reality - mentally representing “senior” vs “junior” as “creates orders” vs “follows orders” which puts political authority as a central cultural value. These are all classic, well-known leadership mistakes. I guarantee the company in this example is full of under-appreciated engineers treated like cogs. Even the overall premise of the layoffs is suspect. Nowhere does the article even ask the question of why the critical project failed in the first place. Why was staffing preemptively overallocated? If you fire these people, will you have to hire and retrain new people later when things change again? How costly would that be relative to retaining them now? Why aren’t there senior leaders being fired? The failure of a project with such wide spread ramifications surely isn’t down to a bunch of little guys. Here’s what happened: Using the same overly reductionist, chain of command failed ideas described in this post, other leaders pursued a bad strategy and allocated resources poorly. Now, to avoid being punished and paying the consequences of their failed strategy, i.e. actually firing executives and senior leaders who caused this problem, they need to scapegoat it as an IT downsizing and they need some inexperienced twerp (this CTO) to spas out pretending like some critical calculus was applied to make the heartbreaking least-bad fewest cuts they could. It’s disingenuous to the core. Absolutely this is shitty, low-accountability leadership.
- valuearb 6y ago
  It says Junior devs are useless. If they are useless, why were they hired?

jacquesm 6y ago

It's a programmer that approaches people management with the same level of empathy that he would normally apply to lines of code or database records.

Noumenon72 6y ago

Is your complaint that instead of looking to see "who are my mid-levels who can create a plan", he just assumes by their level that they cannot create a plan? Without detailed knowledge, I think most places hire senior/mid/junior based on exactly the criteria he describes. Every team is fungible in the long run. If you have someone who is specialized labor, either they handoff to someone who is non-specialized now, or they do it later when they leave the company. Edit: I think your response to dmak covers this, thanks.

dmak 6y ago

Could you share more about your opinion on why this makes a horrible leader?

mlthoughts2018 6y ago
Some of the best product strategy in my org has consistently come bottom up from junior and mid level engineers. Some of the most out of touch product strategy has come from principal / staff engineers and senior product managers. All engineers, whether junior or senior, need lots of autonomy to propose and try plans. No engineers needs to be “taught to follow the plan” - that is career death. Meanwhile, the risk of political motives and malicious intent or self-preservation is much higher among senior staff, especially as they become ex-technical. Finally, many products need teams of specialists in various areas, and their team structures don’t resemble fungible full-stack wishful thinking. A good leader tries much harder to give them what they need instead of imposing the fiction they are fungible. So, overall the leader of this post is - overly reductionist - failing to protect autonomy - failing to protect specialization - failing to deal with reality - mentally representing “senior” vs “junior” as “creates orders” vs “follows orders” which puts political authority as a central cultural value. These are all classic, well-known leadership mistakes. I guarantee the company in this example is full of under-appreciated engineers treated like cogs. Even the overall premise of the layoffs is suspect. Nowhere does the article even ask the question of why the critical project failed in the first place. Why was staffing preemptively overallocated? If you fire these people, will you have to hire and retrain new people later when things change again? How costly would that be relative to retaining them now? Why aren’t there senior leaders being fired? The failure of a project with such wide spread ramifications surely isn’t down to a bunch of little guys. Here’s what happened: Using the same overly reductionist, chain of command failed ideas described in this post, other leaders pursued a bad strategy and allocated resources poorly. Now, to avoid being punished and paying the consequences of their failed strategy, i.e. actually firing executives and senior leaders who caused this problem, they need to scapegoat it as an IT downsizing and they need some inexperienced twerp (this CTO) to spas out pretending like some critical calculus was applied to make the heartbreaking least-bad fewest cuts they could. It’s disingenuous to the core. Absolutely this is shitty, low-accountability leadership.
valuearb 6y ago
It says Junior devs are useless. If they are useless, why were they hired?