|
|
|
|
|
by ineptech
1688 days ago
|
|
I don't know if that was intended to be snarky, but yes, that's exactly what you should do, and people do in fact do that, and it often does work (although probably not as quickly as you'd like). How else am I supposed to know Bob and Joe are doing bad work? Should I count their LOC/day? Pore over their code and rely on my own (10 years out of date) opinion of it? In my humble opinion, there is one (1) good way to measure developer productivity, and that is to ask their teammates, and if you won't tell me your teammate is awful, you can't really complain that I don't act on it. Of course it's possible that you tell me and I don't do anything, but at least then it's my fault and not yours. |
|
It describes very well the phenomenon but gives advice that I can only see ever working at BigCo. Where your team is huge and if you screw up there's another one down the hall.
The truth is most places that exhibit this level of helplessness often include a small team of 5 or 6, each with plenty of tenure. With no other lateral teams to move to.
Now you want the new guy to walk up to the boss and tell him that his drinking buddies for the past decade are the reason things are falling apart and he's an ineffective manager for not noticing it. You can play with the wording but that's the message.
In the real world we have political factors like seniority, favoritism, nepotism, tenure, and nevermind external factors.
In the real world the boss doesn't actually care if the team is working well or not. He only cares that the perception of the team is positive. If the new guy threatens the perception, he's gotta go. Nobody cares if it gets fixed. If nobody knows it's broken there's no need to fix it.
Let's have less articles like this one where we basically fire ourselves ostensibly for virtue signaling and more articles about how to socially engineer your way to the fucking top. Because let's face it, that's what it actually takes.