This post is part of a series on The Effective Executive (by Peter F. Drucker). You can find the first post here. In this post I’m going to tackle chapter 6: the elements of decision-making.
Chapter 6: the elements of decision-making
I had a hard time getting my head around this chapter. I’ve read it several times over the years and I’ve always glossed over it with the takeaway that effective executives make important decisions by following a decision-making process. Beyond that, my eyes kind of glazed over. I’ve encountered so many decision making processes over the years and they all have failed me in one way or another.
But since I committed myself to writing about this chapter in this post, I dove into it and I finally think I understand what Drucker was trying to tell us.
Effective executives make decisions of consequence for their organizations. They do not make a great many decisions but they follow a five step process that establishes a rule or policy that addresses the issue at the highest possible conceptual level. Once you make a decision it is not considered complete until it has “degenerated” into someone’s job and it has a feedback mechanism.
Step 1: is this a generic situation or an exception?
The first step is to determine which of four situations you are in:
1. truly generic – all the “problems” are just symptoms of the underlying condition
Until you address the underlying condition the symptoms will not improve. For example, I had a situation where my VM was crashing randomly, I was getting weird reboots, and my GIT repo became corrupted. At first, they all looked like unrelated problems. I wasn’t able to diagnose or eliminate these problems until I realized that they might be linked. I tested my RAM and learned it was faulty. That was the underlying condition tying those seemingly unrelated events together. Once I replaced my RAM (and repaired my repo), my problems went away.
2. a unique event for your company but it is actually generic in business
Examples might include deciding to migrate to the cloud, handling a merger and integrating multiple IT systems, or responding to a data breach. These might be unique events in the history of your company but they are quite common events in business.
3. a truly exceptional and unique event
This is an truly unique event without comparison in the history of your business or any business. Drucker mentions the thalidomide birth defects tragedy as an example. A parallel in programming might be the complexities and challenges of deploying self-driving car software. There’s no real template for the legal, ethical, social, and technological challenges of releasing that kind of software.
4. an early manifestations of a new generic problem
If you deploy machine learning-backed pricing bot you might start to see a whole new classes of problems such as:
- pricing bias/discrimination (illegal pricing strategies adopted by your bot)
- price manipulation by competing bots (bots manipulating your bot)
- sub-optimal pricing (your bot fails to outperform humans)
Bad things might even happen to you if a major competitor adopts a pricing bot. You might suddenly find your pricing strategy is ineffective even though nothing has changed inside your company.
You have inevitably struggled to read code other programmers have written. For example, people write overly complicated code or write in an unfamiliar style or with unfamiliar formatting. Lots of teams descend into endless arguments over the acceptable naming standard, white space formatting, programming paradigms, language features, etc. And the whole tabs vs spaces debate is alive and well.
Drucker would encourage us to solve this problem at the highest level possible. In PHP you can simply adopt the PSR standards. And you can even setup your IDE to automatically format your code in that standard. At my company we used a modified PSR standard. Our IDEs automatically format our code before every commit. And we have a couple static analysis tools that flag things we don’t want to see in our code base.
Anything you can do to avoid negotiating every detail of how your code looks or the language features you use is a win in my book.
Drucker argues that you must handle truly unique events (situation 3) on a case-by-case basis. Everything else requires a generic solution, a rule, a policy, or a principle. Once you have established the right principle, you can handle all manifestations of the generic situation pragmatically.
Step 2: develop a clear specification of what the decision must accomplish
How are you going to identify a solution that satisfies all your needs if you don’t know the boundary conditions of the solution? The short answer is that you can’t. Unless you have a clear understanding of the boundaries of an acceptable solution, you won’t be able to tell when a plan will solve the problem.
This makes sense. If your boss says that he wants your website to be faster but doesn’t give you any other guidance, how will you know what actions will satisfy “faster” in your boss’s eyes? You probably need target average and worst case response time targets at a minimum. You may also need to get your boss to set a limit on this project.
Without knowing the boundary conditions of an acceptable solution, your solution space is unacceptably large. Should you rewrite your website in C? Add a caching layer, dump your ORM and write raw SQL queries? Optimize your images? Serve your images from a CDN? Split your database from your web server? You won’t have any idea which–if any–of these solutions will solve the make the website “faster” problem.
Step 3: stick with what’s right rather than what’s acceptable
I can’t say this any better than Drucker:
One has to start out with what is right rather than what is acceptable (let alone who is right) precisely because one always has to compromise in the end. But if one does not know what is right to satisfy the specifications and boundary conditions, one cannot distinguish between the right compromise and the wrong compromise–and will end up making the wrong compromise.
Need I say more?
Step 4: convert the decision into action
Here’s more Drucker:
In fact, no decision has been made unless carrying it out in specific steps has become someone’s work assignment and responsibility. Until then, there are only good intentions.
How often has your boss said “From now on we are going to do x” only to have that decision last a couple of weeks (at most)? How often has some policy or initiative you’ve tried to implement followed that same path?
Drucker has some advice for us. Converting a decision into action requires we answer the following questions:
- who has to know about the decision?
- what action has to be taken?
- who has to take it?
- what does the action have to be so that the people who have to do it can do it?
- the people assigned have to be capable of the task
- make sure measurement, standards for accomplishment, and incentives are changed simultaneously otherwise people get caught in paralyzing internal emotional conflicts
If you can’t answer these questions, you might be in trouble.
Step 5: build feedback into the system
Drucker stresses that effective executives know they must go back and look at the results for themselves. It’s not enough to make a decision and communicate it to the appropriate people. You need to actually go look at the results yourself because that’s the only way to get reliable feedback.
It’s also the only way to see if the assumptions underlying the decision are still valid. Managers who fail to perform this step are the typical reason for persisting on a course of action long after it has ceased to be appropriate or even rational.
I worked as a solo programmer for many years. But at one point we needed more programming than I could provide so we hired a second programmer. I gave my new co-worker a few assignments and sent him on his way. Big mistake. We tried again but this time I gave my new co-worker more explicit instructions and gave him the opportunity to ask many more questions about the task. He still missed the mark. It took us a long time to make code reviews our policy. Code reviews were the only way we could ensure that all new code we wrote met our standards. Code reviews are the programming equivalent of “going to look for oneself.”
Now that we’ve made code reviews part of our culture, we are trying do more unit testing, which is a great form of fast, automated feedback.
I’ve never practiced the decision making process Drucker advocates in this chapter. I find Drucker’s advice to be practical in a lot of ways but it somehow doesn’t fit with how my mind works. I don’t naturally try to figure out if I’m faced with a symptom of a generic situation or an exception, even if I can see the value in solving a problem at the highest conceptual level. The “5 whys” analysis technique fits my brain better.
I also get the feeling that Drucker envisioned people using his framework to solve bigger problems than I typical face. Drucker’s examples are from situations faced by famous CEOs, military generals, and American presidents.
So your mileage my vary. Read the chapter if Drucker’s decision making process sounds interesting to you. Or skip it and know that all the other chapters are still very applicable to small business programmers.