Comment by steveBK123
5 days ago
It's a good point but I'll add the problem is also the system/incentives of whatever org you are in.
Some shops its easy enough to manage someone out and bring in a new team member who will contribute more. This is a health environment and generally free of the boom-bust hire/fire cycle.
Other shops have very top down hire/fire cycles where if you fire someone now you have no ability to replace them, and worse yet.. when you HAVE to fire someone, you want the low performer around to hit your metrics..
So a lot of shops carry around a lot of dead weight for different reasons, as long as the person is not a net negative contributor.
Aside from that, yeah, how to deal with poor performers is as much an art as a science. I often find, aside from exceptional cases, most of them actually have some part of the job they prefer & are good at, so modifying the task allocation can go a long way.
> I often find, aside from exceptional cases, most of them actually have some part of the job they prefer & are good at, so modifying the task allocation can go a long way.
While this works in the short/naive scenario, I feel like in most cases these low performers prefer the "gravy" work if you will. The type of work that almost everyone prefers and is good at. So you risk setting a bad precedent for perverse incentives by rewarding poor performance with easier work.
Really depends actually!
In a sufficient sized team you may have boring/rote tasks that your high performers hate & neglect, but sometimes a comparatively lower performer will take on.
In many cases it's the (sometimes perceived but not in practice) higher performers that want the harder exciting high profile tasks, but maybe don't want to do the less fun parts of those tasks. Basic data munging, documentation, testing, monitoring, configuration management, etc... no fun!
A lot of perceived high performing devs I've worked with want to be like surgeons who walk into the OR, put their hands into the gloves, pick up the tools prepared for them on a tray, do the surgery, and leave.
Problem is I don't think we can really pick and choose tidbits like that. You want the person who wrote the code to be the same person that documents it.
Some parts of the job just suck and there's no easy out. I just tell myself this is why they're paying me.