Looking back on the first few programs I’ve executed at Amazon, one of the critical pieces is communicating and collaborating with the right stakeholders. Picking up programs mid-way, I can’t count how many new stakeholders come out of the woodwork that was not initially identified by the original program manager, resulting in additional re-alignment effort, delaying the program. Getting this right at the start is crucial to a truly transparent and collaborative program. The second part of identifying stakeholders, is stakeholder analysis, attributing the right level of contribution and collaboration per-stakeholder.
From when the PRFAQ (and possibly BRD) is written to when you pick and execute the program in many cases can be short, at Amazon. You need to line up the artifacts, set the program tenets (charter), communication cadence (email distribution list, Slack channels, meetings), and build your workback plan. Identifying the stakeholders is a crucial yet overlooked step.
You identify individuals that have an interest or concern in your program. You start with a smaller circle and work your way organically, starting with the immediate engineers, engineering managers, product managers, program managers, contributing directly to the program. You would then note their expected interest, involvement and influence on your program outcome.
You continue to work your way organically into the outer circles of your stakeholder list, identifying leaders that are interested in the outcome of your program, as well as dependent engineering teams, that either contribute directly to your program or are directly affected by your program. Use your immediate engineering managers and dive deep into the program requirements to identify early on. Aside from engineering teams and leaders, there may be product and program managers outside of your inner circle that may have a stake in your program outcome.
I would also encourage the invitation of subject matter experts (Principal Engineers in Amazon) as great contributors to your program, even if they don’t specifically have a stake in your program.
While you may not get all of your stakeholders at first, always revisit your list and continually add as you dive deeper into your program’s technical design exercise.
The second step is categorizing your list of stakeholders into a matrix of responsible, accountable, consult, and inform, otherwise known as a RACI chart. I put this into a table that I stick in the workback plan artifact.
Putting it all together
With your list of stakeholders and their category of responsibility, also include in your table, the role of each stakeholder, team, and email/LDAP alias.
I finally create an Amazon permissions group (amazon teams) for the program, adding each stakeholder along with a note/description of the stakeholder role/responsibility. This allows me to ensure every program report and update goes to all of the stakeholders.
An added benefit of using Amazon teams is that you can synchronize the group list with a Slack channel.
Another option I consider is creating multiple permission groups for a program, grouping each permission group with a RACI group, to reduce noise and have more precise channels of communications. Either way, you can best decide the level of granularity, but managing your stakeholder list from the start puts you on path to a successful execution of your program.