[quickthrower2]

You are correct but so often we are measured on individual productivity. And you get what you measure. So team members will want to work distraction-free to max their KPIs.

Your insights good, it needs to be needed by managers and staff that the team is working as a team.

[Kadin]

I recently re-read the classic "Peopleware" (written 1974) and I think it's a bit unfortunate, given all the innovation elsewhere in the field, that there hasn't been much innovation or even experimentation about the nature of employment or how teams are constructed and actually execute work.

Sure, there's a new "method" every few years but these seem like tinkering around the edges.

I admit this is not a fully-formed idea but I've wondered about a concept where an entire team would be compensated as a team, but then the team would be responsible for hiring/firing. (Which seems only fair -- if you're going to be compensated as a team you should have control over it.) A group "audition" interview technique is discussed in Peopleware that I have sadly never seen implemented, but something like that could form a part.

But as long as people are compensated on an individual basis there will always be an incentive to treat communication and particularly assistance or training of other team members as a second-tier function, to be done only reluctantly if at all. But viewed from the throughput or potential of a team, someone who increases the performance of multiple other developers has a much greater shot, in my experience, of being the mythical "10X developer" than even a very strong individual contributor. And the reverse is certainly well-known to be true: someone who hurts the performance of people around them, even if they produce good code at a reasonable rate, may actually be worse than useless to the team as a whole. Producing an incentive structure that takes those issues into account that's based on measuring individual performance is extremely difficult, and I've begun to think impossible, given that the industry has been trying to do it for decades with little apparent progress.

[lovich]

The team based compensation is interesting but I don't think any company other than some startups would go for it. The main reason would be falling afoul of discrimination laws. The teams would be highly incentivized to exclude people that they thought would be less productive, say a pregnant woman who the team thought would be out for a long period, but the government will be holding the company accountable and not the team itself.

It's the same result of you get what you measure

[mmirate]

Isn't this problem theoretically also suffered by e.g. ~5-person contract/consulting shops?

[lovich]

It is and in my experience small consulting shops are a lot more open to folding if something goes bad and reopening as a different entity or with a slightly different group of people. Any larger firm or group that's in it for the Long haul doesn't have that option.

The more I think about it the more it seems like small consulting shops basically are team based comoensation, but it still ends up with 1-2 people deciding who gets paid what more often than not

[erikb]

I haven't experienced that at all. Okay, yes. When you ask your boss what he measures you about, he'll give you performance data. Tasks closed, commits sent, LOCs produced, etc. But what he really measures are top features you produced. And that happens rarely. I think for a really talented guy it's 0.5-1 top success per year. And these don't need to be measured, they are team memory.

Ask your team who is most talented in their eyes. They'll agree on a small number of names. And if you ask them why they believe it, it's something like "because he wrote our test automation" or "he's the guy you ask about that really nasty part of ancient code". Everything else is only for self-fulfillment of the developers.

E.g. https://www.youtube.com/watch?v=oyVksFviJVE

[quickthrower2]

YMMV as they say

[sidlls]

I make sure that the people manager of the junior engineers I mentor know that my view of the productivity they are evaluated on is that it's related to the quality of their engineering, not output quantity, or even output per se. A significant part of engineering is bringing clarity to a problem, usually by engaging in a proper process of requirements analysis and design. Time spent slapping code into an editor ought to be less than the time spent doing other engineering tasks. Frequently it ought to be much less.

[erikb]

And that's what people think (me too, no exception here) two years after they come out of university.

[sidlls]

What do you mean by "that?"