Contrary to popular belief, managers are not there to ‘make difficult decisions’. What makes a decision difficult usually, is a lack of information. What makes a decision dangerous is the lack of knowledge of how to use that information.
If a manager selects one item from a list of choices or approves an initiative instead of delaying it, these are decisions, but not difficult decisions.
Choosing from a list
Given two similar candidates for a job, there is not enough information to make an informed decision. The easiest way to make a partially-informed decision is to just toss a coin. If the manager wants to make an informed decision they must gather more information.
Inviting each candidate to work alongside colleagues for a day or two would provide valuable empirical data. At Menlo, Richard Sheridan gathers feedback simply by asking people that worked with the candidate to vote thumbs-up or thumbs-down. Candidates receiving all thumbs-up are hired and there is no discussion about why a thumbs-down was given. They discuss only candidates who receive a sideways-pointing thumb, as that indicates they don’t mind one way or another. Since that is not a yes it warrants the investment in time needed to understand it.
If doing something as different as a trial working day seems too difficult, has too much red tape to cut through, or no manager is willing to step-up to lead it, then your decision-making is going to remain ill-informed. Tossing a coin will be a more efficient way of making decisions because it is very quick. Of course, candidates will get to hear about your decision-making process, so explaining why you operate recruitment this way would give them the information they need to make an informed decision. That would be efficient for them too.
Approving an initiative
Everyone wants their project to go ahead and quickly. Yet deciding to ‘do nothing yet’ can be the more valuable decision. The term for this is options, or real-options as Dan North describes them.
Businesses use financial options to protect their assets and speculate on future outcomes. Financial options are said to have value and expiration. Value reduces as the expiration date approaches, simply because more information is available and very little is left unknown. This shift over time from unknown to informed is why options must be reviewed frequently. In volatile situations that review might be daily.
Outside the financial sector, options are used to buy time. Additional time allows smart decision-makers to invest in reducing ambiguity by gathering more information if they wish. Even without spending more money, the longer a decision is delayed, the more choices remain open and the more is known about the future. Mary and Tom Poppendieck describe this as making decisions at the last responsible moment.
Of course, the last responsible moment is not to be confused with the last possible moment, which will lead to panic and rushed decision-making. Also, options should never be misused as a way of avoiding doing something you find personally uncomfortable.
Consider a typical IT system. It is making money for the company, but is legacy and struggling to keep up with the volumes and demands of the organization. The commercial department wants to get the maximum value from the investment already made and sees it is still coping, but IT wants to replace it because they see a myriad of problems, any one of which could be disastrous.
This is really two decisions, often made difficult because they are perceived as one. Decision A is when to switch-off the current system, decision B is when to start building or procuring the next system. Independently, these decisions are straightforward. Note too, the decision relates to time, when, not how.
Decision A is the easiest because you have a wealth of information readily available; how much it costs to run the system in staff, licenses, errors and how much revenue or good-will it is processing. The only uncertainty is when the costs will exceed the revenue and good-will. The answer is now obvious, monitor the costs and switch it off at the point they exceed the yield. That is the only decision to be made because everything that follows can be pre-planned. Letters to customers thanking them for their custom and saying the service will cease, cross-training opportunities or redundancies for staff, and hopefully, a big switching-off party.
Decision B is more interesting because it is really two different things. The replacement for the capabilities of the current system, plus the opportunity to build on the knowledge and experience gained. As well as operational, business domain knowledge, there will be much that has been learned from other technology areas that have evolved since the legacy system was built. A rule of thumb is that software has a life expectancy of about five years before the technology used to build it changes. The platforms it is built on changes about every ten years.
It is a common fallacy to assume the existing functionality is easy to reproduce in a replacement system. Although it would have started as a merely complicated system, carefully documented and designed, over the years it will have evolved into a multi-layered, entangled mess of disorganised chaos. A mound of spaghetti is easier to unravel than a legacy system. The people who asked for modifications have forgotten what they needed and why it was important, the people who made the changes have long since moved on. Every change made carries an increasingly large risk of failure because the safeguards built into the original design and build process are no longer present.
The only viable option is to bring the people who use and want the system together with the people who will build it for them and work-out the requirements for the next system. Trust the operators have the experience and knowledge to describe their needs and the engineers the skills to design it. Building it incrementally and iteratively allows fast feedback and will yield value sooner than any other approach. But it is a big system and it will take time you say, so what are you waiting for, a decision?
That wasn’t difficult
Hopefully, this discourse shows that having the right information renders ‘difficult decisions’ trivial. The big question of ‘should we rewrite this system?’ Becomes ‘Why aren’t we working on the next version already?’ And ‘let your legacy run until you can no longer afford that business’.
Decision-making is not a management function, just something we all do in our everyday work and home lives: a developer deciding to write unit tests to make their code easier to maintain by others is doing what they believe is right based on their knowledge, experience, and training; someone deciding to ask their colleague to read an email about a delicate situation before sending it; the receptionist deciding to come into work despite having an excruciating migraine. These are everyday decisions that could have long-term or far-reaching consequences, yet they are made without asking their manager to make them.
The manager’s responsibility is to make themselves accountable for choosing a particular course of action or inaction. They must gather the information they need to do this and may choose to consult others to get their opinion. They must break each problem down, not necessarily as presented to them, but as manageable ‘chunks’. For each chunk, they decide the action or inaction then get behind the classic sign that says ‘the buck stops here’.
