How to survive and thrive with multiple stakeholders
Each week I take the top voted question from readers and answer it (submit yours here). With 40 votes, this week’s winner was “How a manager can facilitate communication between technical and non-technical stakeholders” submitted by Grant Landram.
Any tips for how a manager can “level the communication playing field” between technical and non-technical stakeholders within project teams so the team can better communicate and “get stuff done”?
It’s fun to get a project management question. Its been awhile. It used to be these were the only questions I ever got.
The existence of multiple people who hold the stakes (meaning money, not stakes that go in the ground , nor the ones that are tasty to eat) means every major decision is more complex, not less. Even if you love all of your stakeholders the addition of each one makes progress slower, not faster.
The specific rub in this scenario is translation. If one stakeholder spoke only German and the other only Esperanto it’d be obvious you need to find one person who can speak both fluently before you’d attempt anything. But with domain differences like technical or business knowledge, we presume basic English is sufficient. It isn’t.
Good project leaders, and consultants, are versed in many domains. They can translate between the designer, the engineer, the business analyst and the executive, each of which demands a different frame of thinking. They also see how tradeoffs between domains are required for the project to succeed. Perhaps most importantly they known their limitations: sometimes they need a better translation, or translator, and will pause the proceedings until one is found.
You need four things when dealing with diverse stakeholders:
- A shared goal. It takes effort to translate. If all the stakeholders can’t see the goal they all share, they’ll defend their turf and their biases, tanking the project. At the beginning any project leader must spend time defining shared goals that everyone will benefit from achieving. Then when things get frustrating, you can remind everyone of the goals they share and why it’s worth the effort. If there is no single shared goal among stakeholders success is improbable.
- Empathy means wanting to understand what the other person is trying to say and helping them clarify it, even if it’s inconvenient. It takes empathy to admit that simply because the other person know’s less than you about writing code or closing deals, it doesn’t mean they’re any less smart or their ideas are any worse. It’s up to the leader to demonstrate the value of all the different perspectives.
- Patience is what you must offer, even to people who know less than you, about your expertise. In life, the smarter you are, the more time you will spend with people who know less than you, therefore it’s wise to develop patience. If you are a genius who is continually surprised by how stupid everyone is, how smart can you be? Often in a career you will work for people, bosses or clients, who know far less than you and how you deal with that gap will define your success or failure.
- Prevention/Recovery from communication breakdowns. Good teams prevent and recover from communication mistakes. They avoid the temptations of wishful thinking, or pretending not to notice someone else’s wishful thinking. Get in the habit of asking clarifying questions like “I think you mean X. is that right? Or did you mean Y?” It’s a godsend. As is the companion of reflection: “I think I understand. Let me explain the whole thing and you tell me if I have it right.” In a room full of good communicators you’ll hear people clarifying and reflecting often. It’s a sign everyone sees the traps and wants everyone to avoid them.
Do you wrestle with many stakes, and their holders? What say you?
Great post! I do the clarifying question thing a lot. One risk is that you come across like you are cross-examining, which people hate. So proper tone is key.
I find that empathy and patience are lacking in a lot of interactions on projects.
Lack of empathy in that many times, people assume they know what you are trying to say or explain, and they either have a preconceived idea therefore already have their mind made up on how to answer, or they keep interrupting you with what they think you are trying to say, so you have to keep re-explaining.
Patience is missing in some people (project managers) who decide it’s quicker to just do it themselves rather than wait for someone else to tackle it. While it’s nice to have it done sooner, I think this is detrimental to the project and the programmers working on the project who could gain some valuable experience by doing these tasks themselves.
Step -1. Identify all of the stakeholders. Sometimes there are stakeholders who don’t become apparent until halfway through a project
Step 0. Identify what each stakeholder’s motivation is. They are frequently divergent.
Step 1. Scott’s 1 -4
These recommendations are spot on, thank you. I would add a subset or detail to item 4 – that the project leader needs to be proactive during discussion and directly translate the jargon of each of the domains. It is not just the different ideas or concepts, but the language of the domain that can cause misunderstanding and confusion. For example, there are many words or terms that have different meanings in different contexts, and there are nicknames or even made up names that teams use. So translating these in real time as the discussion proceeds can go a long way in preventing misunderstandings.
We deal with this all the time – tech, private and public sector, across high- and low-income settings, makes for a lot of translations.
In the end, of two persons want to understand each other, they will find a way even if they don’t share language. I once found my way around mainland China trains using sequence diagrams with cartoons. If two persons don’t want to understand each other, not even being married and living together for 20 years will help them achieve it. So I’d say establish common primary goals first and then the language thing will be easier.
Sometimes in project management, like in any good crime, you need to have motive, means and opportunity. Sometimes mutual misunderstanding and assumptions about the operational envelope of each ‘stakeholder’ mar progress. E.g. Motive/Why under which conditions do you think this project would be a failure? What would make this a success?
Finding the dimensions along which each stakeholder holds opportunities and fears gives you a good frame to surface, park and/or address them.
Sometimes a good old Precision Questioning in a fireside-chat format (as opposed to a rapid-fire format) can do wonders. What-if scenarios also are a useful tool that allows people to react to imaginary A vs B realities vs collaborating on one master plan that always looks good on paper.