The Problem Statement is Not Always the Problem
I recently gave a “talk” at my local SPIN group. They wanted me to do a small version of a session I normally lead at AYE. I organized and reorganized and reorganized and finally developed what I hoped was a one-hour experiential session on coaching. I realized if we had more than 40-50 people, we would run out of time. But, I thought, who would want a session on coaching?
Well, it turned out more than 100 people did. The session scaled, but we had to keep the activities and debriefs shorter than I would prefer.
One of the insights that many people discovered was that the problem the coachee stated at first was not actually the problem. Here are some problem statements that evolved. One test manager said, “I’m working as an individual contributor on project #1 and managing project #2. I have to figure out how to make the management and testing on two projects work.” The coach asked more clarifying questions, such as “Tell me what you do as a technical contributor,” and “Tell me what you do as a manager.” After a few more questions, the coach asked, “What if you were the technical lead on project #1? Would that change what you do?”
Now the test manager has a reframe of the problem. Sure enough, “Well, if I was the technical lead, I would lead discussions about how we test, and not actually do certain types of testing. I might do some exploratory testing in pairs with other people. But I don’t see how to do that.” Now the coach and the test manager can generate more options, evaluate the ideas, and develop an action plan to see if a solution works.
That test manager wasn’t the only one to have a problem different than the original problem statement. A lead developer said, “I talk too much.” The coach and the developer had a little trouble coming up with the real problem statement (they only had six minutes!). When this happened with one of my staff back in the days I was a manager inside an organization, my developer and I reframed the problem to “I talk too much at the wrong time. For example, if I have a good idea about a design, I can’t not say it, even if it’s supposed to be someone else’s turn to talk. I interrupt my manager at times. I have opinions about everything and I don’t filter what’s in my brain enough to prevent the words from coming out of my mouth.”
Once we knew that the problem was the words went directly from the brain to the mouth without a pause or filter, we could generate options about how to impose a pause for the developer.
If you’re coaching and you want to make sure you’ve identified the problem correctly, try these steps:
- Ask for an example of the problem. Make sure you understand that example by paraphrasing it back to the other person. “So I heard you say that you have too many projects underway, 45 projects at the last count?”
- Ask for another example of the problem in a different circumstance or another day. “So each project is independent? Oh, some aren’t? How are the projects related or not?”
When I led one project manager I was coaching through the problem identification stage, she said, “I really have three buckets of projects. Each bucket has a different release date.” Now that we know she has programs (a collection of projects with a common release date), we can identify the problem as how to organize the programs, not deal with 45 independent projects.
On the other hand, a different project manager really did have 30 independent projects, of which 14 were supposed to release in the same quarter. Those 14 were “sharing” teams, and you know how much progress they were making–none. In this case, the problem was lack of project portfolio management and how to influence management to decide which project should be done first, second, third, and which projects should wait to start.
When you coach, you too may find that the first time someone explains the problem, their statement might not be the real problem. That’s okay. Coaches expect to have a period of discovery in order to provide great coaching.
Need Some Coaching?
If you have a thorny problem, you might want some help identifying the problem, its causes and potential solutions to resolve it. If so, take a look at my coaching services. I offer one-on-one coaching for those of you who have unique problems in your organization. If several of you are struggling with similar problems, I can offer group coaching to several of you at once.
I’m also starting a new offering in group coaching, starting in February, aimed at managers, project managers, and technical leads with too much to do. Since this is a new offering as a group coaching session, I’m strictly limiting the enrollment to six people. The coaching runs for four weeks. Take a look at my group coaching page for more information, or send me an email.
Assessments Clarify the Situation
If you'd like to unravel the mystery of why your projects aren't always 100% successful, or if you're stumped by your attempted transition to Agile, or if you think a group is stuck, consider an assessment. I timebox my assessments, so you receive the value of an in-depth investigation without having to wait months for the answers. You'll receive an action-based report and I'll facilitate your action planning. Call me if you're wondering about what an assessment can do for you.
Take a look at my blogs for my most recent writings:
Managing Product Development
Hiring Technical People
Thanks for reading, and please do send me your comments. I hope 2009 is a great year for you.
Johanna Rothman
(c) 2009 Johanna Rothman