I'm going to flip the question, because we get a little more insight with it upside down.
How do you know a developer is doing a bad job? Is it because they don't code a lot? They sleep late? Maybe wear the wrong clothes?
I'm agreed with the author that with an organization of any non-trivial size, all we have is subjective data, since effort and value are so completely decoupled in tech.
Unless you know you're going to be funded for life, every tech group has a difficult question it must face sooner or later: how do you deal with incrementally decreased funding, where somebody has to be released?
The best I've got is that the team has to vote somebody off the island. I don't like it, but it's a decision that must be made, and managers aren't the ones to make it. I would add to that: the team includes the developers, the managers, and the customer/users that interact with and receive value from the team.
It's an open question whether or not you decide to do this on a regular basis or just save up and whack somebody with a vote all at once. I don't like forced ranking, but I would prefer a rolling average of votes over a long period of time as opposed to an all-at-once vote. For some reason it seems more humane to me.
What is the alternative? Drawing straws? A game of chance?
Should the team be responsible for downsizing itself? If not, how does that happen?
Perhaps the team force-ranks itself once a month or so using a 360-like method -- but the results are never read and kept secret until/if they are ever needed?
Drawing straws would be better for morale I think. So yes, if those were the two choices I'd prefer drawing straws.
I think management should make the decision though - even if they have to pick someone at random. The heart of management's job is to make this kind of large-scale decision and carry for responsibility for it.
You are working in a team of, say, six. You are working alongside some business folks and helping them make money and support their family. Your boss, let's say, is a nice guy but an old mainframe IT guy who doesn't really grok what kind of things the team is doing.
There is not enough money for all six to work next year, but the company thinks they can pay for four.
You'd rather have a manager make the call, a guy who doesn't know really what the team does or the individual contributions of each member -- than the team? The team, who if push came to shove could probably agree on the four most qualified people to help everybody else in the coming year keep their jobs.
I don't follow this. I think the team is the most qualified, and I think if you care about the value you are creating then the team is also on the hook to make the tough decision. Now how it's made and such? I have no idea. I just know if you care about the work you're doing, the people closest to the work are going to be the most qualified to make businesses/management decisions like that. But maybe I missed it?
> I think if you care about the value you are creating then the team is also on the hook to make the tough decision.
I think if management isn't able to do it then what are they even for? (This is not just a rhetorical device - if I was working at one of those radically-less-management places like Valve then this might be one of the pieces I'd expect to have to pick up). But yes, I want the boss to make the call - he can ask me questions and I'll try to answer them, but I want it to be his decision and his responsibility. Not liking to make that kind of call is part of the reason I've chosen not to go into management (and paid the price financially), after all.
If you have no idea what the team does or who is contributing how much until you're starting to fire people then you aren't really managing anyone. Even if you are completely nontechnical figuring that out should be within your grasp.
I disagree, but my intent was not to argue. I've found it quite common even with developers working side-by-side for there to be a big gap between what they think is going on and what's actually going on. Thanks!
Of course, but if they continue operating that way for a long time it's failed communication. Part of what I'd expect from a decent manager is letting me know if everyone thinks I have an issue while I'm totally oblivious.
Communication failure is the #1 cause of technology project failures.
Communication failure is insidious because there are no warning signs or alarms that it happens. In fact, in most cases, even after the death of a project there is no serious examination of the communication failures that caused it.
I love management. I love being a manager. I love being the guy who is responsible when things go wrong but has nothing to do with things going well.
But technology development has changed that game. It's basically flipped the idea of manager upside down. It will be quite a while for the rest of us to adapt to the change.
The manager should use his subjective judgment, including but not exclusively asking other team members for their opinions about their reports, and everyone should be on the same page about how well or not they are are doing. Any scenario where someone could be blindsided to learn their performance isn't up to snuff is just really poor management. Anybody watching that happen with their head screwed on straight is going to head for the exits as soon as possible (not to mention the potential for personal grudges in any system that relies entirely on peer input to decide to fire somebody).
How do you know a developer is doing a bad job? Is it because they don't code a lot? They sleep late? Maybe wear the wrong clothes?
I'm agreed with the author that with an organization of any non-trivial size, all we have is subjective data, since effort and value are so completely decoupled in tech.
Unless you know you're going to be funded for life, every tech group has a difficult question it must face sooner or later: how do you deal with incrementally decreased funding, where somebody has to be released?
The best I've got is that the team has to vote somebody off the island. I don't like it, but it's a decision that must be made, and managers aren't the ones to make it. I would add to that: the team includes the developers, the managers, and the customer/users that interact with and receive value from the team.
It's an open question whether or not you decide to do this on a regular basis or just save up and whack somebody with a vote all at once. I don't like forced ranking, but I would prefer a rolling average of votes over a long period of time as opposed to an all-at-once vote. For some reason it seems more humane to me.