Getting Past the Deciders

September 28th 2011

As a developer in industry, you're almost never a lone wolf - you work within some team. So when big, architecture-level decisions need to be made, as much as you'd love to call the shots, you've got to get the consensus of the group. For example...

Imagine that some for some feature you're working, it could be implemented in a number of different ways, each with some impact to maintainability, performance, reusability, and development effort. You probably have a strong sense for which path is best, having looked at the problem in detail, but it's not usually wise to do anything until others (e.g. managers, business owners, other developers, etc.) weigh in. Until the decision is made, however, your task is blocked...and the sprint deadline looms.

In these cases, your job is to pop this decision up to the right group of people and facilitate the best decision, quickly so you can get back to work implementing the feature. Pretty simple, right? Just schedule a meeting, present the evidence, make your cogent argument, and they're bound to see the light. Err...not always.

In my experiences, facilitating a big decision is one of the more precarious, but crucial, tasks of the enterprise developer. Even if you get the right people in the room to make the decision, the discussion is like walking a tight-rope - one wrong step and you fall into the pit of indecision, or worse the abyss of irrelevant pontification.

So what can we do, as developers, to facilitate good, collective decisions? One useful thing to consider a psychological phenomenon called decision fatigue, defined as:

"the deteriorating quality of decisions made by an individual, after a long session of decision making" (wikipedia)

On large enterprise projects, decision fatigue is (depressingly!) the standard mode of operating for many of us. On any given day, we all must navigate and make decisions on dozens of complex, confusing, and frustrating issues, and this all takes mental energy. The more choices we make, the more tired our brains get, and according to theory of decision fatigue, the more likely that we'll then make bad decisions, or defer the decision altogether (a decision in itself!)

Back to the original example then, how can you help the group not fall victim to decision fatigue, so they can come to a good decision and you can get back to your task? Here are a few strategies:

1. It's always best to schedule morning meetings for important decisions. In a recent study on parole hearings in Israeli prisons, it was found that judges gave out parole 70 percent of the time when appeals were heard in the morning, and only 10 percent of the time when they were heard in the afternoon. Essentially, after hours of listening to arguments, decision fatigue sets in, and judges would rather make no decision than the wrong decision. Anecdotelly, this seems right - how many afternoon meetings end in the insanely-frustrating: "let's schedule another meeting!" - i.e. decision deferred.

2. If decision fatigue is the result of making hard choices, then another answer is to make choices easier for the group. One way to do this is to limit the solution set. For example, a study discussed in the book The Paradox of Choice found that consumers were 10 times more likely to buy jam when they were presented with 6 flavors rather than 24 - in other words, too many options make decisions difficult. As developers, when presenting decisions to the team, it's important therefore to frame the decision in the most "cognitively fluent" way possible, identifying ahead of time the salient trade-offs and simplifying to a manageable set of possible solutions.

3. Lastly, if the first two tips don't work, bring some candy for the team. Seriously. In studies done by Roy F. Baumeister, it was shown that sugar (specifically glucose) can effectively rejuvenate the brain from its decision fatigue, improving self control and the quality of decisions. (Note that it's this effect that is partially responsible for the junk food you buy when grocery shopping on an empty stomach - your brain's out of fuel, and so it makes poor decisions.)

Obviously, there's plenty more to consider when helping a group come to a big decision, but being aware of decision fatigue might help. As always, let me know what you think! (and if you're interested in some of the research, here's a great starting point.)

I'm an "old" programmer who has been blogging for almost 20 years now. In 2017, I started Highline Solutions, a consulting company that helps with software architecture and full-stack development. I have two degrees from Carnegie Mellon University, one practical (Information and Decision Systems) and one not so much (Philosophy - thesis here). Pittsburgh, PA is my home where I live with my wife and 3 energetic boys.
I recently released a web app called TechRez, a "better resume for tech". The idea is that instead of sending out the same-old static PDF resume that's jam packed with buzz words and spans multiple pages, you can create a TechRez, which is modern, visual, and interactive. Try it out for free!
Got a Comment?
Comments (5)
September 29, 2011
what are you talking about?
there is never, ever more than one person who calls the shots. That person may be a delegate of the client (or the boss) but there is never ever more than one.
In an agile sprint that is called the product owner.
Now, on big decisions he may have to consult with other people. that is fine, that it's his job.
You, as the developer however, you can tell him: i need a decision by tomorrow afternoon or the feature gets dropped from this sprint. That again can happen and is fine.

what you're saying here , in the blog post makes no sense ans is idiotic. Now we are all dumber by reading it. please stop doing this.
September 29, 2011
Commenter giony has clearly never dealt with non-corporate management, i.e. non-profit organization, government, etc.
September 30, 2011
Thanks for the comments (I think).

@Giony - haha. We obviously don't work in the same places! :) There's a good point in there, but mind-spiritedly wrapped! Anyway, I respectfully disagree. I've been a consultant for over a decade, engaged on dozens of projects. There are certainly environments where there is only one primary decision maker, however this, in my experience, is the exception not the rule - isolated to smaller teams/organizations.

Most large, enterprise/government/non-profit environments (again, in my experience) are to some extent consensus-driven - and necessarily so. Issues are often complex, and multi-faceted. For example, from the scenario I laid out, it's very possible that the "issue" to be solved impacted scope (an interest of the product or business owner), schedule (an interest of the project manager), maintainability (an interest of other developers), and performance/scalability (an interest of the architect). The decision that comes out must be some trade-off of each, which means each stakeholder should have some say in the decision.

Further, issues often impact other software systems in different silos of the organization, which means the decision is hashed out by product/business owners/managers at equal levels in the org chart.

@P - thanks. :)
October 03, 2011
Really good post. I would add one more suggestion; improve your pre-meeting "ground game". Before pulling the deciders together get a high level summary of the options. A few sentences for each. Make it clear you're willing to chat before the meeting with anyone who has questions about the options. And make it clear - explicitly clear - that the meeting is to result in a decision and not a call for further research or consideration.

These pre-meeting actions account for people who process information better by thinking about it in advance and it also sets the expectation that a decision is to be made.
October 12, 2011
@BigPigVT - great point. Letting people mull over the decision prior to the meeting is key. Thanks for that!