Make a decision, would ya'?

Senior leaders are paid to make decisions. So, why does it seem like so many prefer not to do so?

Studies are commissioned, "tiger" teams are formed, data are collected. But the decision to do or to not do something is buried in steering committees, integrated program teams, or follow up meetings with a sub-team.

Meanwhile, valuable time and experience are lost.

Watts Humphrey, originator the Software Engineering Institute's Capability Maturity Model and a significant contributor to the concept that software development is an engineering discipline, once remarked to me that one can learn a lot more from doing than by studying.

Of the many lessons Watts' provided to me, this one found itself into my essence as an executive. Don't get me wrong. I'm not walking around all day randomly making critical decisions without thoughtful input and deliberation. But I do not wait forever, hoping that if I just have enough more information or the time is right, then I'll decide.

The key is to make decisions at the latest possible moment (Agile folks should recognize this). Another key is to leave yourself an out if the decision needs to be corrected. Let's be real here - most decisions you make are not so critical that they have to be 100% correct. In reality, you can never know if you are 100% correct anyway. Your goal is to be correct enough, learn from the execution of the decision, then make corrections.

This is not new. Nancy Wang and I wrote about this many years ago in Software Testing and Quality Assurance (Juggling Concurrent Releases). The concept of failing fast, learning from doing, and responding quickly is at the core of Agile Development, as well. With the emerging acceptance of Agile Development principles, perhaps some of this thinking will make its way into the execute suite.

Since Nancy and I wrote that article, I've had many opportunties to make a decision with less than ideal information.

During that time, I've learned another lesson : Build your team to be adaptable. You see, most teams expect their leaders to make infallable decisions.

Try these approaches with your team:

• Let them know that you don't have all the information you would like to make the decision. This is important because someone on your team actually may have more information and prevent you from doing something bad. It also helps perpare them for the fact that down the road, the decision may need to be revisited.
• Be very clear with your team that you have very intention in changing course if the consequences of the decision require it. (HINT: The consequences will). I often set a specific time for when we will revisit the decision. This has the effect of preventing the team from getting too wrapped up with making the decision "stick" and allows the team to focus on the business problem we are trying to address.
• Demonstrate concrete changes you make in response to lessons you learn once the decision is being put into place. I believe this is an action that gains tremendous credibility. It shows that you are willing to take a chance and make adjustments when presented with new information.
• Allow people on your team to fail. Ok, maytbe not fail miserably, but at least them understand that it is OK to take a course of action that doesn't turn out as hoped. The be there for them to help them make the adjustments needed to get back on track.

Perhaps most importantly, these steps begin to build your next generation of leaders. They provide a model of how to navigate uncertain times. Nobody expects a pilot to take off and blindly stay on the planned course, regardless of what reality presents.

We shouldn't act like our decisions are any more accurate and stable than this.