Stakeholder

The problem was decisions getting overturned after they were made. Screens drawn, development finished, launch date booked — and then someone who appears for the first time says no.

The shape it takes is familiar. Three days before launch, a legal reviewer joins the check-in and says that notice copy can't be used. In the same meeting, sales says the pricing change conflicts with a large contract signed last month. Nobody on the build side ever invited either of them, and neither of them knew the work was happening. No one did anything wrong and two weeks have to be spent again. The retrospective records it as a communication problem, which is true and not useful.

The cause was the absence of a list. With nothing written down about who to invite and who to inform for this decision, whoever came to mind got invited. Whoever comes to mind is usually on the same team, which is why the people outside it who can block the work arrive last. The later they arrive, the more expensive their objection is, even when the objection is correct.

Stakeholder is the demand to build that list before the work starts. Write down who is affected by the outcome and who can stop it, and objections surface during planning rather than three days before launch.

Two steps: build the list, then split how people are involved. Build the list without splitting involvement and meetings grow to fifteen attendees.

1. Pull names with two questions. Who is affected by the outcome of this decision, and who has the power to block or change it? The first reaches down to actual users and the support staff who answer them; the second reaches up to legal, security, and whoever controls the budget. Both directions matter, and teams routinely write down only the second.
2. Write down how each person is involved. Separate the person holding the final decision, the people whose input has to be heard before deciding, and the people who only need to be told afterward. RACI, the table that splits involvement into responsible, accountable, consulted, and informed, is that work turned into a template.
3. Attach timing. Consulted people get asked during planning; informed people hear after the decision is made. Reverse the order and people who only needed to be told start offering opinions, and the decision stretches.
4. Rank by interest and influence. High influence with high interest gets frequent contact through the work; high influence with low interest gets a short confirmation at decision points only. Treat twenty-five people at the same frequency and nobody gets explained to properly, and the people who needed the most context get the least.
5. Keep the list current. Reorganizations and role changes change the list. Work from a list built six months ago and you end up seeking approval from someone who moved teams, while the person who now owns that area hears about the work from somebody else.

The line to hold here is not growing the set of decision-makers. Write twenty stakeholders and make all twenty decision-makers and nothing gets decided. Widening the list and dividing decision rights are separate acts. That's why roles exist to concentrate the decision in one place — the product owner, who has the final say on backlog priority in Scrum, is one.

Three places pull the list out and use it.

The first is the kickoff, the session for aligning on goals and roles as a project starts. Read the list together there and check for anyone missing. One name added at that table buys back two weeks later on, which is the cheapest trade available in the whole project.

The second is the sprint review, where finished work gets shown to stakeholders for feedback — so who attends comes straight off the list. Consulted people get invited; informed people get a written summary afterward instead of an hour on their calendar.

The third is when something goes badly. In escalation, the procedure for handing an unresolved problem up, who to hand it to follows the influence axis of the list. Start figuring out who to contact in the middle of an urgent problem and it costs an extra hour, which is the hour the problem uses to grow.

Goal-setting uses the same list. When setting OKRs, which split a goal from the key results that confirm it, having the teams affected by that goal on the list reduces mid-quarter collisions over priority.

"Legal was missing from the stakeholder list. Next time we'll bring them in during planning."

Locating the cause of a late objection in the list.

"Security is consulted on this one and I'm the decision-maker."

Confirming a split of involvement so the decision doesn't stall.

"They're on the informed side, so sharing the outcome is enough."

A judgment that this person doesn't need a seat where input is gathered.

At Pagedeck the list first became a document during a pricing change. The previous quarter, a change reducing free-plan storage got carried almost to launch before Sofia mentioned two customers whose proposals cited that exact allowance, and it had to be reversed. Rebuilding the change and re-briefing both customers cost two weeks.

Mia's list had eleven names, with Grace as the only decision-maker. The rest split into five consulted and five informed. On the next change, sales and legal gave input during planning, and no new objection appeared in launch week. The change shipped on the date it was first given.

The most common misreading takes stakeholder to mean senior. Describing them as people who can block a decision calls authority to mind. But half the list sits below and outside. Support staff fielding questions every day are the first to know what kind of tickets a change will produce. Actual users hold no decision rights and receive the entire outcome, which makes them the group most worth representing and the one most often left off. Work from a list of senior names only and you'll collect every approval and still watch the support queue spike after launch.

Believing more consultation is safer is the other one. Having reversed something once because of a missed person, teams move toward inviting everyone. But put twenty people in one room and wait for unanimous agreement and the decision stops. Opposing opinions produce another meeting to reconcile them, and twenty people attend that one too. What produces safety isn't headcount, it's having split how people are involved. Gather input widely and concentrate the decision in one place, and say which of the two each person is getting before the first meeting rather than after.