XYZ Lab Consulting

Strategy, Engineering, and the Color of Success

Menu
  • About William Li
Menu

Leadership Doesn’t Abandon Team

Posted on January 6, 2026January 6, 2026 by William Li

I read a post recently which was supposedly about where Leadership should spend time.  It embodied everything I think is wrong with corporate leadership today.

TLDR, the claim was that if I, as a leader, are constantly managing under-performers, I’m not investing in the people who are actually driving the business forward.  Leaders who find their time and energy stretched by spending too much time with “C” employees should really spend all their time with their “A” employees and show the “C” employees to the door, either literally or by just ignoring them.

Holy Aldous Huxley Batman!  Never mind the human stuff about how leaders should be empathic and supportive to their team; from a purely technical point of view, I consider following this approach an utter failure of leadership.  If you have many “C” team members, you should do some self-reflection.  Did you do your job in the first place when hiring?  Did you develop your team?

Did you coach your hiring managers about how to sniff out potential, or did you just assume that they’d all just figure out how to conduct hiring?  My very first hire was an utter disaster, and still haunts me a few decades later, as I was at the time green enough I had absolutely no idea how to hire – I advertised for the skills of the day and looked for just those, as opposed to looking for potential and fit in terms of underlying attitudes and background.  I’ve since gotten much better at hiring, but really only through constant comparison against that first, disastrous experience, and never ever through any sort of coaching from my various managers.

Do you have a progression process in place?  I don’t mean orientation for new hires – I mean working with the team leads under you to develop a path for each developer through your Agile backlog in such a way that each successive iteration worked on builds additional technical skills and domain knowledge.  You need architectural insight to do this, but the reward is it serves as a  teaching moment for both the developer and the team lead at the same time.

Unless you’re so personally over-leveraged as a leader in terms of direct reports that you should be checking into a Micro-Managers Anonymous self-help group, you should almost always be able to bring in at least one other person into the process of ramping up the more junior or currently less-capable team members.  The idea is that the next time some coaching of the juniors needs to happen, the seniors are enabled with the tools to do so because they’ve seen you do it yourself.

Only as a last resort do you look to sidelining the C members in favour of spending more time with just your A team.  If you go there first, I guarantee you’ll fail in the long run.

Category: Management Software Development

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Recent Posts

  • Leadership Doesn’t Abandon Team
  • New Year, New Goals, New Strategy
  • Color of Winter
  • (AI) Tools don’t make products.  Strategy makes products.
  • Managing multiple remote engineering teams for fun and profit

Recent Comments

No comments to show.

Archives

  • January 2026
  • December 2025
  • November 2025

Categories

  • AI
  • Color
  • Management
  • Software Development
©2026 XYZ Lab Consulting