Communicating To Stakeholders
Communicating To Stakeholders
How seniors effectively communicate to stakeholders by understanding needs, classifying Power vs. Interest, and tailoring communication appropriately.
One time as a senior at a web agency, I sat down with another dev for a quick conversation to give them a few small-detail development tips.
I left that conversation happy with sharing things that I felt were useful.
The dev left the conversation feeling like I was once again micromanaging and nitpicking their work.
My good intentions didn’t matter, and it hurt. 🙁 All I wanted to do was share tips that I personally found useful. But the way I communicated made the dev feel like they sucked at their job.
You can avoid the same mistake by tailoring your communication to your stakeholders through:
Identifying who they are
Understanding their needs
Classifying them based on power and interest
What is a stakeholder?
A stakeholder is someone with an interest in, or is affected by the project you’re working on. They’re usually internal – people at your org that you work with regularly. They can also include people external to your company: customers and clients, third-party vendors, suppliers, regulatory bodies, etc.
On engineering teams, you’ll often intuitively know who your stakeholders over the course of discussing a project:
Your boss
Your team lead
The other devs on your team
The Product team
Related teams like Design, Infrastructure, Security, etc.
Good teams have documentation in place that identifies key people and their roles in a project (when the scope is big enough). These are immensely useful for both identifying stakeholders, and knowing who to turn to if you have questions or concerns.
Identifying a Stakeholder’s Needs
(I swear if I write “stackholders” one more time…)
Each stakeholder in a project has their own goals, needs, and desired outcomes for a project.
The CEO might not care about the project itself, but rather than health and growth of the company as a whole.
Your boss has significant interest in your project, in terms of both personal and team success.
Another dev on your team is mostly interested in their part of the project.
Understanding the needs and goals of a stakeholder can help you classify and tailor communication:
The CEO needs to know how the project will help with company health and growth, not what you’re doing today.
Your boss needs more regular involvement about the project’s status and your ongoing tasks.
Your coworker needs to know if they’re doing a good job achieving their development tasks.
When I gave advice to my coworker, I focused on what I wanted and not what they needed, which was to know if their work was effectively progressing our team’s goals. My small tips came across as focusing on little things that didn’t matter, regardless of their validity.
Once identified, you can classify your stakeholders to tailor communication.
Classifying Stakeholders
Using a combination of their needs and their position in your company’s project and/or org chart, stakeholders can be classified using two key characteristics: their power to influence your project, and their interest in your project’s results.
Those with significant power over a project will need to be kept satisfied.
Those with significant interest in a project will need to be kept informed.
Those with significant power and interest are effectively partners in the project. They should be kept fully engaged along the way to ensure their satisfaction and information level is high.
Those with low power and interest are minimal priority, and can be given similar efforts when it comes to communication.
Here are some examples of engineering stakeholders, their needs and classifications, and how to tailor communication for them:
The CEO: needs company-wide stability and growth. High power, low interest. They’ll want to know how the project helps achieve stability or growth. Depending on your organization’s size and structure, this will likely be handled by someone else.
The CTO: needs to reduce technical cost and complexity (also read: needs to help achieve stability and growth through technology). High power, low interest. Treated like the CEO, might not be on your radar at all.
Your boss, an engineering manager: needs effective output from their team(s). Medium-to-high power and interest. Treat them like a partner and remain engaged with them. Good ones will make it very obvious what their goals are with the projects, so you won’t need to ask or, worse, guess.
Your team’s lead, a senior+ level engineer: similar to the manager but on a more implementation level, needs effective output from the team and make the manager happy. Low-ish power, high interest. Utilize your project management tools like Jira to keep your work visible and up-to-date. Tell them about blockers early. Make it so they never have to come ask you what the current status is.
The Product owner who created the feature spec: needs to achieve their own team goals, such as increasing revenue or improving customer satisfaction. Low power, high interest. Keep them informed, especially of any changes to the feature or its timeline.
At the very least, imagine yourself in the role of the stakeholder. What actions would others do that would make you happy, make your job easier? Do those things, communicate those things, and you will be a valued asset to your team.
Is there a role not mentioned here you’d like help tailoring your communication to? Do you have a similar failure in attempting to communicate as mine? I’d love to hear your questions, anecdotes, or how your engineering career is going lately!
I apologize for missing a week of Become a Senior Engineer. I caught the flu from my daughter after it wreaked havoc on her for almost a week, my basement backed up with water after our sump pump went out, and we said goodbye to one of our pet cats.
May you and your pets remain healthy and happy! 💙
