I ended part one with two questions: Why do these different kinds of work cause problems? And why do those problems seem to get worse as the company grows? Let's get to the answers.
- Apples-and-oranges trade-offs. It's extremely difficult to make intelligent trade-offs between things that are not at all alike. For example, should we invest a week of engineering time into making our website more failure-proof (which we're pretty sure will pay off right away) or into experimenting with a new technology (that might pay off in months, years, or never)? If I have some budget for outside help, should I hire a vendor to help us drive down our payment fraud rates by 1% (ROI easy to predict), or hire a market research firm to give us insights into potential customers (ROI hard to predict)? It's much easier to make trade-offs within a single kind of work than across types of work.
- People have natural affinity for some kinds of work. Even worse, in my opinion, is that I know there are at least a few readers out there who read the previous paragraph and thought, "those aren't hard choices to make; it's obvious what you should choose..." That's because most people have a natural affinity for certain kinds of work. Have you met that prickly operations guy who seems to love servers more than people (but would never let them fail on his watch)? Or the zany innovator who just can't comprehend schedules but always has a new trick up her sleeve? Those are the natural leaders of the kind of work they were born to do. But they are often counter-productive when placed in a management role for other kinds of work. Sometimes, just having other kinds of work being done nearby is enough to drive them crazy. This can lead to a lot of needless politics and needless suffering if it is not proactively managed.
- People get trapped doing the wrong kind of work. Successful products and features have a natural lifecycle. They are born in R&D, become part of the company's DNA in Strategy, delight zillions of customers in Growth, and eventually become just another box on a Maintenance checklist somewhere. The problem is that people who were essential to the product in a previous phase can get carried along and find themselves stuck downstream. For example, the original innovator from R&D can find himself the leader of a team tasked with executing incremental growth, because he understands the feature better than anyone. Or a critical engineer, who wrote the breakthrough code that first helped a feature achieve scale is considered "too essential" to be relieved of responsibility for maintaining it. This has two bad consequences: it puts people in jobs that they are not ideally suited for, and it reduces degrees of freedom for management to make optimal resource allocation decisions. If your top performers are all stuck in Growth and Maintenance, who do you have left in R&D and Strategy?
In part three, I'll lay out the criteria for such a process, and describe the techniques I've used to make it work.