Why Yes, I am a Rocket Scientist!

Have you ever felt like you needed to be a rocket scientist to understand a topic? 

I think sometimes we get too buried in detail. We fail to see the simplicity in what we are experiencing. In doing so we end up solving the same problem over and over again. 

I recently spent several days at AirVenture 2015. (Whether or not you are an aviation enthusiast Airventure is a must for everyone’s bucket list www.airventure.org ). While meandering through the many exhibits I saw a great bumper sticker that said. “Why Yes, I am a Rocket Scientist!”   

I sometimes wonder if we try to make leadership into a rocket scientist experience. Do we create conceptual models that are complex, burdensome, and hard to comprehend? Why does that happen when most people are not rocket scientists? 

So what is the solution? We need to have some simple models that can be applied across all problems of similar nature. Yes, every situation is unique, however often it is only unique in context with the underlying principles being the same. This is especially true of leadership because the common factor in leadership is dealing with people. (See my blogs on Change Trajectory and What’s Your Perspective for examples of models.) 

One thing is inescapable. All models are flawed. Some are useful. The role of models is to take a big complex problem and reduce it down to a size that we can wrap our heads around. We give up some things in simplifying the situation to fit a model.   

For example we may have a process for conducting project management that progresses from concept, initiation, planning, execution and close out. There is an agreed upon framework defining each stage. However there are often exceptions. A project that requires the development of multiple options or contingencies may not fit into the model. Things get messy. The team begins to refer to the project as a program and redefines the model for execution. 

So was our project management model flawed? It was flawed in that it did not accommodate for more complex competing options in simultaneous development toward a common goal. However the expediency the model provides in handling most situations makes it useful.  

A model provides a common starting framework. Understanding the framework helps the team arrive at a common concept for execution. Without a common understanding the team can make modifications to the model as needed to for the situation. 

Models are most useful when they incorporate the common language of the organization. Models that require teams to redefine what they already know can lead to confusions and isolate the team from the rest of the organization. This facilitates communication in that the team can reduce the trial and error that comes with developing a shared understanding of nomenclature. This allows the team to focus on the deliverables and avoid waste.   

So next time before you get started on something new, ask yourself, what model are we going to follow? If you don’t have a model for execution is it better to spend a little time working through a common model or risk spending a lot of time having the team run off in different directions?

Joe Thompson

© 2016 Differentiating Strategies, LLC