One of the familiar tensions in management is how you encourage or discourage people from bringing you problems. One of my clients had a favorite saying, “Don’t bring me problems. Bring me solutions.”
I could see the problems that saying caused in the organization. He prevented people from bringing him problems until the problems were enormous. He didn’t realize that his belief that he was helping people solve their own problems was the cause of these huge problems.
How could I help?
I’d only been a consultant for a couple of years. I’d been a manager for several years, and a program manager and project manager for several years before that. I could see the system. This senior manager wasn’t really my client. I was consulting to a project manager, who reported to him, but not him. His belief system was the root cause of many of the problems.
What could I do?
I tried coaching my project manager, about what to say to his boss. That had some effect, but didn’t work well. My client, the project manager, was so dejected going into the conversation that the conversation was dead before it started. I needed to talk to the manager myself.
I thought about this first. I figured I would only get one shot before I was out on my ear. I wasn’t worried about finding more consulting – but I really wanted to help this client. Everyone was suffering.
I asked for a one-on-one with the senior manager. I explained that I wanted to discuss the project, and that the project manager was fine with this meeting. I had 30 minutes.
I knew that Charlie, this senior manager cared about these things: how fast we could release so we could move to the next project and what the customers would see (customer perception). He thought those two things would affect sales and customer retention.
Charlie had put tremendous pressure on the project to cut corners to release faster. But that would change the customer perception of what people saw and how they would use the product. I wanted to change his mind and provide him other options.
“Hey Charlie, this time still good?”
“Yup, come on in. You’re our whiz-bang consultant, right?”
“Yes, you could call me that. My job is to help people think things through and see alternatives. That way they can solve problems on the next project without me.”
“Well, I like that. You’re kind of expensive.”
“Yes, I am. But I’m very good. That’s why you pay me. So, let’s talk about how I’m helping people solve problems.”
“I help people solve problems. I always tell them, ‘Don’t bring me problems. Bring me solutions.’ It works every time.” He actually laughed when he said this.
I waited until he was done laughing. I didn’t smile.
“You’re not smiling.” He started to look puzzled.
“Well, in my experience, when you say things like that, people don’t bring you small problems. They wait until they have no hope of solving the problem at all. Then, they have such a big problem, no one can solve the problem. Have you seen that?”
He narrowed his eyes.
“Let’s talk about what you want for this project. You want a great release in the next eight weeks, right? You want customers who will be reference accounts, right? I can help you with that.”
Now he looked really suspicious.
“Okay, how are you going to pull off this miracle? John, the project manager was in here the other day, crying about how this project was a disaster.”
“Well, the project is in trouble. John and I have been talking about this. We have some plans. We do need more people. We need you to make some decisions. We have some specific actions only you can take. John has specific actions only he can take.
“Charlie, John needs your support. You need to say things like, “I agree that cross-functional teams work. I agree that people need to work on just one thing at a time until they are complete. I agree that support work is separate from project work, and that we won’t ask the teams to do support work until they are done with this project.” Can you do that? Those are specific things that John needs from you. But even those won’t get the project done in time.
“Well, what will get the project done in time?” He practically growled at me.
“We need consider alternatives to the way the project has been working. I’ve suggested alternatives to the teams. They’re afraid of you right now, because they don’t know which solution you will accept.”
“AFRAID? THEY’RE AFRAID OF ME?” He was screaming by this time.
“Charlie, do you realize you’re yelling at me?” I did not tell him to calm down. I knew better than that. I gave him the data.
“Oh, sorry. No. Maybe that’s why people are afraid of me.”
I grinned at him.
“You’re not afraid of me.”
“Not a chance. You and I are too much alike.” I kept smiling. “Would you like to hear some options? I like to use the Rule of Three to generate alternatives. Is it time to bring John in?”
We discussed the options with John. Remember, this is before agile. We discussed timeboxing, short milestones with criteria, inch-pebbles, yellow-sticky scheduling, and decided to go with what is now a design-to-schedule lifecycle for the rest of the project. We also decided to move some people over from support to help with testing for a few weeks.
We didn’t release in eight weeks. It took closer to twelve weeks. But the project was a lot better after that conversation. And, after I helped the project, I gained Charlie as a coaching client, which was tons of fun.
Many managers have rules about their problem solving and how to help or not help their staff. “Don’t bring me a problem. Bring me a solution” is not helpful.
That is the topic of this month’s management myth: Myth 31: I Don’t Have to Make the Difficult Choices.
When you say, “Don’t bring me a problem. Bring me a solution” you say, “I’m not going to make the hard choices. You are.” But you’re the manager. You get paid to make the difficult choices.
Telling people the answer isn’t always right. You might have to coach people. But not making decisions isn’t right either. Exploring options might be the right thing. You have to do what is right for your situation.
Go read Myth 31: I Don’t Have to Make the Difficult Choices.
| Reference: | Do You Encourage People to Bring You Problems? from our JCG partner Johanna Rothman at the Managing Product Development blog. |
Nice article. I would hope it worked that way. But I too believe in discussing issues early, and that more communication is much better than less. Team leads/managers/etc are there to make a decision, and to back that decision up. And discussing an issue when a “superior” is almost as important as investigating the issue – the “Wall” effect. As a Tech Lead, I encourage private code reviews – it could be embarassing to highlight code issues in front of other people. And when working with a new team, some people really did appreciate that. They liked the guidance and… Read more »
Hi Nicholas, It sounds as if you are doing the right things. You are right. More communication is better than less. You are also correct about the “Wall” effect. (grin.) You may want to consider an alternative to private code reviews. One thing I did as a project manager and manager was to ask for review on any document that was “private.” (One that I could share with everyone.) I said, “I value your feedback. Please provide me feedback and review on this doc.” When people realized I was serious, and I did value the feedback, I got terrific feedback.… Read more »