Technically it’s not backed by a study, but by the personal observations of a pair of engineers who started a consulting firm with the goal of helping other companies succeed at engineering. After doing that for twenty or thirty years, they wrote Peopleware to try to put to paper everything that they had learned.
The 10× number was intended to be qualitative rather than quantitative. They openly acknowledge that there is no one single measure of productivity by which all engineers can be measured, but point out that productivity does vary quite a lot from person to person, and that you shouldn’t expect engineers to be fungible. If you have a 10× engineer, you should do your level best not to lose or misuse them; replacing them might involve hiring a lot of people. That includes not just paying them more, but also allowing them to choose what they work on. Salary is an extrinsic motivation, but choosing what to work on is an intrinsic motivation. Intrinsic motivations trump extrinsic every time.
They also take the time to point out that productivity cannot be the only way that you value the people in your engineering teams. For one thing, not everybody in an engineering organization is actually an engineer, and they matter just as much. Even the project and people managers matter a lot to the ultimate success of an engineering project.
They also point out that there are very frequently team members who are average or below average engineers, but who still manage to improve every team that they are a member of. They’re the ones with non–engineering skills that they use to bring the team together, get everyone to like each other, build esprit de corps, etc.
A lot of advice in the book will seem quaint by today’s standards. For example, there is a whole chapter about offices. It recommends putting no more than two or three people in a single office, and recommends that part of that space be used for communal furniture like couches, coffee tables, bookshelves, etc. Engineers should design those offices themselves, drawing on a pool of real estate and furniture owned by the company. The offices used by an engineering team should all be near each other, but not near the offices of their managers, lest the managers get the idea that they are supposed to be involved in the engineering in any way. Of course today most companies would rather cram hundreds of people into a crowded and noisy open–plan office. On the other hand, it is possible today to do good engineering work from home, and not need offices at all. That wasn’t possible at all in the 80’s when Peopleware was written, let alone the 60’s.
But the insights about building high–functioning teams by understanding the individual people that those teams are made of are timeless.
The 10× number was intended to be qualitative rather than quantitative. They openly acknowledge that there is no one single measure of productivity by which all engineers can be measured, but point out that productivity does vary quite a lot from person to person, and that you shouldn’t expect engineers to be fungible. If you have a 10× engineer, you should do your level best not to lose or misuse them; replacing them might involve hiring a lot of people. That includes not just paying them more, but also allowing them to choose what they work on. Salary is an extrinsic motivation, but choosing what to work on is an intrinsic motivation. Intrinsic motivations trump extrinsic every time.
They also take the time to point out that productivity cannot be the only way that you value the people in your engineering teams. For one thing, not everybody in an engineering organization is actually an engineer, and they matter just as much. Even the project and people managers matter a lot to the ultimate success of an engineering project.
They also point out that there are very frequently team members who are average or below average engineers, but who still manage to improve every team that they are a member of. They’re the ones with non–engineering skills that they use to bring the team together, get everyone to like each other, build esprit de corps, etc.
A lot of advice in the book will seem quaint by today’s standards. For example, there is a whole chapter about offices. It recommends putting no more than two or three people in a single office, and recommends that part of that space be used for communal furniture like couches, coffee tables, bookshelves, etc. Engineers should design those offices themselves, drawing on a pool of real estate and furniture owned by the company. The offices used by an engineering team should all be near each other, but not near the offices of their managers, lest the managers get the idea that they are supposed to be involved in the engineering in any way. Of course today most companies would rather cram hundreds of people into a crowded and noisy open–plan office. On the other hand, it is possible today to do good engineering work from home, and not need offices at all. That wasn’t possible at all in the 80’s when Peopleware was written, let alone the 60’s.
But the insights about building high–functioning teams by understanding the individual people that those teams are made of are timeless.