Kennis Decisions: 5 Considerations to Become Better at Making Them

Decisions: 5 Considerations to Become Better at Making Them

I've always had a hard time making decisions. I can endlessly weigh the pros and cons of each possibility, not being able to make up my mind.

Sounds familiar? We see it happening all day, just like the exact opposite: co-workers just doing the same thing over and over again, because this is the way we have always done it. So how can you become better at making decisions? As I just said I'm no expert on the matter, but the following guidelines might help you to become a better decision-maker.

1. There is no right or wrong

There are only choices which are more, and less beneficial in your situation. Why? Because every option has its own up- and downsides, but every 'wrong' choice has its advantages, however small they might be. For example;

  • "Will I use Spring or EJB?"
    → Spring is more flexible but leads to less homogenous applications, EJB is less flexible but all convention-over-configuration (so, it depends).
  • "Should I refactor this method or just leave it?"
    → Refactoring complex algorithms sometimes leads to less understandable code (so, it depends).
  • "Should we give the developers more freedom of choice in the language used for this project or not?"
    → More freedom means more creativity, but can lead to less maintainable software.
  • "Do we use a relational, or key-value based database?"
  • et cetera...

For a fair decision, you should take note of both up- and downsides of each option. Special thanks to Dan North (https://dannorth.net/about/) for pointing this out at Craft Conference during his awesome talk!

2. Specialist Syndrome

As software specialists, we often neglect to offer alternative choices. Why do we do this? Because we think we know what the best option is and as such consider it being the only option, skipping the part where we think of the alternatives. This is a dangerous game to play, because:

  • No matter how skilled you are, nobody is right 100% of the time.
  • It discourages creativity (creative, not-so-obvious options might be better than the obvious 'best' option).

The best specialists identify the up- and downsides of all options. If you can't point out the downsides of your favourite tool or language, you're not a specialist but probably more of a salesman.

3. The Right Decision at the Right Time

Do you really have to make this decision right now? If you think you can make a better decision later (because you've obtained more information by then), delay it. But be aware: making a decision too late can be just as harmful: everyone else may already moved on, making assumptions about the issues you had to provide the answer to.

4. The Ponder Trap

Sometimes, making a decision is more important than making the right decision:

  • When your team calls for leadership (guiding the decision) and you fail to provide (no clear decision is made), you may be off worse than when you made a suboptimal choice.
  • You can't decide which testing tool to use and don't choose at all; leading to missing tests, leading to bugs not being discovered.

This is especially true for decisions which require action right now. For example, crunch-time in the Production Emergency War Room ('Do we analyse the running container or do we shutdown to prevent further data loss?')

5. The Delegation Pattern

And last but not least: are you really the person who has to make the call? Depending on your role, you can (and should!) delegate a part of the decision making to your team and co-workers. Let other people make decisions and watch them grow. But be aware: being allowed to make decisions means you should feel accountable for them. If you feel like you can't defend your choice, don't accept the responsibility for having to make it.


These points help me streamlining my decisions. At the end of the day, evaluate your decisions: which ones did you make today? What helped you, and what didn't?