You can’t have it all

 There are two executive planning strategies: go for it all (cut later), and do a few things well (add later). Executives follow the strategy that best reflects their belief system. They use that planning strategy to drive work throughout the product cycle.

Executives who go for it all believe their staffs produce the most when they are under pressure and overloaded. “Expect little and you’ll get little,” would be their motto. Thus, they expect the impossible and are often rewarded for it. Their staffs work incredibly hard, frequently ending the product cycle with a prolonged engineering “death march.” They show their pride during raucous ship parties, at which they boldly proclaim, “They said it couldn’t be done, but here we are!” Everyone cheers and then regroups.

Executives who do a few things well believe the best quality and customer experience are the result of delivering a few critical scenarios seamlessly and brilliantly. They provide their staffs with focus—setting the expectation that the key scenarios must sing and that everything else is extra credit. Their staffs work at sustainable levels, but rally around integration periods, blocking issues, and exciting innovation extras. Their ship parties are less raucous, but show no less a source of pride in the remarkable experiences delivered.

Clearly, the executives who go for it all are getting more work out of their staffs and more alcohol at their ship parties. That’s better, right? Wrong. The executives who do a few things well may not work their staffs as hard, but they actually ship more high-quality features on time that result in a better customer experience. Why? Because you can’t have it all.

Eric Aside

I’ve heard go-for-it executives use the “Art of War” to justify putting their people through hell. “Throw your soldiers into positions whence there is no escape.… If they will face death, there is nothing they may not achieve.” People who’ve read Sun Tzu carefully know that this is a tactic of last resort for when you are cornered. The preferred approach is to set yourself up for success in advance. “Victorious warriors win first and then go to war, while defeated warriors go to war first and then seek to win.”

What’s the matter here?

It’s been proven over and over again that an engineering staff that does a few things well produces more features with higher quality than an engineering staff that goes for it all—even if the go-for-it staff works extreme amounts of overtime and slips its schedule (which staffs like this usually do). How can that be? The math seems wrong, unless you remember to subtract.

The go-for-it staff starts work on many more features than the few-things-well staff. However, software development isn’t an assembly line with predictable timing. It’s a learning process, discovering issues along the way. The few-things-well staff is aligned on features, swarming to solve issues as they arise. The go-for-it staff is charging ahead at breakneck speed without clear priorities, so issues fester and eventually cause features to collapse. Features are left incomplete, inconsistent, or cut.

To customers, incomplete, inconsistent, and cut features don’t count. As far as they’re concerned, that work never happened. Thus, all the time spent on them gets subtracted from the tally of time worked. What’s even worse, all those incomplete, inconsistent, and cut features create work for end-to-end testing, usability, user-research, integration testing, design, localization, security, and a host of other supporting teams. That time gets subtracted too.

The end game for go-for-it teams is typically a death march (often prolonged), a horror that I cover in detail in Marching to death. During death marches, people don’t have much time to think. They come up with quick patches that often regress and are poorly designed. The result is significant bug counts and significant rework. That rework time also gets subtracted from the staff total, as well as the supporting staff total.

Of course, the few-things-well staff also ends up cutting features and doing rework, just far less. People are focused and aligned with clear priorities, so what’s planned to ship typically does. They also have more time to think during the end game, so designs and fixes are better, resulting in less rework. The net tally of time worked minus time wasted puts the few-things-well staff well ahead and better positioned to adjust to changing requirements and markets.

Well, how did I get here?

If the strategy is always worse, why would an executive ever choose to go for it all? I think there are a few reasons.

• Going for it all does work. I never said it didn’t. I only said doing a few things well works far better.
• Going for it all is more macho. Microsoft still has a hero culture. Why be a wimp and do a few things well, when you can be a hero and go for it all? The answer: It takes an entire team to build a product, not just a few heroes. Just because you code your piece doesn’t mean the feature ships and is used by customers.
• Going for it all defers making tough tradeoffs. Who knows what customers will really like? Careful planning is hard and risks making the wrong choices. If you work on everything, you can delay making decisions about what matters most. Fractures in the engineering process will usually decide for you.
• Going for it all gives the appearance of productivity. Everyone is super busy on a go-for-it team. The fact that much of that time is wasted isn’t apparent until the end, when you can never get the time back.
• Going for it all creates commitment. The more trouble you go through to achieve something, the more value you ascribe to it. This is how fraternities and military units create attachment. Anyone who makes it through “hell week” or basic training will be deeply committed to the group. Going for it all commits the staff to the end. Alternatively, doing a few things well relies more on respect and trust.

While I can easily understand why executives choose to go for it all, I have greater respect and trust for those who choose to do a few things well.

Eric Aside

Our hero culture also leads to poor work-life balance, attrition, and sometimes divorce and health issues. Being committed to shipping a great experience on time is fantastic, but it can be done without sacrificing clear thinking and a balanced life.

I just can’t get enough

I can hear naysayers saying, “But what if I want my team to deliver more than a few things?” No one said you had to stop at a few things, only that those few things were the top priority and must be delivered with quality and on time.

We hire great engineers. They want to excel. They want to overachieve. They will attack the few key things and complete them on time if it means they can then add more innovative features and experiences. They’ll also find ways to make those few things really shine and surprise. It’s amazing what creative and motivated people can do.

Naturally, adding more features is risky, just as when you go for it all. However, when you do a few things well, the extra features aren’t critical. You can cut them without compromising critical deliverables and initiating a death march. That lack of pressure creates space to think, design, and deliver engaging enhancements instead of panicked patches.

So, did your team meet expectations by delivering a few things well, or did they exceed expectations by making those experiences pop and adding even more value on top? People take pride in their work. Trust them to exceed.

Eric Aside

I also covered this question in Pushing the envelopes: Continued contention over dev schedules.

Weird science

“But what about breakthroughs in natural user interface, search, or other research areas? Those are 99% perspiration.”  Yes, engineering is hard. This is not news. If your development plan includes new technologies, you’ll want to do tons of prototyping and iteration. You’ll want to measure and track your progress and have realistic goals. You’ll want to fail fast and call it when your work is good enough.

Knowing when your work is good enough is like doing a few things well. You plan for it. You achieve the seamless compelling experience, and then you try to do even better. If even better isn’t achievable, at least you’re still delivering value that customers can appreciate.

I’ll drink to that

As a manager, lead, or individual contributor, how do you handle working for an executive who chooses to go for it all? Set priorities for yourself and your team, and gather “air cover.”

• Your priorities should be based on the business and customer. Confer with your manager, colleagues, and team, and then make the call. Use those priorities along with lean software development methods to complete the most important and urgent work first. That will keep you a step ahead of the cuts.
• Your “air cover” is gained by being transparent about your priorities with your manager. You’re not revolting against your executive. You’re prioritizing your work in a way that mitigates risk and drives quality and predictability. Everyone likes that—even macho types.

Of course, you’ll want to get credit for being productive with high quality—you don’t want to be upstaged by careless cowboys. So report your completed feature counts and remaining bug counts regularly. Happily help cowboys clean up their messes and get credit for that too, or work on additional features while everyone else is scrambling. It’s tempting to be self-righteous about your superior productivity and quality, but being humble and helpful, while regularly reporting results, will get you much farther.

Regardless of which planning strategy your executive chooses, what matters is delivering high-quality, innovative, and compelling experiences to our customers. You can achieve that for yourself and your team by always doing a few things well at any given time. While ideally the entire organization is aligned with that approach, we each play an important role in bringing our customers true value they can appreciate. I’ll raise a glass to that every time.