Seth Dobbs (he/him): Do you find yourself rushing to fix problems without stopping to ask, is this the right problem to solve? What do you think of the notion that becoming a better problem solver isn’t about solving more problems, but rather getting better at shaping them in the first place? Hi, I’m Seth Dobbs, and this is the Principle Driven Leadership Podcast where I share principles of leadership, along with examples of how to apply them to help make you be the best leader you can be.

These principles are based on my years of experience as an executive leader, in building teams and organizations, and in coaching others to become leaders themselves. I believe that not only can anyone develop leadership skills, but that everyone can and should develop leadership skills. I think they’re essential for helping you achieve your best in whatever way you might be trying to make an impact.

And that’s because leadership skills help you better influence others to effectively create durable results.

And leadership is a journey. The step we’re taking in this episode involves understanding that it sometimes can take more effort to understand a problem than to define a solution to it. But if you don’t take that time upfront, you might find that your solution actually solves very little and is creating even more problems that need to be fixed.

So years ago I had a neighbor, Joaquin, who was an operations manager. He’s a good guy. He was really excited when he was hired in at a global insurance company to be the director of facilities at their North American headquarters. It was a large campus with lots of work going on. One space or another was always either being upgraded, modernized, or being reconfigured for a new team.

So it was a great opportunity for Joaquin. He’d previously done some similar work at a much smaller organization, so this was a big step up. Now he dug in quickly, he spent time with his direct reports to get to know them and spent some time in the field where the work was being done to see how things operated and to learn more about his team.

His enthusiasm was infectious and he was welcomed by everyone he met and told how well things were going, and because of that, he felt he’d settled in quickly and was in a good groove. He soon learned though that not everything ran like clockwork. In fact, much of the work ran long and often over budget.

Unfortunately, he learned that from department heads and division leads that were waiting to get their team moved into new locations, complained that their delays were holding back their work.

Joaquin quickly realized he’d seen this kind of problem before. There were a lot of detailed plans floating around, but they didn’t have any kind of centralized reporting or information flow that he could look at to quickly provide insights into how all the work was proceeding. Now, he took pride in being a problem fixer and jumped on this rolling out a dashboard that had served him well in the past, and he’d learned to keep this kind of thing simple.

So the main thing he implemented was a dashboard with a color coded status. Project managers could then use this to fire off red alerts or other indicators that they felt were warranted so that they could get the attention and support they needed to make their project more successful. Changing the status then in this dashboard would trigger setting up a meeting with him and and other leadership to review the problem.

He was able to roll this out pretty quickly by keeping it simple and held a meeting with the managers on his team to spread the word and get everyone using it. And within a couple weeks he’d heard back that everyone had access and had received the simple training needed to use the status sheet. So the next month or two, there were still a few build outs that ran over, that weren’t marked with any kind of alert. He figured that was because most of the problems had occurred prior to implementing the dashboard, but now that he’s done this dashboard, he should be able to see changes any time. The thing is, in spite of the dashboard remaining pretty consistently optimistic in the status,

it depicted few alerts of any kind, added in few meetings, called to review problems. The problems still happened. Overruns continued and various department heads continued to complain to him, and so he was pretty frustrated when he explained this to me. He’d set up a really great and simple system.

It’s easy to use. He didn’t understand why people weren’t comfortable using it. That was a clue to me that that led me to ask a few more questions and reach the conclusion that he didn’t really understand the problem that needed to be solved. And that gets us to the enabling principle for this episode.

Shape the Problem Before the Solution. You need to first get a good handle on what a problem really is before you can go deep into resolving it. If you do a really good job in shaping the problem and driving out clarity, problem resolution is not only easier, it’s more likely that that you’re going to result with the right targeted fit.

On the other hand, if you don’t take that time, you spend more time and energy building and operating a solution that doesn’t in fact actually resolve the problem. Now, there’s many reasons you might jump to the solution. Some find it embarrassing to ask questions or to appear they don’t understand or they don’t know something.

But often one of the biggest problems here is, is the notion of instant solution gratification. As a leader, you need to fight the temptation of instant solution gratification and make sure that in your rush to resolve a problem, you’re actually resolving a real problem that needs resolution. And what’s interesting is that sometimes one single question can make a difference in shaping the problem.

To take it sort of into a different context, imagine you’re trying to get to a meeting in another city, and you know the timeframe to get there will be tight. So you ask a friend the best way to get there because they’ve made that trip many times before.

So your friend enthusiastically gives you instruction that makes you an hour late. Because their definition of best way was the scenic route that they didn’t think you should miss. One question, “how much time do you have?”, or one statement of constraint, “I need to get there in two hours,” could have completely changed the solution provided

In Joaquin’s case, he suffered from thinking he’d seen the problem before and knew the solution. The thing is he jumped to a path of doing, applying a fix that he’d used before, rather than achieving by working to understand what the actual problem was. Now, remember I’ve said in previous episodes, a problem is something that gets in the way of reaching our desired outcomes.

In Joaquin’s case, the desired outcomes were creating office spaces that enabled other teams in the organization to do their work and achieve their goals. Delays in his work prevented those outcomes from being reached or at least slowed them down and potentially could have reduced their impact. So after we chatted, he took some time to dig in and learned a lot about what was and wasn’t actually happening.

What’s interesting was that ultimately most of the delays were caused by typical problems like supply chain issues, team members being out sick and so forth. And some could have benefited from higher level management intervention, like wrong priorities and slow decision making. But the bigger cause seemed to be a lack of communication.

And it turned out his direct reports were afraid to raise issues because Joaquin’s predecessor would essentially punish people for escalating issues and making him look bad. So the lower level workers who saw the problems gave up trying to escalate to their managers because nothing ever seemed to happen, and they felt like they were at risk if they were too noisy.

This isn’t a dashboard issue, this is a cultural issue, which no dashboard by itself was going to fix. So once Joaquin realized that lack of communicating the delays had the biggest negative impact, he was able to make changes and build trust. Fortunately, one of the reasons it didn’t occur to him that this was a problem was ’cause the previous teams he’d led were very open and trusted him.

He wasn’t the type of leader that punished people. He was a supportive leader and, and tried to help people fix things and solve things. So once the team saw that in him, once he demonstrated that he was true to his word, that he wasn’t a punishing type, they started becoming more comfortable raising issues.

And ultimately this changed the dashboard approach a bit so that anyone on any team could escalate when they saw something and rather than receiving ridicule or anger, they knew that they’d be able to be heard. Equally important, the next time Joaquin ran into a problem, he took a step back to make sure he really understood what was happening and in time, this led him to see more rapid and meaningful improvements as he and his team became more effective. So this enabling principle, Shape the Problem Before the Solution, it’s designed to help you understand that problem resolution isn’t something you just do by tossing out solutions, but rather something you achieve by working to really understand what the problem is.

It’s ineffective to go down a path that doesn’t actually take you where you need to go, but that happens all too often when you just want to jump to solutions. The flip side of this, of course, doesn’t mean you should overanalyze a problem. There’s often no real perfect understanding or perfect solution to anything even mildly complex.

But do make sure that you understand enough so that when the folks you lead work to resolve the problem, they have enough clarity to do it effectively. All of us often have our favorite approaches, our favorite ways of doing things. So when you see something that seems close to a path you’ve taken before, the temptation to take the same path without taking time to learn more can be great, especially with the time pressures often involved.

And some of us like problem solving so much, we just want to dive into every single problem and try to fix it, try to resolve it. But we need to resist that urge of instant solution gratification and really take the time to understand and shape the problem before we dig into the solution. Of course you might have an approach in mind going into that, but rather than simply just diving into the approach, you should use your knowledge and your experience to ask more questions and to learn more about the underlying issues before deciding on a path forward.

So you can think of it this way, maybe in instead of taking pride in being a problem solver. Take pride in being a problem shaper by helping provide clarity on outcomes, on constraints, and on assumptions prior to resolution.

And then you’ll see your team becoming more effective. Why do you think leaders often fall into the trap of instant solution gratification? How would you coach a team member who tends to jump to solutions without understanding the underlying problem?

Joaquin discovered a cultural issue that inhibited problem solving. How can you foster an environment where your team feels comfortable raising concerns and knowing they’ll get properly addressed and prioritized? And what changes can you start making today to make that happen? Thanks so much for joining me.

Please subscribe, follow, comment, or share with a friend if you liked it. And send feedback and questions to contact@pdlpodcast.com, and I might address a few before the season’s over and join me next time where I’ll talk about how sometimes the biggest successes come from a series of small wins.