Most of us in software (and probably in other fields) know about hero culture. It’s a concept everybody loves to hate. The term refers to an environment where individuals work in isolation and thrive on receiving sole credit for their work. This is generally perceived as leading to inflated egos and poor cooperation among developers. It’s the same phenomenon you see in professional sports, when star athletes are sometimes accused of not being good “team players” and getting greedy with the ball, wanting to be the center of attention.
So there are social reasons to dislike hero culture. There are plenty of practical reasons, too. One involves a principle known as the bus factor: the more you rely on a hero, the more vulnerable you are in the event of losing him or her—e.g., if he or she is hit by a bus, or leaves for another company.
But you guys know me. If everybody else is going left, I’m going to go right (a highly predictable trait that my friend Sameer frequently reminds me of).
If you turn away from hero culture and sprint in the opposite direction, you’ll eventually start getting into what I’ll call Borg culture.
Borg culture is the antithesis of hero culture, where every individual is functionally equivalent. In a Borg culture, there is no place for glory or arrogance. There’s also no pride and no personal ownership. I would argue that this isn’t really better.
A while back I wrote about software engineering versus software craftsmanship. In general, I think most of us would associate my description of “engineering” with what is typically done at larger corporations—less personal, more mechanical. That sounds like Borg culture. Actually, I think it’s just the opposite. Big companies are notoriously conducive to hero culture,