Also, the larger the team, the bigger the incentive to be a free loader, because individual contributions become harder to assess.
Free loading includes plain slacking, doing things the fun way rather than the good-enough way, playing politics, keeping yourself busy with unnecessary management/coordination, etc.
Oh if only it was just free loading at large companies!
The reality is much more complicated. I worked with some great people at a huge company, a lot of them had families, one had a child with very severe asthma, and one time only a helicopter could get to the hospital fast enough.
Others had perfectly healthy children... in college, and a huge mortgage on the family home.
They all engaged in counter productive job preservation strategies. The easiest of which is simply to not aggressively share knowledge. At very large companies you really have to actively push your knowledge onto people or a shared knowledge repo.
The next level is to put a very small bit of effort into actively avoiding the sharing of knowledge. Give less than the best answers you can give when asked for information. You don't have to lie or hide, just don't be quite as eloquent as you could be.
At yet another level are things like writing custom wrappers around things that didn't need wrappers, or that already were wrappers themselves.
People were doing this because if they lost their jobs they would lose their homes, the children's heath insurance which can pay for things like helicopters, etc.
Then there's personality conflicts. At very large companies you work with a lot of people and this increases the probability you'll meet your worst match. That is the personality that just happens to clash with your personality. The most common I've seen is very confrontational vs. very passive. The very passive then often becomes as passive aggressive as the other is openly aggressive. And boy can smart people like hackers be incredibly good at passive aggression.
The point here is that either of those people would be good on their own. It's the combination that's toxic for them and anyone caught up with them.
And then there's anything other than stellar management. Organizing any large group of people so that communication is effective is not easy. If that large group is programmers and the information is highly complex... you don't have to be bad to mess it up, just not being a great manager is enough.
And there's even more, I could write a large book about this.
The easiest of which is simply to not aggressively share knowledge.
When you're stack ranked against your peers, I wonder if people ask themselves, "why should I help you, when all I'm doing is making it harder for myself to get a bonus next year"?. I don't indulge in such behaviour, but I've wondered if others have thought and acted upon it.
This probably depends on the local culture. When I was at Microsoft, in the groups I worked in, we were explicitly evaluated on criteria such as "makes others better". My reviews actually stated that actively mentoring and going out of my way to be genuinely helpful to others contributed to my score, and I ranked on top almost every year. When I think of other colleagues who I know ranked highly, the people who come to mind are the ones who had both the ability and willingness to help a lot of other people do their jobs better.
Yep, and what I've heard (and only heard, never worked there myself) is that Microsoft has some of the most programmer friendly corporate culture around.
A lot (if not most) big companies are not like that. The reason Joel's writing on company culture is so popular is because such simple things are still quite rare in the world.
If you were to design something to sabotage team effectiveness, I can't think of anything more effective than stack ranking that wouldn't be a criminal offense.
Being passive aggressive is something smart people have to learn -- we can't go up against the bully, but we can make him fall into a trap the next day.
And you shouldn't allow confrontational people on your team anyways -- they can't be in a group (but would properly be awesome on their own).
And you shouldn't allow confrontational people on your team anyways
A lot of great hackers are very confrontation, it comes from love of truth. Look at Linux and Linus Torvalds, Linus freely calls himself an asshole, because well, he is one. Many hackers are.
You can't just magically decide not to work with confrontational people when you're in the software business. Not unless you have infinite amounts of money to hire whomever you want.
You have to earn the right to be an asshole. Disrespectful confrontation out of some arrogant "love of truth" (arrogant because it implies one has some special relationship with truth) is just dickery that's going to poison a team.
This is one of the things I love about small companies. There is literally nowhere to hide. Either you're helping to get things done, or you're creating barriers. Of course small groups can be pathological too, but the visibility of BS is so much higher.
Agreed. Larger companies can try to simulate this effect to a large extent by creating smaller teams. So visibility within a team is good. This can be taken to an extreme and lead so silo-fication so these teams are run almost like smaller companies, have their own hiring policy, budget, etc.
But in the rest of the large company, there are hordes of pointy-haired bosses who are busy full-time trying to take up as much credit, budget and headcount as they can. They'll be drawn to your success as rats to food. It takes a lot of political savvy and energy to keep these freeloaders out of an effective team.
Exactly. It is not a perfect solution. Ideally there would be only 2 or 3 owners, and an accountant above all these silos.
The bigger problem is that it would encourage bitter feeling between teams. If a silo is not successful and freeloaders are not pruned, then there will be a tendency for a silo to sabotage another silo if they think their collective job security is at risk. It is not a perfect solution. It can be approximated but still actually separate small companies is what makes more sense.
Silo-fication is good in a large company, you find a good silo and you make sure the rest of the dreck doesn't infect your group. If you've got a decent financial whiz who can end-run the bean counters in your silo even better.
Take a look at a farm, what's outside the silo? Rats, rot, waste, what's inside the silo? Stuff you can sell for money that is well protected from the elements. In a large company you need to be a very adept bargainer / barterer to acquire all the resources you need despite the bean counter mentality.
There's also something Fred Brooks observed in The Mythical Man Month - at some point, the marginal productivity of adding an additional programmer to a team is outweighed by the marginal increase in communications overhead and complexity.
In cases like that you can improve productivity by actually cutting the team's size and pairing less important features.
While I agree with your point, the author's argument does not allow for rockstars and slackers - all programmers have been reduced to the mythical $10k/month level (i.e. man-month is the measure of all things).
Actually, the large differences in individual productivity have more to do with the slackers than with the rockstars.
Some programmers, in some environments, are negative net productivity programmers. If some programmers literally get nothing accomplished at all, then you can easily say that "some programmers are 10^3 or 10^6 or 10^100 times more productive than others"
Another factor in "rockstar" productivity is that you need to get all the bull out of the requirements gathering process. I've seen so many places where it takes six hours of time working with "customers" to figure out the requirements for something that takes 6 minutes to implement. Tasks that are absolutely trivial can stretch on for weeks if your organization can't be decisive about getting them done.
Of course, in large teams there's a lot more bull to go around.
It's one of the things the author misses, at a certain scale the requirements are such that gathering them and managing clients requires more personnel than the actual writing of the code.
And a thirty person team is not only more likely to have several interns, but also people who spend a significant amount of time training, mentoring, and managing them.
Free loading includes plain slacking, doing things the fun way rather than the good-enough way, playing politics, keeping yourself busy with unnecessary management/coordination, etc.