Book Review: First, Break All The Rules

If you are a tech geek, having your boss read this book is probably the next best thing to reading "The Mythical Man Month."

Geeks have said for a long, long time that there is easily a 10-to-1 ratio of productivity between the best developers and an average developer. There is tons of evidence to this fact... however it is still a difficult reality to swallow for some folks. In many cases, you're better off with a team of 3 good developers, than a team of 20 average developers. This book not only validates this claim, but also provides proof that this productivity ratio exists in every job role!

This was based on data from a 25-year survey by Gallup... they interviewed over 100,000 people, trying to find out who were great managers, and what they knew. Almost uniformly, they knew that the standard rules about managing people were completely bogus. They break down what attributes your employees have into 3 buckets:

• Knowledge: Basic information; "book learning." People with knowledge interview well, and test well, but that doesn't always translate into productivity. Training people "knowledge" is fast and easy.
• Skills: This is applied knowledge. A great deal of accounting and data entry is applied high-school math, but that doesn't mean any high schooler can do it. They need the skills to know when to apply what knowledge and when. Training people a "skill" takes time, and not all people are cut out for every skill.
• Talent: The most important of the bunch... somebody not only with skills and knowledge, but their brain is wired to be exceptional at this task! You can have a talent for sales, accounting, data entry, development, bartending, housekeeping, management, anything! Training people a "talent" is extraordinarily difficult, but you can find it during an interview.

This book validates what I have said for a long time: manager is a role, not a rank! Only people with the "talent" for being managers should be managers. It should not be an expected career path for all.

One talented employee is easily more valuable than 10 of her peers, across the board. This book provides sufficient examples that should make any decent manager rethink their methods of using their employees like cogs in a giant "process machine." A good manager should look for "talent," and not "skills" or "knowledge" during an interview... and then figure out a way to help their employees harness their latent talent. If so, then you will see 10 times more productivity out of a talented employee, compared to an average one.

This has nothing to do with knowledge, skills, or process... the talented ones just "get it." They see the problem, they know inherently how to solve it, and it brings them tremendous joy to solve it. Don't promote these stars to management; that's not their talent. Instead, let the exceptional employees -- like exceptional baseball players -- make more than an average manager. They call this "broad band" pay scales, and in practice they work pretty well to make sure everybody is exceptional at their role.

What about developers? They had a few things to say about them... somewhat oversimplified, but they said a common career path is from developer to systems analyst. In other words, go from designing one system, to designing integrated systems that work together.

This is a HUGE mistake.

Why? Because both roles require different talents! Developers are problem solvers, but in general they need ALL the pieces of the puzzle before they want to try to solve it. There is no feeling more frustrating to them than not being able to solve a problem because you weren't given sufficient data... or a complete specification.

To illustrate... Imagine you work at a software company. If you ask a talented developer a technical question, but you don't give sufficient information, you might have just cost your company a full day's worth of developer productivity. Why? Because the developer will seethe, and stew, and gather his buddies for a hallway bitch-session about you... which will cause others to likewise seethe and stew, and grumble about how "nobody ever gives them enough information." It all adds up to a full day lost.

It happens. I've seen it.

In contrast, a systems analysts (or architect) thrives on incomplete information. They know they are designing a system with a lot of people, a lot of requirements, a lot of needs, and thus a ton of moving parts. People don't know what they want, because nobody really knows what is possible. An architect can't wait around forever to create a specification: he needs to experiment a little. This means iteration, agility, extreme programming, and all that garbage.

It is certainly possible for one person to have both skills... but usually the best developers have a mild weakness at integrated systems, and vice versa.

Getting your manager to read this book might be tricky... "you suck! read this so you suck less!" Nevertheless, its a good book that will help you make the case that there is talent in every role... you're not asking for special treatment when you ask to play to your strengths. You're asking that your manager let you do what all great managers do.

Simple as that...