Problem, Observation, Solution

I am working with someone who has a different working style than myself. I find it interesting to watch them work. They often ask how they they can be more effective in their communication.

I gave some advice that I was also given about how I communicate. In my previous experiences as a developer I often would talk about the solutions I had in mind. This would lead to debates and arguments about the merits of my solution over others’. I see this all around me still, and my co-worker struggles at times too.

My advice is to use a pattern when communicating about ideas. Problem Observations Solution Invitation Start the conversation by stating the problem or issue at hand. Do not talk about the solution first. This will do wonders to frame the conversation. When there is debate or alternatives in step 4, we can trace back to this problem. This will help keep focus on the problem and solution being good fits.

Next, talk about observations and evidence. This is important because it provides critical context. The solution brought to the table has been born out of these observances.

Now, offer the solution. I say solution, but this can also be the tasks or proposed course of action. Everyone has enough context to understand the solution. Skipping to this step forces people to invent their own context and problem.

Last, ask what they think and shut up. Seek their input and proposals. Listen to their observations. Hear if the problem is one real to them or not.

Here’s an example:

There seems to be a problem with how much time production support is taking. I’ve noticed the number of support tickets has increased every release. Also, many of the solutions are simple fixes. I think we may want to add some automated tests so that we can catch simple mistakes beforehand. What do you think?

If you have found yourself getting stuck in debate about solutions, give this pattern a shot. It may help.