Visible Decision-making

Decisions, advice, perspectives, pitfalls, diligence, design, discovery, spikes.

Nick Gibbon
Pareture
Published in
6 min readMay 23, 2024

--

Have you ever come across something done completely differently to how you might expect for no apparent reason? Have you ever been party to an unresolved disagreement? Or had conflicting direction from authorities that makes working in certain areas awkward and unclear? Have you ever had to put a large amount of effort in to doing something differently than it was done before for no clear benefit?

Good, clear, visible decision-making practises help avoid these situations.

Decisions need to be made when something is a bit different than the status quo and it’s not completely obvious what to do. Usually this means new stuff. New projects, new features, new ways of doing things. But decisions are needed in other cases too.

Decision Log

Summarily record what was decided, why and when in a central place that all team members can easily access.

A decision log is really useful for a team. It is a clear reference point for why something was done. It quickly removes confusion that might organically arise in the future and enables efficient forward progression for a team as they don’t need to periodically readdress the same problem across time unless something has materially changed from when the decision was made. This happens because people change in teams and even when they don’t they forget! A decision log does the remembering for us.

Examples

  • A recurring feature request comes up that you’re team has decided they won’t do for some reason. Log it.
  • A feature implementation is different than in other similar cases because of some obscure detail. Log it.
  • You’ve agreed with another team that some common problem is in their support domain and not yours. Log it.

Designs

Design documents are used to work through more complicated or bigger decisions.

You get all of the options with their costs and benefits in one place to discuss and decide. Design decisions can be made at the team level but also the department / unit and organisational level (or some relevant subset of the org).

Always start with being crystal clear on why the problem needs to be solved. What is the negative consequence or impact of not doing anything. What is the risk? What is the potential pay off? There are often more important things to do than there are resources available so it is critical to be able to assess the size and shape of each problem.

Where the decision needs to be made depends on impact. Who will be impacted? How significant would the change be? What is the cost in terms of cash, time and people? What is the complexity in terms of implementation and coordination? What is the time horizon? Diligence should scale somewhat with the size of the decision but we want good efficiency even for big decisions.

Jeff Bezos / Amazon has really good information on decision making:

Keys to decision making at speed
1. Recognise two-way doors. While some decisions are one-way doors, others are two-way doors, meaning they are reversible, and you can correct mistakes quickly.
2. Don’t wait for all the data. If you wait until you know everything, you are probably being too slow. Most decisions only need about 70% of the information you wish you had.
3. Disagree and commit. People can disagree, but once a decision is made, everyone must commit to it. This saves time versus trying to convince each other.

Try to use fast discovery techniques to remove uncertainty so you can make better decisions. Use spikes.

Isolate the specific questions that need answering and find the most efficient way to get that information. Write a report on what you’ve done and summarise the outcomes back in the original design doc.

Advice

If you’re going to be making a big decision then it should be in an area that you have a good grasp of. Agnostic of any input you should have your own instincts and be developing your own view of the solution. But on top of this use advice to your highest advantage. Don’t do everything, explain everything and then finally look for feedback at the end of the process but get advice early and often.

In your organisation you may look to your managers, your team, experienced colleagues, stakeholders, maybe you have an advisory board? Outside of your organisation ask the internet, ask your vendors, and ask other individuals. If there is significant investment on the line then pay for it. Organise short term positions to get perspectives from the best people you can find.

You shouldn’t go super deep in the details with most people. Outline the problem and ask about the core things they would think about in a solution. Add on any important constraints or details. Ask about how they would address specific risks that you are concerned about. Why do they feel this way? Is it instinct or evidence-based? Have they done it before? What was different about that situation? What would they have done differently with hindsight? You’re looking for fresh perspectives and what you might be missing.

Remember that advice is just advice. Everyone has different biases, incentives, experience and perspectives. Don’t get too attached to any individuals opinion and over-index on that (whether it aligns with you or not). Weigh it all as appropriately as you can and cast a wide net where the situation calls for it. You will inevitably find that some people you interact with don’t really grasp the problem. That’s fine. Just move on. If no one at all grasps the problem then it’s likely you aren’t communicating as well as you want to be.

This can be a really rewarding journey for those involved if you’re open. You can learn a lot. Everyone else can feel like they are contributing and helping without really having to invest much time or effort.

As an aside you should periodically do this with your team if you are in a leadership position. Ask everyone what 5 things the team should do in the next year if it was completely up to them. You will be able to learn about individuals perspectives and hopefully see some common themes. If your own plans differ greatly then perhaps you need to adjust them or work out how to frame the situation better.

Pitfalls

  • A decision is made by committee and becomes too convoluted. We should cast a wide net for advice and information but this all needs to be synthesized into a cogent solution that the decision-maker has confidence in.
  • The decision-maker has no real grounding in the domain of the decision. This is a precarious position to be avoided. In this case they can easily be influenced by arbitrary things like personal connections or the style of presentation.
  • Making important decisions without any advice or diligence at all. The decision-maker might have great instincts. But it might result in an avoidable and confusing waste of resources.
  • A decision is made and explained but it just does not align with anyone’s actual experience. Advice isn’t diverse enough. You could have really used some other perspectives or expertise. Ensure the right stakeholders are able to input. Those who are most affected. Those who are not related at all (and therefor can be more objective). Those with most knowledge in the area. Weigh their input accordingly. This probably isn’t appropriate for layoffs. But it’s generally the right move.
  • The right decision (or at least a good / reasonable decision) is made but there is no visibility in to the process and no good communication of what and why leaving those subject to the decision unsure about it.
  • A good decision is made and communicated at the time but it’s not recorded. Eventually people will forget and the issue will resurface.
  • A reasonable decision is made but there isn’t the right governance structure to ensure that the decision is implemented as intended leading to confused and variable outcomes.

--

--

Nick Gibbon
Pareture

Software reliability engineer & manager in cloud infrastructure, platforms & tools.