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.
References
- Peopleware by Larry Constantine
- Peopleware by Tom DeMarco and Tim Lister
- Pragmatic Learning & Thinking: Refactor Your Wetware by Andy Hunt