Great managers define problems well
The last few weeks I've been running strategy and planning workshops for different organizations. These workshops range from half-day to two-day affairs where senior leaders review accomplishments made over the last year, develop insights around performance and areas for improvements, and then define goals and metrics for the coming quarters.
I truly love these sessions and this type of work. As a facilitator and coach, I have the privilege of learning about really what makes these teams tick and what challenges them. For teams who I work with on a regular basis, we've built trust and transparency that we need to go deep and address core issues which hinder personal and team performance.
My key to my role as a coach is to ask questions. Sometimes my questions are designed to prompt discussion or help the team consider alternatives or possibilities. Sometimes my questions point out inconsistencies or gaps in logic or understanding. Sometimes my questions shine a light on a topic or issue that everyone in fact sees, but nobody wants to bring up.
However, the best questions I can ask are questions that clarify problems. I've found that teams can spend hours, or even days, struggling to find a solution to a problem. Only to realize late in the process that people don't have the same view of what the problem is or why it's important.
Great managers and great teams don't just come up with great solutions,they come up with a great definition of the problem before they start trying to solve it.
Great Managers Define Problems Well
Defining a problem before finding a solution is critical to success. The more complex the problem, the more critical the definition.
Albert Einstein famously once said, “If I had an hour to solve a problem I'd spend 55 minutes thinking about the problem and 5 minutes thinking about solutions.”
While his ratio might seem excessive, I would say that for complex problems, anything from 50-80% of the time should be spent in the "definition" phase of the problem-solving process. Anything less, you run the risk of missing key insights about what the problem really is or coming up with solutions that don't truly address the needs of a solution.
To define a problem well, you need to answer four key questions...
First, you need to define the problem in exact terms. Describe what the problem is in qualitative and quantitative terms. Be specific.
Don't just say "we have a problem with buggy code." Instead try, "we have performance issues with the page load times on mobile devices for six of our product pages."
The key here is to define what the problem is not as much as what it is. Is it all of them, or just some? Is it all the time, or just sometimes? Is it always that bad, or does it vary?
A great technique here is the "Five Whys" developed by Sakichi Toyoda (founder of Toyota) and popularized by Lean Manufacturing and Six Sigma. Dig further into the problem by asking why several times. Each time uncovering a new layer of insight and progressing to the root problem.
Teams who don't do this well waste a lot of time because individuals are trying to solve different problems. And argue over different paths to take because they aren't on the same page.
Second, clarify the impact of the problem. By defining the impact, you define why the problem is a problem. This will drive the data that will be collected and possible solutions developed.
Building on the example above, "as a result, users are clicking away and we're losing potential sales." Other impacts could be losing repeat customers or getting negative reviews. These could drive different questions and paths for solutions.
Third, define what success looks like. The point here is to agree on the criteria you'll use to measure success and decide that you're finished. Defining this up front clarifies the end point and helps articulate the path towards a potential solution.
For the example we've been using, this could be the load time of the pages under review. Even better would be to define which browsers, running which OS, and during what time of day. All of these could be factors in the problem, and thus should be parameters of the solution.
I'm always surprised how trying to define the solution criteria puts teams quickly back into the previous two steps. And that is the true value of this step. Defining solution criteria further articulates the problem and its impact.
Fourth, articulate the value of solving the problem. This is the step that most individuals and teams often skip. And often this results in a lot of wasted effort.
This step is basically the ROI test for the problem. It defines the potential return on your time invested in solving this problem. Ideally, this is expressed in dollars or time saved for the organization. It can also be expressed in terms of risk and uncertainty. The more quantitative the better.
Why do we bother with this step? It's because there are far more problems than there is time to solve them. We can spend every hour of every day solving problems and we'll always have more.
Successful individuals, teams, and organizations, pick the problems that have the highest return for the time invested. They know their time is a limited resource and they are really good about prioritizing the problems that have a high return. They also know how much time they should spend on a problem and do the minimum work required to hit the success criteria.
Many people make the mistake of spending time on problems that are annoying or get a lot of complaints but don't really have much impact or value in solving. While having a product page load slowly is certainly a problem, if it only affects a small number of users or it's low-margin product then the return would fairly low.
Don't focus on squeaky wheels. Focus on value creation.
Here is a simple mnemonic for the four steps: D-I-S-V.
D - definition
I - impact
S - success
V - value
Following these four steps before problem-solving will ensure that you're choosing the right problems to solve and zeroing in on exactly what needs to be done to solve them.
If you want a simple one-page sheet that walks you through these four steps, email me at disvtemplate@eckfeldt.com and I'll send one to you.
* * * * *
Bruce Eckfeldt is highly-focused, results-based performance coach. Previously an entrepreneur and a former Inc 500 CEO, he now focuses on advising startups and high-growth companies on leadership and management. He is a long-time member of the New York City Chapter of the Entrepreneurs’ Organization and a mentor for the EO Accelerators, ERA, and SBS programs. You can reach him at bruce@eckfeldt.com or visit his website at http://www.eckfeldt.com.
Want to improve your management skills? Join 52 Habits and get an email each week to help you better manage yourself, your teams, and your projects.
