Are you managing your stakeholders?

A coat rack "stake holder" with various stakes and a bat and vampire looking shocked.

Code is not always the most challenging part of a project. People come out of the woodwork to ask about progress, discuss the release plan and opine on the feature and functionality. Stakeholders will keep you away from your work and the more you avoid people, the more they will distract you. When you stick your head up and provide information, you become the go-to for more information. All you want to do is write code, why is that so hard!?

Stakeholders need to be managed. But what does that mean exactly?

You are their manager.

Not in the hierarchical sense, of course. The definition of managed includes the words like influence, take charge, handle, and direct. Sounds like a manager, doesn’t it? Owning the communication with stakeholders will allow them to do their job and will give them the confidence that you and your team know how to do yours. Your team can control the story. Ceding that control is a short term benefit (i.e. you get to code) with long term issues (i.e. questions about bugs, delays, feature issues will come right back to your team through the grapevine).

Who are your stakeholders and what do I do with them?

A quick search on this topic will give you numerous acronyms, matrices, and techniques for identifying stakeholders. Take a look at them, but TL;DR:

  1. Make a list of folks in the organization interested in your project. (e.g. Business sponsors, Manager, Exec team, Vendors)
  2. Write down how you communicate with them including frequency
  3. Communicate with them step 2 and ask for feedback
  4. Incorporate feedback and finalize communication plan
  5. Do the thing

Step 5 is where every single one of the tools falls short. If you do not follow through, all the work in steps 1-4 is pointless. Sound easy? Just wait until you are a couple days/weeks away from your release date and try to keep the discipline of letting folks know the status of the project. Hold yourself and your team accountable for messaging through calendar reminders, task lists, or even an assigned team member.

Managing the message

If you have a strong product owner or project manager on your team to handle the communication, that is a plus. You may even think that all members of the team will say the same thing when asked about the project. You are wrong. The team needs to manage the message through conscious effort. Develop a cadence for aligning on a message. That cadence should take into consideration:

  1. Priority of project for business
  2. Number of days/weeks until delivery
  3. New information or change in status

Here is a scenario that plays out on a regular basis:

Engineer manager to engineer: “I heard we found some bugs, what’s going on?”

 

Engineer: “QA found some bugs, but the team is on it and we should have them fixed today.”

Meanwhile in another room…

QA manager to QA person: “What are the bugs you found? Are they showstoppers?”

 

QA person: “I can’t test the flow right now and I’ll need to retest the flow once the bugs are fixed. Might take a few days to retest.”

Meanwhile in yet another room…

Project manager to stakeholders: “We found some bugs which will require a complete retest. The release date is at risk.”

 

Stakeholders: *gasp*

Later…

Engineer manager to engineer: “I just heard the project is behind and you said things would be fixed today. What happened?”

 

Engineer: *gasp*

The fallout of this scenario will take hours to recover from, if not a few days. You are probably asking yourself how the project manager knew that there might be a delay or why the engineer was confident while QA had doubts. That is exactly what will take this hypothetical team time to piece together as well. Time that could have been spent getting the project out the door. How could this scenario be avoided?

At some point earlier that day, the engineers and QA spoke about the bugs that were found. The immediate follow-up should have been a messaging sync-up with the whole team. With the team on the same page, everyone gives the same answer, and no one is left defending their position.

But I just want to code!

Managing your stakeholders may feel political or a waste of time. That is, until you are asked why your message differs from someone else on the team. As a developer and a member of a team, it is important to identify and communicate with the folks who are impacted by your project. Once identified, the team should manage the message by staying in sync with each other.

Good communication is key to the success of any organization. For the software engineer, this means managing your stakeholders.

Leave a Reply

Your email address will not be published.