Mentoring and leading by example are great things to do, but they do nothing to solve the actual scenarios that Will gave as examples in the OP. There are some situations that you can’t resolve by being a good colleague, and the manager needs to step in.

Managing peers is not their job - the author tried to spin the lack of action by manager as poor management, but what if the manager has more context and good reasons for maintaining the status quo? IMO, this is management equivalent of tech debt, and hr is demanding that it gets addressed immediately without caring about other consequences outside their own narrow window into the org.

This is not how I read it. You have to do your best as a manager to train your employees and live up to what Andy Grove said in High Output Management. You must set a high standard and it is your job to get your reports to that standard the best you possibly can.

But when your reports cannot or will not get to that standard despite a huge investment in training and clear direction, you have to move on.

Emphasis mine.

When you fire someone. You tax HR and yourself with the process both of letting someone go and finding their replacement. You have to pay their salary 3-6 months going forward as well as all the paid vacation they may have saved up. Most importantly you tax your team with the added resource drain of covering the tasks as well as integrating the replacement. You also risk damaging morale, and worse, you risk increasing employee anxiety as even the best employee can have inferiority issues.

That being said, the basic mantra in management should always be that you can get rid of anyone, it’s just a matter of cost. So if you need to fire someone, then you need to fire someone.

Personally I prefer building people to the point where they will leave you themselves, but, that’s a style or management that isn’t present in a lot of companies because it takes a corporate culture that is very hard to maintain in large organisations and require quite a lot of management talent in small organisations. It’s also something that is incredibly hard to do as a single manager if the culture is against you.

Well, that’s time (or deferred pay) they’ve contractually and morally earned, so that part’s entirely fair.

In the U.S - where you generally don't have to pay as long a severance pay if at all.

on edit: as in most things 'in the U.S' this varies on state by state basis.

Does Denmark not have constructive dismissal laws? Making changes that force someone out is an easily winnable unfair dismissal at an employment tribunal, at least for the UK. And that costs more than just firing them for bad performance.

You clearly haven't met Austrian management. It's nearly at will employment (in theory it's not, but in some domains many companies know and do skirt around the law to get rid of employees quickly without getting sued).

Once the management decides they don't like you anymore, you're given your standard one to three months notice, then you're gone. I asked a lawyer, and they said the employer can fire your without any reason as long as they give you your contractual notice period.

My favorite example is them using Jira velocity charts to fire the one with the slowest curve. You get a warning (p.i.p.) telling you your velocity needs to catch up, then after two sprints you get your notice handed to you.

OTOH, there are other EU countries where firing people is really difficult. Here it's just a rubber stamp thanks to decades of pro-business politicians elected in power who eroded workers' rghts.

In many English-speaking countries is not difficult to convince an employee to quit.

If someone really should be fired but isn't, that also damages morale.

This is the crux of the issue: The definition of "causing problems for other people" isn't as well defined as it may seem.

Someone who is constantly driving the team further apart than together, struggling to work with other members of the team, and being openly dismissive of others would fit the definition of "causing problems for other people".

From another perspective, it would also fit the definition of the "hard to work with" person in this article. That's the point: Even when someone is falling behind, as an employee you must find a way to at least try to work with them and lead by example.

One pattern that I saw quite a bit was one team member being a bit more technical (rather than business focused), so they tended to cop a lot of the internal questions that caused them to context switch a lot. It increases their frustration levels and drops their performance. One effective way to solve that is to acknowledge what is happening, and put in some boundaries so the other team members know that (for example) Tuesdays-Thursdays you need to really be stuck before you bug XXX about your problem. It makes XXX feel better about the situation because not only has it been acknowledged they are a key team member, it also makes sure they get some quiet time to really get stuff done at their own pace without having to switch jobs all the time.

The other team members, knowing there are a few boundaries now, tend to become more self sufficient so you end up with a better performing team overall, and one that isn't so dependent on a single person.

Obviously there are other patterns that end up creating "hard to work with" people, but the example came up so often I think it's worth writing about.

If you're too busy thinking what an amazing worker you are and everyone else is dragging you down, there's a good chance you feel vindicated in behaving in a way that makes your coworkers' jobs harder. Why should you help them out? They're not even trying to do things right and they're making you look bad.

Let's imagine there is a problem that requires to need to implement 100 classes to deal with 100 different types.

A 18th century person would say: I have 100 classes, 5 workers, I am going to give 20 classes for each worker to implement.

A person that actually knows what's going on would simply write template <typename T> class FuckYou, done.

In the wrong hands, software is misery.

  function FuckYou(T) {
    return class {
      // something with T
    };
  }

My read on the article was more on a mis-alignment of values and what is considered success. High bar / low "performance"(which is a subjective thing and can vary based on external factors) are those who want to learn because they know they aren't at that bar now but they want to be.

"Low bar" / high or low performance means that you have different goals and different measures of "success". If you don't resolve those first then that leads to the friction and the pattern the author outlines.

This can be in a bunch of different areas(security, performance, maintainability) and sometimes if you have two people who hold velocity and architecture separately as their highest bar it can appear that they don't value each other's bar since they are in direct conflict. It's been my experience that if you can ground it in why people hold certain bars and that the goals are actually aligned then the sum of the team that hold a high bar in different areas is greater than the parts.

In his shoes, I’d be thrilled if the response was “you’re right, we’re going to coach this other person to improve, because they’re valuable in a lot of ways, but need improvement there so we can succeed.”

In the other situations an employee is performing poorly, not recognizing it, and neither is the organization.

Here we have an excellent example of the straw man, nice to see still practiced these days.