The Haste Bias (Rushing into Action Without Alignment)
Erikson warns that a fast-moving leader can act before the team understands the plan. He recommends making the costs of haste visible and checking that others can carry out the next steps.
THE IDEA
Quick but Often Frightfully Wrong
Everything in a Red’s world is usually very urgent. You can figure out for yourself the risks this entails. Putting the pedal to the metal may seem like a good idea, but only when everything else, and most of all every one else, is on the same train. Normally, Reds rush ahead of the group, only to get annoyed when others can’t keep pace.
A Red needs someone who can get him to pause and realize that not everyone has grasped the situation as quickly as he has. He’ll never be able to carry out all the phases of a project on his own—even if he believes he can and probably will attempt to. He still needs to have his team with him.
You’ve probably heard the expression “quick and wrong.”
Conclusion: Give examples of instances where time was lost by being too hasty. Point out the risks involved in hurrying too much. Explain that others can’t keep up, and point out that it would be great if everyone knew what the project was about. Don’t give in. Assert that not even he can manage everything himself. Force a Red to wait for others.
Afterwards, try to discuss the event and show clearly and distinctly what was gained and how much the Red has profited by taking things a bit slower.
When to use it
When facing tight deadlines, prompt yourself to assess whether speed is truly necessary or if a brief pause could prevent errors.
In team meetings, encourage the most impatient members to first summarize the situation and ask for input before deciding the next steps.
During high-stakes projects, schedule regular checkpoints to review progress and ensure everyone is on the same page before moving forward.
As a leader, model patience by explaining your reasoning and inviting feedback before implementing changes.
FROM THEORY TO EVERYDAY LIFE
In practice
Project Launch Without Team Buy-In
A manager at a software company decides to implement a new tool without consulting the development team, believing it will save time. The team is confused about the new process, resists adoption, and the rollout fails, ultimately costing more time and resources than if the manager had involved them from the start.
Premature Product Release
An entrepreneur rushes to launch a mobile app because of competitive pressure, ignoring user testing feedback. The app receives poor reviews due to bugs and missing features, leading to a loss of early adopters and requiring a costly relaunch.
A MOMENT TO REFLECT
Put it to work.
Recall a time you rushed a decision. What were the consequences, and how might slowing down have improved the outcome?
How can you create a habit of checking alignment with key stakeholders before taking action?
What mental shortcuts or emotions tempt you to act hastily, and how can you counteract them?
CONTINUE THE CONVERSATION
Source texts
- Surrounded By Idiots (Thomas Erikson)