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.