One of the most persistent myths in software development is the notion of the hero developer—the rockstar, the machine, the great programmer—who gets things done. They work faster, fix more bugs, ship more features, and deliver more code than anybody else. They are legends.
And like most legends, they don’t really exist.
Oh, sure, you’ll hear people talk about this guy or that who once did this great thing, but when you dig into it, you find that they aren’t actually 10x more productive than the next developer. Often it’s somebody who stepped up in a crisis—managed to get things done in an otherwise comprehensively broken system—or, conversely, they are developers who caused a crisis by disregarding the needs of the rest of the team.
Maybe they exist somewhere, but it’s always somewhere else. Somebody they heard about in another team. The 10x developer is the Bigfoot of software development. Frequently sighted; rarely seen.
What does exist is the 10x organisation.
Organisation versus individual variation
One discovery made in a study by Tom DeMarco and Timothy Lister, the authors of the book Peopleware, was that performance among developers in an organisation was generally very similar. Programming language, experience, code quality, and salary generally didn’t result in meaningful performance differences from developer to developer.
The fact that they had nearly identical performances suggests that the wide spread of capabilities observed across the whole sample may not apply within the organization: Two people from the same organization tend to perform alike.
But what did matter was the organisation itself.
Over the whole, sample the best organization (the one with the best average performance of its representatives) worked more than ten times faster than the worst organizations. In addition to their speed, all competitors from the fastest organization developed code that passed the major acceptance test.
(I recommend the book Peopleware. It’s highly approachable and full of workable advice.)
10x developers don’t exist, but you do have 10x organisations whose developers work 10x faster, at a higher standard, across the board, irrespective of their experience or pay grade.
Or, how your company or team is organised might cost you and your colleagues 90% of your productivity. A software company can have a 90% handicap just from its management, right from the outset.
The cruel theatre of performance reviews
This shouldn’t be too surprising, Deming had his 95% rule for a reason: “95% of performance is governed by the system” and he demonstrated it quite forcefully with the infamous Red Bead experiment.
It also fits with many people’s subjective experiences. Anybody who has been working in software for long enough will have experienced both dysfunctional and highly functional organisations; places where nothing ever seems to click and places where everything is running smoothly.
Management loves to do meaningless performance evaluations, pit employees against each other, and talk some developers up and others down, but the hard truth is that they’re the ones responsible for most of the variation in performance from worker to worker.
Employee performance, as measured and practised by most software companies today, exists solely as theatre to justify the layoffs and promotions that management wants.
It’s a farce. One that ends with an actual sacrifice: layoffs.