The Essential Bezos - All You Need

After a recommendation from the top to read "Go read Moneyball for Engineers" - basically and article by the supermen of McKinsey, I start with Moneyball itself - by Mickey Lewis - boring stuff, but he makes a good point that we already know.

But, the Moneyball for Engineers article is a goldmine. You know you should look at stuff that matters - extract insight from the data. Now, there a tonne of that for baseball because you have a lot of people with nothing better to do than watch games and count beans related to them. Good. Now, ask good questions - it wasn't batting average that did it - so what else was it? And you find criteria that make a difference and now you can take corrective action.

What do you do with a team of engineers in the semiconductor industry - which, BTW, spends the highest percentage on R&D? Go to McKinsey, that's what :

Who do you look at :

1. Top performers
2. Project coordinators (go look at the Qualcomm layoff discussion forum to see all the complaints about "status collectors" (aka Mauricios)
3. remaining staff

What did they find out?

1. Team size : don't go above eight. Six to eight is optimal - Bezos' two-pizza rule
2. Team-member fragmentation : The insight is that one-project all the time is bad - spread your guys over multiple projects. Mechanical engineers can work on three concurrently before their productivity drops. This is not multitasking. You have things to get done in a day that belong to multiple projects. At any one time, you only focus on one task related to one project.
3. Collaboration history : You gain more from a team that has worked well for a while than a team of strangers
4. Individual experience : The strongest performance driver - beats education handily. Get and retain people with experience
5. Geographic footprint : Spreading the team out (increasing physical distance between members) hurts. You can lose 10% in productivity easily. (Trust me, it's way more).

That last one brought back the best part of Brad Stone's book into my mind : 

At a management offsite (for Amazon) in the late 1990s, a team of well-intentioned junior executives stood up before the company’s top brass and gave a presentation on a problem indigenous to all large organizations: the difficulty of coordinating far-flung divisions.

The junior executives recommended a variety of different techniques to foster cross-group dialogue and afterward seemed proud of their own ingenuity. Then Jeff Bezos, his face red and the blood vessel in his forehead pulsing, spoke up. “I understand what you’re saying, but you are completely wrong, ” he said.

“Communication is a sign of dysfunction. It means people aren’t working together in a close, organic way. We should be trying to figure out a way for teams to communicate less with each other, not more.”

Other classics :

“A hierarchy isn’t responsive enough to change, ” he said. “I’m still trying to get people to do occasionally what I ask. And if I was successful, maybe we wouldn’t have the right kind of company.”

All new hires had to directly improve the outcome of the company. He wanted doers—engineers, developers, perhaps merchandise buyers, but not managers. “We didn’t want to be a monolithic army of program managers, à la Microsoft. We wanted independent teams to be entrepreneurial, ” says Neil Roseman. Or, as Roseman also put it: “Autonomous working units are good. Things to manage working units are bad.”