Seth Dobbs (he/him): Have you encountered or use the phrase “bring me solutions, not problems”? Have you thought about what issues this approach might actually create in your organization or team? 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 organizations and teams and coaching others to become leaders themselves.

And I believe that not only can anyone develop leadership skills, but that everyone can and should develop leadership skills. I think they’re essential in 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 today involves rethinking a common motto: “don’t bring me problems, bring me solutions.”

Jameson was a well-respected manager who had been working with the same team for a few years. He didn’t like to micromanage. And in fact, he believed that the manager shouldn’t get in the way of the team’s work. If they had a problem, they were encouraged not to come to him with it unless they had a proposed solution or two in mind. He believed that his team should always focus on finding answers rather than dwelling on issues. In fact Jameson became known for his motto: bring me solutions, not problems. While this approach had some merits, it also had its drawbacks as Jameson and his team were about to discover. The company’s flagship product, a state-of-the-art software application, was experiencing a significant increase in customer complaints about slow performance and system crashes. The team members were genuinely concerned about this issue as it was affecting the company’s reputation and customer satisfaction. Feeling the pressure, the team gathered in Jameson’s office to discuss the problem. Malik, a seasoned software engineer, said “Jameson, we’ve been receiving numerous customer complaints about the software’s performance.

Our initial analysis indicates that it might be due to inadequate server capacity. We need to upgrade our servers and optimize our code to address this.” Jameson sticking to his motto, nodded and replied, “great, Malik. I appreciate your proactiveness. Go ahead and prepare a proposal for the server upgrade and let’s get started on the code optimization immediately.” Malik did as instructed and the team began implementing the server upgrade and optimizing the code.

They worked really hard, believing they were on the right track. And in fact, the software started running faster and the number of complaints decreased, and Jameson considered this a job well done. However, as time passed, the complaints began to resurface. Customers were still experiencing issues with the software and some were even canceling their subscriptions. The team was baffled; they’d addressed

what they believed was the core problem. Frustration and confusion began to permeate the office. Now one day, Emily, a junior developer, decided to dig deeper into the issue. She started talking to customers directly, trying to understand their experiences and frustrations. Emily soon discovered that the problem was more complex than any of them had initially thought. And it wasn’t just about server capacity or code optimization. And while she felt she had a pretty clear understanding of the problems involved, she was too inexperienced to solve them.

The scope was larger than anything she dealt with and she wasn’t sure how to tackle it. So, Emily gathered her findings and presented them to Jameson at the next team meeting. She explained that many customers were using outdated hardware that struggled to run the software efficiently. And additionally, the user interface wasn’t intuitive leading to confusion and frustration.

Emily concluded that while the server upgrade and code optimization had helped, they weren’t addressing the root causes of the problems. Now Jameson was visibly irritated when Emily concluded, he reminded her that he wanted solutions, not more problems and sent Emily back to her desk with that admonition.

So in the previous episode, I emphasized how important it is to grow leaders so that they can ultimately see and handle changes and challenges without your intervention. But what happens when they’re faced with something that they don’t know how to deal with, that they don’t have the experience to address? As a leader, you ultimately own the resolution of all the problems in your team. It doesn’t mean you do all the solving, but, when the team is unable to resolve an issue, you have to step in. Now I’ve worked with some folks that say they don’t like it when their team members come to them with just a problem.

I’ve heard things like, “I want to see that they’ve thought about this a bit and have some kind of solution in mind.” And one case, it seemed like the manager I was talking to actually felt that his team was being lazy if they just brought him a problem. And that aside, there’s some merit in pushing people to think, for sure. But the downside that this approach can actually suppress information. If your team member isn’t able to solve a problem, isn’t able to even think of a solution and fears being called out like Emily was, what is their incentive to raise an issue?

As I talked about in episode nine of season one, we’ll get things wrong before we get them

right. This is an important principle for enabling growth of your team, but your team won’t get to right if they’re afraid to even raise a problem in the first place. And because of that, they won’t develop the skills to handle these problems in the future if they can’t talk about them today.

Now if your team is truly empowered, they shouldn’t have to bring a solution to you unless it requires resources or something that they don’t have . Coming to you, just for permission to execute a solution they’ve thought of actually slows things down and ultimately is a command and control approach that I talked about in season one.

Seth Dobbs: So looked at this way. Jameson made a couple of mistakes. First, he seemed to be giving permission to Malik, but that’s all, he didn’t use the opportunity to actually probe and question the solution and even question Malik’s understanding of the problem. To a certain extent they’re suffering from solution

fixation as discussed in episode eight this season. And that can happen when all you center on is solutions and don’t allow discussions of problems. The second mistake that Jameson made was rejecting the information from Emily outright. Not only did that delay resolving the problem, it may have put off resolution for far too long. But worse,

emily might not have ever wanted to raise something like that again. And she didn’t learn anything. Jameson offered no information on how to approach the problem.

What if instead of getting irritated, Jameson had realized a couple important things. First that Emily had brought new information that he hadn’t previously known. And second, that as a junior developer, she was probably in over her head in trying to solve it and needed someone with more experience and expertise to help her. So instead of being upset about Emily only bringing problems, what if he saw that as an opportunity to coach her and help her develop new skills? So that she might be able to handle the next challenge herself. In that world, instead of sending her back to her desk, he allowed Emily to lead a cross-functional team under his guidance to investigate further and identify comprehensive solutions. And as Emily’s team delved deeper, they would have found that the user interface needed a complete overhaul to make it more user-friendly. They needed to develop a version of the software that was compatible with older hardware. These changes would address the real problem, customer dissatisfaction, rather than just the symptoms. And in this scenario, the team implemented the changes and over time, the software’s performance improved significantly. And customer complaints decreased rapidly.

The company’s reputation is restored in this scenario and customer satisfaction soars. And on top of that, Emily develops new skills and confidence, and the team develops more trust in Jameson. By seeing that he could face uncomfortable truths and discuss them openly, they could collectively get to a better place.

And this approach would also shift Jameson into more actively creating and cultivating new leaders.

Growth requires making mistakes sometimes, even facing the fact that you or your team doesn’t have the skills or experience to handle a challenge. Imagine taking a sprinter and putting them on a hurdle track and expecting them to just do it without any kind of coaching. The sprinter is likely going to get injured or just walk away and not even bother trying. And this is what happens with your team when you require them to only come to you with solutions. When a big enough unexpected hurdle appears, they don’t know what to do. And if they can’t come to you for help, they’re going to give up, they’re going to suppress information or hope that someone else will see this issue and solve it instead. And this means rather than forward motion, you’re actually letting problems fester. And instead of creating leaders, you’re teaching people to hunker down and not get called out.

An effective leader

doesn’t require people to come to them with solutions. If your people can resolve an issue without you, they should already be empowered to do that without you. It’s worth repeating. If your team is truly empowered, they shouldn’t be coming to you with solutions to get your permission. They should be resolving the problems without you. They should be coming to you as the leader, because they need to debate a solution.

They need to make sure the problem is worth spending energy to solve, to make sure that they actually understand even what the problem is. To get the coaching, to even know where to start. To escalate to someone that has the ability, the experience, the scope to actually help resolve it. You need to support this process by always working towards alignment. Creating a trusted space for people to bring things that they can’t resolve so that you can help them. When they do, you still don’t necessarily have to solve the problem for them.

You can make sure they’re thinking properly, see the problem correctly, help them get to right without giving them the answer, provide them principles that help guide you to the answer. But also sometimes due to urgency, you might have to solve the problem to ensure forward motion and protect against disaster. And then circle back when things are resolved and explain why you took the path you took so that they still learn. But regardless, which of these paths you end up having to take, growing leaders sometimes means giving people the space to admit they don’t have the answers so that you can coach them. And would you want anything less from your leader?

So I want you to think about, are the people you lead comfortable coming to you with their problems and seeking help? And how do you know that? And what can you do differently starting today to ensure your team is getting the coaching and growth that they need from you? Thanks so much for joining me, please subscribe and share with a friend

if you liked it. Send thoughts, comments, and questions to contact@pdlpodcast.com and we’ll address a few towards the end of the season. Join me next time, where I’ll talk about how being a team player often means speaking up, not just going with the flow.