loading...

Have Your Ideas Heard

recursivefaults profile image Ryan Latta ・2 min read

Every team I have worked on has some similarities. First, they are full of people who do want to do a great job. Second, they all have ideas that they think will benefit everyone. How do you have your idea heard and considered when everyone else wants the same thing?

Before I divulge a powerful communication technique, I want to put out some ground rules.

This is not about being right. Check yourself out. What will your reaction be if everyone rejects your idea? If that rejection stings then your ego is at play. A quick fix for that is to come up with a legitimate alternative to your own idea. Coming up with a real alternative removes your emotional investment in both ideas.

Learning to find legitimate alternatives is a worthwhile skill in itself.

On to the technique itself. What follows is a pattern of communication. Follow the steps, do not skip them. Think about them before you open your mouth. Practice. This isn't natural for many people.

  1. State the problem
  2. List your observations about the problem
  3. State your idea or solution
  4. End with, "What do you think?"

An example:

We keep having a ton of production support. I noticed that this past release generated a few dozen bugs. Also, that when we fixed the issues we only released a hot-fix. We should write automated tests for each of these fixes, and look at how we are testing in general. What do you think?

Why is this pattern effective? It provides critical pieces that are often missing when we only state our idea. The first two steps provide critical context. That context helps the listener understand how you arrived at your conclusion. It also helps the listener test how your solution fits the problem. Step four is an actual invitation for the listener to engage in solving the same problem.

Without this context, people will use their own perspective to test your idea. People have their own perspectives on problems and their evidence. That unique perspective will be the basis of how they judge your idea. This usually results in hearing that your idea is flawed for an often unrelated reason. That is because both of you are aiming at different targets.

There is a detail that trips some people up at step one. When you state the problem, the problem is never a lack of your solution. If your idea is to add automated tests then the problem is not that you don't have automated tests. Take a step back and try again. Either your ego has tangled you up into the solution, or you have a solution looking for a problem.

The fourth step requires that you ask, "What do you think?" This needs to be a sincere question. I can't tell you how many times my team has surprised me with their observations and how they took my idea to a new level.

It takes practice to make this a habit. Give it a shot and see if people don't start listening and giving a lot more consideration to the ideas you have.

Posted on Mar 23 by:

recursivefaults profile

Ryan Latta

@recursivefaults

I've been in software since 2009. I help software companies get the results they want and developers get the career of their dreams.

Discussion

markdown guide
 

Thanks for this piece, Ryan. Those four steps heavily resonates with me. Particularly the fourth one; it encourages the other party to contribute and generally brings a constructive atmosphere.

Oh, also:

When you state the problem, the problem is never a lack of your solution.

This is gold. Need to keep this in mind.