8 key differences between effective and ineffective decision makers

The other day I was just skimming through an wonderful piece of work by Peter F. Drucker called “the effective executive“. One of the important abilities of an effective executive as suggested by Drucker, is the ability to make effective decisions. He highlights some key differences between effective decision makers and the ineffective ones.

Decision-making is only one of the tasks of an executive. It usually takes but a small fraction of his time. But to make decisions is the specific executive task. Decision-making therefore deserves special treatment in a discussion of the effective executive.

Only executives make decisions. Indeed, to be expected—by virtue of position or knowledge—to make decisions that have significant impact on the entire organization, its performance, and results defines the executive.

Effective executives, therefore, make effective decisions. They make these decisions as a systematic process with clearly defined elements and in a distinct sequence of steps.

Let’s take a look at some of the crucial characteristics between effective and ineffective decision making.

1. Not many but few important decisions

Effective executives do not make a great many decisions. They concentrate on the important ones. They just operate on the qualitative layer rather than just marching forward on the quantitative road as well.

2. It’s not just about solving problems

They try to think through what is strategic and generic, rather than “solve problems.” According to them, it’s not just fire-fighting or damage control, rather it is prevention and control, coming up with a long-term option to deal with homogeneous problems in future.

3. On the highest level of conceptual understanding

They try to make the few important decisions on the highest level of conceptual understanding. Conceptual understanding is knowing more than isolated facts and methods. The successful executive understands the core ideas, and has the ability to transfer their knowledge into new situations and apply it to new contexts. This deep conceptual understanding is a key principle for effective executives.

4. Seek the invariants

They try to find the constants in a situation. They feel the significance of working with the immovable parts of any problem is the most effective way in decision making. It’s better to hold onto something one has already than to risk losing it by trying to attain something better.

A bird in the hand is worth two in the bush.

5. It’s not about speed.

They are, therefore, not overly impressed by speed in decision-making. Rather they consider virtuosity in manipulating a great many variables a symptom of sloppy thinking.

Sloppy thinking is something we’ve all been “diagnosed” with at some point in our lives. We get distracted, forget to ask the right questions, ignore the data, shoot from the hip and jump to conclusions.

6. What it’s all about?

They want to know what the decision is all about and what the underlying realities are which it has to satisfy. An effective executive requires a deep knowledge about the decision and it’s implications in the real world without just making the decision and move on, in the theoretical realms.

7. Techniques are for amateurs

They want impact rather than technique, they want to be sound rather than clever. The Expert never cares about the technique, he knows that there is not one single technique, recipe or formula to make the right decisions for every problem. He knows a great many techniques, and also to improvise those at any point of time to make the effective decisions.

8. Principle vs Pragmatic

Effective executives know when a decision has to be based on principle and when it should be made on the merits of the case and pragmatically. They know that the trickiest decision is that between the right and the wrong compromise and have learned to tell one from the other.

Good intentions

They know that the most time-consuming step in the process is not making the decision but putting it into effect. Unless a decision has “degenerated into work” it is not a decision; it is at best a good intention. This means that, while the effective decision itself is based on the highest level of conceptual understanding, the action to carry it out should be as close as possible to the working level and as simple as possible.

Let’s summarize the differences between effective and ineffective decision making.


Image credits

  • Pictures from Unsplash
  • Photo by Marvin Ronsdorf on Unsplash


Why experience and intuition can ruin decision making?

Why experience and intuition can ruin decision making?

There is more than one way. There is always more than one way.

There is more than one way. There is always more than one way. This simple credo can be a practical beacon throughout our professional life, leading us to consider alternatives in how software might be organized and how people might be organized. But recognizing alternatives also carries a burden, the burden of making decisions. Developing better software means making choices among alternatives and, better still, finding that creative synthesis that integrates the best of several approaches and thereby exceeds them all. Well-organized teams that base decision making and problem solving on consensus have the best shot at making quality decisions and building such a creative synthesis, but they need to know how to avoid certain traps common to groups. The secrets of consensus-based teamwork are worth exploring.

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it!

The ability to make decisions to be one of the most essential of basic life skills. There is no way to learn how except by doing it, which means that successful families and companies make sure there is plenty of opportunity to practice the real thing. By mid-career, the typical professional programmer has solved countless problems and along the way has probably made many thousands of decisions. Naturally, we expect professionals to become good at it. But most of these decisions will have been made individually, by the programmer on her or his own, and problem solving and decision making in groups are different animals altogether.

Risks of Mediocrity

In the early ages, much study and concern were focused on supposed defects of group problem solving and decision making, particularly the effects of the so-called risky shift and the counter-tendency of groups to pull toward a mediocre mean. In those conservative days, even democratically minded managers worried more about the risky-shift than about creeping mediocrity.

According to the research, collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently. If this model applied to programming, we would expect groups to produce software that used more exotic data structures or more unconventional algorithms or more obscure language features. However, other research on group dynamics seemed to show that groups had a leveling effect on problem solving and decision making that reduced results to a kind of lowest common denominator of individual contributions and abilities. Either way, the lone decision maker seemed to have an edge.

Collective decisions often seemed to be skewed toward more risky alternatives than would be selected by members deciding independently.

The social and organizational climate in which a group works is what really shapes the ability to perform up to potential. For best results, the corporate culture and group leadership must actively encourage and support innovation and collaboration. In a sense, some teams did perform well, meeting the real expectations of bosses and enterprise policy makers, which were based more on covering the backside than achieving results.

Leading Lightly

In consensus design and decision making, the role of the group leader is crucial, not only in establishing the overall climate for collaboration but also in the detailed way in which leadership is exercised. Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all, not just an average of their contributions, but a genuine synthesis that combines their best. When group leaders, however talented and brilliant, push their own agenda, the quality of teamwork goes down. The effect of group leadership can be as insidious as it is subtle. Even just expressing an opinion at the wrong time can bias a group and lead to a poorer outcome. Research has shown that merely having leaders delay tossing in their own ideas until after all or most group members have presented theirs will improve the group solutions. That means that a leader who merely speaks too soon is probably degrading the quality of team-work. Confident leaders, sure that they are right or know best, may cause the most difficulty.

Consensus design and decision making is at its best when the solution derives from the talents of all team members and reflects the experience, creativity, and critical thinking of all.

Techies at heart

Most project leaders and mid-level managers in software development are really techies at heart. Nearly every one of them was promoted up from programming, systems analysis, and software engineering. They got where they are by being good at software development. For many, it is hard to let go of the keyboard, letting someone else actually do the work and make the technical choices.

Most of us as managers are prone to one particular failing: a tendency to manage people as though they were modular components. It’s obvious enough where this tendency comes from. Consider the preparation we had for the task of management: We were judged to be good management material because we performed well as doers, as technicians and developers. That often involved organizing our resources into modular pieces, such as software routines, circuits, or other units of work. The modules we constructed were made to exhibit a black-box characteristic, so that their internal idiosyncrasies could be safely ignored. They were designed to be used with a standard interface.

We were judged to be good management material because we performed well as doers, as technicians and developers.

After years of reliance on these modular methods, small wonder that as newly promoted managers, we try to manage our human resources the same way. Unfortunately, it doesn’t work very well.

The Discussion Leader

We now know that one of the most important factors in achieving first-rate problem solving through consensus is having neutral leadership. The position of discussion leader is so powerful that whoever leads or facilitates meetings and discussions must be assiduously neutral about the outcome in order that the best of what the group has to offer can emerge.

Such a leader is everyone’s friend and nobody’s advocate. Such a leader draws out the contributions of all without favoring any. Such a leader helps the group to build its own technical consensus without biasing the outcome or pushing a private agenda.

Ironically, what this means is that project managers and official team leaders are probably the worst choice for leading any discussions or meetings directed at technical problem solving and decision making. They have too much at stake. In a sense, they probably also know too much. The stronger they are as leaders, the more likely they are to actually dampen the free-spirited exploration of alternatives and the building of technical consensus that lead to the best results.

It’s a popular vision that leaders are diligent, thoughtful decision makers. They gather all the relevant facts, weigh them, and come up with the logical, rational decision. But in fact, that idealized process is basically never followed, even by expert, high-pressure decision makers.

Instead, we make decisions and solve problems based on faulty memory and our emotional state at the time, ignoring crucial facts and fixating on irrelevant details because of where and when they occur or whether they are brightly colored.

Some managers take a completely hands-off approach and try to stay out of the technical problem solving altogether; however, this is not ideal for their teams, who are deprived of the manager’s experience and expertise, or for the managers, who miss out on much of the fun. The best of them will turn over meetings and discussions to a neutral facilitator, then practice staying in the background, learning how to contribute without dominating. Some may never learn how to do this, but many actually enjoy being able to be “one of the bunch” again, taking part in technical discussions on equal footing with the rest of the team.


  • Peopleware by Larry Constantine
  • Peopleware by Tom DeMarco and Tim Lister
  • Pragmatic Learning & Thinking: Refactor Your Wetware by Andy Hunt

Image Credits

  • Photo by Caleb Jones on Unsplash
  • Photo by Clem Onojeghuo on Unsplash
  • Photo by Josh Calabrese on Unsplash
  • josh-calabrese-236920-unsplash
  • Photo by Dylan Gillis on Unsplash
  • Photo by rawpixel on Unsplash