Yesterday I finally got around to reading Derek Huether's post titled, Mitigated Speech and Project Negotiations. This post is really worth reading.
Because I'm such a big believer in socializing the project management process, how teams communicate and collaborate is something that is very interesting to me. Derek quotes Malcolm Gladwell from his book Outliers, where he defines mitigated speech as "any attempt to downplay or sugarcoat the meaning of what is being said." Because this happens all the time in project-related communications, I thought I would share some of what Derek had to say, and put my own spin on it too.
Gladwell describes the six degrees of mitigation we tend to use when suggesting a course of action during a negotiation:
- Command: "Implement this"
- Team Obligation Statement: "We need to try this"
- Team Suggestion: "Why don't we try this?"
- Query: "Do you think this would help us in this situation?"
- Preference: "Perhaps we should take a look at this as an alternative
- Hint: "I wonder if we will run into any issues by following our current process?"
Although Derek's post is addressing how mitigating language is used in negotiations, I'm going to give it a little twist by suggesting that we need to look at how mitigating language is used in everyday project communications. I hope Derek won't mind.
As project leaders, I think we should look at this from the perspective of how we interact with stakeholders and executives, as well as how we interact with our project teams. Although Derek describes being "direct" and "command" as the same type of mitigation language when negotiating, I don't look at it that way when reporting status or other everyday project communication.
I do agree that commanding stakeholders, executives, or even team members just doesn't work—but being direct is not necessarily the same thing. For example, earlier this month I wrote about how sometimes the problems that lie under the surface are the most dangerous in Icebergs, the Gulf Oil Spill, and Project Management, and how there is a natural tendency to soft pedal, downplay, or sugarcoat (mitigate) project status.
As project leaders we need to facilitate an environment where honest and straightforward conversations are expected and appreciated. If there's a big problem lurking under the surface that I don't know about, I don't want it sugarcoated—I want to hear about it. And, if I shoot the messenger every time there's a problem, I'm going to foster an environment where I never get the real story.
Same is true in my conversations with others. If I'm quick to agree with uninformed stakeholders when they give me unrealistic time-lines and then sugarcoat the bad news to my project teams—what I say will never be trusted by either—and I will eventually become irrelevant.
That's not to say that you should be disagreeable. However, smart business leaders don't want to make decisions based upon information that is inaccurate, or worse, misrepresented because someone is afraid to tell the truth.
I understand that what I'm suggesting is difficult in the real world of project management and office politics. That being said, I believe we have an obligation to encourage that type of communication among our project teams and extol the virtues and benefits of the same to our superiors and other stakeholders. Otherwise, our efforts to improve the work management process will be handicapped by inaccurate and misleading information.
What are you doing to ensure that project conversations are honest and straightforward?