Indecision is a slow and painful death to both productivity and job satisfaction. A recent survey (pdf) found that three of the six main obstacles people face in performing their jobs are tied to decision making.
The sad part is that indecision is a management strategy for some (quite a few, according to this study which states “90% of Australians work in a negative workplace culture of blame, indecision and conformity.” We can only assume the numbers are similar around the world.)
In software development there are two kinds of indecision: developer and non-developer. Non-developers can be managers, internal users, marketing, or your CEO; whoever has a say in how your software will be built. For the sake of this article we’re going to look at non-developer indecision, and we’re going to refer to it, for ease of readability, as “management indecision.”
How Indecision Kills Productivity
What is the impact of management indecision on software development?
One study examined the disruptions caused by technology and resource failures in the workplace. They grouped the disruptions into two types: simple disruptions, and what they call “agenda benders.” Agenda benders “create a period of uncertainty and indecision, during which any existing plans are suspended; replanning may become difficult if not impossible. [Agenda benders] can, at worst, cause the entire day�s agenda to be abandoned, and at the very least, will leave it seriously bent out of shape.”
The study goes on to say:
“[When an agenda bender strikes] not only does she switch from doing high-priority tasks to filling in time with relative trivia, but she has no idea when her workstation will revive and must replan her day without adequate information. This uncertainty ultimately contributes to her inability to complete the �write specs � plan. Agenda benders appear to arise through a loss or breakdown of essential resources, for a period of significant but unpredictable length. Sometimes the missing resource is a person, e.g., a colleague who cannot be found for a vital meeting.” Or, I would add, information that cannot be obtained in a timely manner.
That being said, the impact of indecision is a potentially serious disruption to the development process due to a number of causes:
- The tendency for most people to freeze when faced with a question where they don’t have all the necessary information (described in the book How Would You Move Mount Fuji?)
- The effort it takes to note there’s a gap and come back to it once a decision has been made
- The mental exhaustion of feeling like you’re building a well-designed application that’s full of holes because no one will fill those holes with decisions
Why Developers Hate Indecision
If you’re a developer you know the frustration of not having the answers you need to keep working. You’ve probably experienced this more than you care to remember:
You start working on a new page, script, design, data model, etc… and realize the spec you’ve been given doesn’t have enough information for you to do your job. You walk over to your manager’s desk in search of an answer but he’s working on another issue and you have to wait.
You trudge back to your cube, realizing your deadline is not budging, but unable to continue your work until you have an answer. Your stress begins to increase and you resort to one of two things: sending an email and sitting on your hands until you get an answer (but looking busy, of course), or making the call yourself and living with the consequences. Either way your productivity is hammered and you’re now feeling the stress of having one more loose end on your mind.
“Surveys frequently rank managerial indecision as one of the top office torments, even above issues like low pay.” (source)
So why is it that no ones seems to make decisions?
Most of the time your question is a lower priority than the other tasks on a manager’s plate. Other times it’s due to corporate politics; no one wants to be responsible for a bad decision on a UI that doesn’t work for the Accounting team simply because he made a hasty decision and didn’t ask the accounting team what they wanted.
I genuinely believe that the majority or managers, internal users and yes, even CEOs, are not intentionally trying to see how much stress you can take before your head implodes. For better or worse, this is just one of the realities of working in a corporate environment.
Why Managers Should Hate Indecision: The True Cost
Summary so far: indecision is bad. It’s so bad, in fact, I maintain that most of the time a poor decision is better than no decision at all. This doesn’t hold true when launching nuclear missiles, performing heart surgery, or making software architecture decisions, but in most common software development scenarios it does. Let’s look at an example:
Developer: “The spec doesn’t say if we should show all products on this page, or only enabled products. What should I do?”
Manager: “Let’s call a meeting. We’ll get the four key people together, discuss it and come up with an answer. The soonest everyone can meet is next week.”
Developer: “But this is the core of the page. I need a decision to finish it.”
Manager: “Well, then, put it on hold and move on to something else.”
Now let’s examine the impact this has on the developer’s productivity and, ultimately, cost.
[Note: I know this next section will elicit a slew of comments like “Developers don’t make that much/little,” or “It would never take 2 hours to shift to another task.” In the end I decided that a practical example, even one that requires some subjectivity, is such a helpful part of this discussion that it’s worth including.]
To begin, the average salary of a Mid-level software developer in Los Angeles is $88,750 (Robert Half’s 2006 Salary Guide). With burden and overhead of 65% (this includes your benefits, employer’s portion of your social security and unemployment, the lights over your head, your phone, computer, software licenses and parking space) it comes out to around $146k, or just over $70 per hour (based on 2080 hours per year). A company employing a software developer making $88,750 pays approximately $70 for each hour they work, are sick, or on paid vacation.
In our example above, the first thing the developer has to do is participate in the meeting. Elapsed time: 1 hour (more if she has to prepare for the meeting). Cost: $70.
Next, she has to stop what she’s doing, add this to her to do list and come back to it in a week. Elapsed time: 2 hours to shift gears into another task then try to remember what she was doing when she comes back. Cost: $140.
After returning to the task after a week the developer is more likely to introduce additional bugs because of forgotten loose ends and a lack of familiarity with the code. Since “bug rates” per line of code varies widely this is difficult to measure. Let’s say that on an average day five bugs would show up in QA, but due to the disjointed nature of her development she introduces two additional bugs. The average cost to fix a bug based on this case study (careful, it’s a PDF) is $200. 2 x $200 = Cost: $400.
Finally, she now has another item cluttering her task list, she’s frustrated she can’t complete her work, she’s lost respect for her manager because he won’t make a decision, frustrated with her company for having to gather four people to decide how a single screen works, and she’s concerned she’s not going to remember all the details when she has to come back to the page in a week. Due to stress her productivity degrades 10% for the next 2 days. 16 hours x .10 = 1.6 hours = Cost: $112.
Total loss due to indecision: $70 + $140 + $400 + $112 = Total Cost: $822.
But wait, there are two other alternatives to this story.
One is that the manager makes a decision, and it’s the right one. In this case no additional time or money is wasted. Cost: $0.
The other alternative is that the manager makes the wrong decision. He sends an email to the parties involved indicating how they’ve decided to proceed, and finds out they screwed up. The developer has to go back and re-work the page after she’s completed it. Elapsed time: difficult to know, but assuming it’s a standard page we’re safe with an estimate of 6 hours. Cost: $420.
“Making a decision is a clear winner!” you think. But it gets worse.
These kinds of decisions come up constantly during development. Let’s say we have five developers working on a project and between them we encounter 10 in a week . If a monkey flipped a coin he’d choose the right answer half the time. Giving the manager the benefit of the doubt, let’s say he chooses correctly 60% of the time. 6 out of 10 times we break even, the other 4 we lose $420, for a total cost of $1,680 per week.
If we decide not to make any decisions we lose 10 times $822, for a total of $8,220 per week.
Let me say that again: blanket indecision loses $8,220 per week; making decisions (including bad ones) loses $1,680 per week. That’s a difference of $6,540 per week.
One approach will cost you almost five times as much as the other. Give that a few minutes to sink in.
Trying to Fix Things
Now that we’ve likened indecision to kicking puppies, terrorism and weapons of mass destruction, we’ve decided it’s bad for developers and for the company, and we’ve blamed everyone but the developer, what can someone do to move things along when the brakes are locked?
Here are three alternatives:
- Make it easy for someone to make the decision
- “Ambush” the decision makers
- Force a decision
Making it Easy
We can blame the managers all we want, but the bottom line is that leading a team is hard. As a former manager (who’s back in development by choice), the most common task I performed was making fast decisions with incomplete information. The not very surprising point is that the exact same situation that exhausts developers and kills productivity is the most difficult job of a manager, and the easiest to screw up.
The one thing I found most helpful when forced to make decisions without adequate information was to hear problems and solutions.
Here’s what I never wanted to hear from one of my developers: “Oh my gosh, we didn’t think that people would want to view the results on the blah blah page and now we don’t know what to do. Aaaah! We’re all gonna die!”
Here’s what I wanted to hear: “We didn’t think that people would want to view the results on the blah blah page. At this point we have two options: add the results grid, which is the right way to do it, and will take 2 days, or hack in a temporary table which will take 4 hours. Based on the schedule and where we are with out other tasks I think we should .”
What did the second developer just do? He gave me our best options. He turned this problem into a decision-making process, not a fact finding mission where I had to do recon to figure out the 10 possible approaches. Right away we could discuss pros and cons and make a decision quickly instead of wasting time back at the starting line. In this scenario I would likely suggest additional options, but starting with a base of 2 or 3 is a fabulous head start over the first developer, and makes me more likely to take the few minutes required to make the decision, rather than the 20 minutes needed for the first developer’s approach.
“Ambushing” the Decision Makers
This one is simple; if you need three people to make a decision, find out if they’re going to be in the same place at the same time and drop by. Or, better yet, have one of them walk with you to find the other two. Creating an impromptu meeting will only work with people who have serious buy-in to see your work succeed, or who are close to you in the org chart.
One other way is to try the ol‘ “drop by one and call the other” trick (this works best when you only need two people’s agreement). There’s no rule that specifies you have to wait until everyone’s in a meeting to make a decision (although this is likely the culture if you work at a big company). There are significant limitations to this approach, however, such as a lack of thorough discussion, visual aids, or a white board. If the topic is complex you are likely to receive blank stares and a look that says “I’ll see you at our meeting next week.”
Forcing a Decision
The third tool I’ve found useful is to force a decision. The phrase “We have to make a decision now or we’re going to lose x hours of time.” carries some weight with decision makers. Sure, they may put you off, but make a note that you said this and mention it again (as tactfully as possible) once the damage is done. Do this enough and someone may actually start listening to you.
It’s possible no one will listen to you, even after repeated warnings. In this case you have one of two choices: escalate the problem to your manager, your manager’s manager, the CEO, or whoever you think can address it, or think long and hard about how much your company really wants its software projects to succeed. If nothing changes after your best efforts, then you have little choice but to keep fighting, accept it, or move on.
The other way to force a decision is to make the decision yourself and do the work. People are less likely to change something that’s already been written. This is a back-handed way of getting things done, but it both makes your point and accomplishes something during the time you’re waiting. As with the other approaches, use this one with caution or you may find yourself pissing off the wrong people.
The Wrap Up
Indecision hurts productivity, job satisfaction, and the bottom line, and eliminating it should be on everyone’s agenda. Managers will likely be motivated by cost and morale; developers by the desire to meet their deadlines and avoid frustration.
Either way, we’re in the same boat. Hopefully someone will decide to steer.
Thanks to Mike Taber for reading a draft of this article.
