Engineering and Decisions: “How” Is More Important Than “What”

Aaron Crow
8 min readMar 20, 2018
Screenshot from “Storm Surfers 3D” showing a good decision process. From left to right: Ross, Tom, Ben, Antman

Good decisions are important. But good decision processes are even more crucial to your team’s success. Here’s how to support competent decision processes.

I’ve been a professional software developer for over 2 decades. In that time I’ve worked at a wide variety of companies. I’ve seen disastrous decisions, superb decisions, and everything in between.

I’ve learned that how we make decisions is even more important than what decisions we make.

Engineers who care about their craft adopt tools that promote good decision processes. We have blameless postmortems. We have design reviews, code reviews, and pull requests. The original ARPANET project gave birth to RFCs, which we’ve adopted on an informal basis.

GitHub.com as prime specimen

GitHub gave themselves the moniker, “social coding”. They could just as well have written, “good decision process in a box”.

Every commit is visible to everyone — immediately and forever — as is every line of source code. There’s an open ticketing system for questions, comments, suggestions, and complaints. There’s a robust pull request system for contributions and code reviews. We get a wiki system for collaborative documentation.

Or, “good decision process in a box”

These tools provide a powerful foundation for good decisions over the lifespan of a software project.

Let’s distill this embarrassment of riches down to three core functions:

  1. Welcome stakeholders. The process should include the people who will be affected by the decision.
  2. Transparency. The process should provide relevant data in a timely fashion. It should have a predictable lifecycle and a reasonable evaluation criteria.
  3. Fairness. Of course the outcome of a decision should be as fair as possible for those affected by the decision.

Any good decision process should provide the above. Otherwise it does not properly serve the stakeholders and should not be considered a competent process.

Failure vs. success

What’s the cost of a poor decision process? Of course we can measure damage done by a bad decision. But any worthwhile decision needs engaged employees if it’s going to be successful. With this in mind, let’s focus on the morale of the stakeholders as a key performance indicator.

The worst case of a bad process is not hard to imagine. It excluded stakeholders, was not transparent, and yielded a poor decision. Obviously, people will be upset by the decision and also quite bitter about the process.

But now let’s consider a bad process that actually arrives at a good decision. Stakeholders may tolerate the decision itself. But they will still be bitter about the process.

(“Why wasn’t I consulted?” … “Are you sure we couldn’t have done something better?” … “I don’t understand why you didn’t just do such-and-such.” And so on.)

Bitterness is a strong motivator for poor behaviour. It generates passive aggressive attitudes. It provokes a burning desire to punish the owners of the process.

On the other hand, the common worst case with a good decision process is far less ugly. Some amount of people may be disappointed in the decision but they will also be empathetic.

They’ll be empathetic because they witnessed how the decision was made. They saw the competing interests and difficult trade-offs. Even if they preferred a different outcome, they came out with an understanding of why the decision landed the way it did.

“When one is allowed to genuinely participate in a decision process, one tends to own the resulting decision.” — any smart leader

Here, then, is the price we pay for a poor decision process. Stakeholders will be unhappy and rebellious, in an infinite variety of forms, even when the decision is a good one.

But when we invest in a good decision process, stakeholders will be empathetic and gracious, even when the decision is a tough one.

Stakeholder morale is a key performance indicator of a decision process

Some options

We have a multitude of options and variations available to us as we design good decision processes.

As one example, the United States is a representative democratic republic. At the federal level, we vote to elect representatives who then make decisions on our behalf. Many other governments on Earth practice similar approaches.

This kind of representation is also a common mechanism for companies. You may ‘elect’ a boss who is then expected to represent your interests to higher layers of management.

But a good decision process does not have to resemble a democratic system. True, vote counting and representation can be effective in many situations. Still, we should have more tools in our toolbox.

Guido van Rossum is the creator of the Python programming language. In 1995 the Python community named him “benevolent dictator for life” (BDFL). A cadre of others, such as Larry Wall with Perl and Linus Torvalds with Linux, have been named BDFL by their respective communities.

Guido van Rossum, creator of Python and “benevolent dictator for life”

These communities recognize their leaders as particularly good decision makers. The leaders run decision processes that are inclusive, transparent, and fair. And their communities acknowledge them for it.

So we can see there are various mechanisms for a good decision process. Our job is to find the right ones for a given situation and wield them well.

You the user

As a stakeholder in a decision process you have some heavy responsibilities, including but not limited to:

  • Be open to learning and be careful about judging too early. Other stakeholders may have a different viewpoint than you, and it may be just as valid as your own. As Steven Covey taught us: “Seek First to Understand, Then to Be Understood.” Allow space for others to openly disagree with you.
  • Include yourself. It’s self-defeating to sit on the sidelines in silence and then be grumpy about a decision later. Other stakeholders deserve to hear your point of view. Share what you know.
  • Disagree and commit. If it was a good process and a fair decision, you now have an obligation to honour the outcome. Yes, even if it wasn’t your top preference. Buy-in and support the team.

A surfer story

The 2012 documentary “Storm Surfers 3D” follows world class big wave tow-in surfers Ross Clarke Jones and Tom Carroll as they hunt massive waves to ride.

Early in the movie there’s a harrowing scene involving a life threatening mishap. Tom tows Ross into a wave but Tom’s timing is off. He’s dragged over the falls along with the jet ski. That’s over 900 pounds of hardware dragging Tom into a giant washing machine, all bearing down on Ross.

Screenshot from “Storm Surfers 3D” showing Tom jetting over the falls.

Both surfers are rescued and boated back to shore, no injuries. But Ross is upset. He pointedly tells Tom, “I want to know what happened”.

This leads to an open hearted back-and-forth. Both surfers share their viewpoint, ask questions, and clarify. These two have worked together for decades. You can tell they love each other and trust each other deeply.

As they figure it out together, the tension evaporates. They start smiling and joking. Ross asks Tom, “So, you ready to destroy another jet ski?”

This is a big wave tow-in surfing version of a healthy engineering postmortem. This is what we do at work when something big goes wrong.

After the main crisis is over, the stakeholders gather to compare notes on exactly what happened. It’s a decision process… What did we learn? What should we change? What would we do differently if this were to happen again?

There can be an emotional cost in such processes. If you were a contributor to a mishap then you have to own that, which may not be fun.

If the team hasn’t yet developed a strong bond and deep trust, this kind of process can feel awkward. But it can also be exactly the exercise you need to forge deeper bonds.

Later in the movie Ross and Tom debate whether to try for Turtle Dove Shoal. The location is 55 miles off the coast of Western Australia. They’ve heard rumours of giant waves with the right conditions but no one has ever attempted to ride them.

This would be the most expensive and dangerous trip either surfer has ever attempted.

Ross and Tom gather with their dedicated surf forecaster Ben Matson. They video conference in a second forecaster, Paul “Antman” Paterson.

Screenshot from “Storm Surfers 3D” showing a good decision process. From left to right: Ross, Tom, Ben, Antman

Watching this scene, it’s immediately obvious that it’s a good decision process:

  1. Welcome stakeholders. All stakeholders are present. Everyone engages in the discussion… analyzing, debating, posing the hard questions. (Ross asks Tom, “Are you ready to put your life and your money on this?”)
  2. Transparency. Pertinent data, in the form of charts and an open laptop, is on the table for everyone to analyze.
  3. Fairness. The final decision (go or no go) will be fair — neither Tom nor Ross are going to agree to do something they don’t want to do.

Of course, any difficult decision runs the risk of a bad outcome. But by running a good decision process we can meaningfully bolster our chances for success.

Later in the movie we learn that Ross, Tom, and their team decided to do the mission to Turtle Dove. We see a spectacular series of rides, including successful tow-ins by both surfers. They became among the first humans to surf the giant waves at Turtle Dove.

Screenshot from “Storm Surfers 3D” showing Ross killing it at Turtle Dove after a tow-in from Tom.

Go decide!

You should care deeply about the quality of your decision processes.

Measure the quality of a decision process based on inclusion, transparency, and fairness of outcome. Check the morale of the stakeholders.

With a poor process you may arrive at good decisions but people will be bitter. With a good process you may arrive at tough decisions but people will buy-in.

Poor processes can be damaging, while good processes can support great teams.

Now go have some good decision processes!

--

--