Expectations vs Recommendations vs Suggestions - “Never ascribe to malice that which can be ascribed to miscommunication.”

By Duncan Anderson. To see all blogs click here.

One Sentence Summary: communication is hard, avoid some miscommunications by classifying input as an Expectation, Recommendation, Suggestion!

Definitions:

• Suggestion = take it or leave it AND no need to let the person providing the suggestion know what you decide to do

• Recommendation = take it or leave it BUT you need to let the person providing the recommendation know what you decide to do

• Expectation = cannot take it or leave it HOWEVER if you don’t agree with the expectation please say to so

+++++++++++++++

Details:

For the purpose of this blog let’s assume the following:

• 1. Parties: ‘1.1 Input Provider’ and ‘1.2 Input Receiver’

• 2. Input components = 2.1 Classification of Input * 2.2 Contents of Input

“Never ascribe to malice that which can be ascribed to miscommunication.”

• If someone doesn't do something agreed upon, it's probably not incompetence or worse, insubordination. It's likely there was a difference of understanding in what each party thought they should do. Ie miscommunication!

I find that miscommunication causes ~90% of problems. Here is one way I try to avoid miscommunication:

• If you are the ‘1.1 Input Provider’ clearly ‘2.1 Classify Input’ as an Expectation, Recommendation or Suggestion.  

• Have the all parties confirm their understanding of the ‘2.2 Contents of Input’.

2.1 Classification of Input = Expectation or Suggestion or Recommendation. Definitions:

• Suggestion =

  • A. The ‘1.2 Input Receiver’ can take it or leave it, final owner of what to do is the ‘1.2 Input Receiver’

  • B. There is no need for the ‘1.2 Input Receiver’ to notify the ‘1.1 Input Provider’ what their final decision was.

• Recommendation =

  • A. The ‘1.2 Input Receiver’ can take it or leave it, final owner of what to do is the ‘1.2 Input Receiver’

  • B. However for the ‘1.2 Input Receiver’ to needs notify the ‘1.1 Input Provider’ what their final decision was.

• Expectation =

  • A. The ‘1.2 Input Receiver’ cannot take it or leave it, final owner of what to do is the ‘1.1 Input Provider’

  • B. However if the ‘1.2 Input Receiver’ doesn’t agree with the Expectation they  should push back. No one wants ‘yes people’. Please always ‘thoughtfully disagree’.

Clear communications is not the responsibility of one party, it is the responsibility of all parties always! Leverage the -ations: Expectations, Suggestions & Recommendations

Jingle: -ations make actions accurate!

After input is provided have both parties confirm their understanding of the ‘2.2 Contents of Input’

• This is separate to ‘2.1 Classification of Input’ (aka Expectation, Recommendation or Suggestion). With a blog like this the definitions of Expectation, Recommendation and Suggestion should be clear.

• How to confirm their understanding of the ‘2.2 Contents of Input’:

  • The ‘1.1 Input Provider’ asks the ‘1.2 Input Receiver’ to confirm their understanding of the ‘2.2 Contents of Input’ by restating the ‘2.2 Contents of Input’ orthogonally.

    • Orthogonally = not in the same words that the ‘1.1 Input Provider’ used. Ie the ‘1.2 Input Receiver’ rearticulates the  ‘2.2 Contents of Input’ in their own words. To be clear the ‘1.2 Input Receiver’ is NOT allowed to repeat using the same language what was said in ‘2.2 Contents of Input’.

    • Rearticulation is remarkable. The number of times I’ve thought both parties are on the same page only to find out they aren’t through this technique is terffique ;).

  • After this the ‘1.1 Input Provider’ asks that ‘1.2 Input Receiver’ an orthogonal question (aka a Hinge Question) to double check their understanding a second time.

    • Orthogonal question = a question that can only be answered correctly IF the ‘1.2 Input Receiver’ understands the ‘2.2 Contents of Input’. Ie cannot be answered correct by repeating back what was said by the ‘1.1 Input Provider’.

    • Orthogonal is phenomenal ;)!

  • *aside: the above two actions are to check that the ‘1.2 Input Receiver’ understands the ‘2.2 Contents of Input’ from a ‘first principles’ perspective. A ‘rote learning’ perspective can be done with repeating what was said in ‘2.2 Contents of Input’.

Example time:

• Input: It is an expectation that you come back with a proposal of whether we should go on a holiday to either the north pole or the south pole.

• ‘1.2 Input Receiver’ orthogonally rearticulating input:

  • Rearticulation done well: So you do not want me to go and book a holiday to one of the two, you want to know which one I would recommend?

  • Rearticulation done poorly: I will come back with a proposal for going on a holiday to the north or south pole.

• ‘1.1 Input Provider’ asking an orthogonal question of the ‘1.2 Input Receiver’ to check understanding

  • Orthogonal question done well: why are we suggesting to do a proposal here vs skipping a proposal and jumping straight to booking the holiday?

  • Orthogonal question done poorly: what are the two destinations for the proposed holiday we should be considering?

… if you want to know what the answer to where you should go on holiday is… it’s to the North Pole as that is where Santa is silly ;)!