Stakeholder Mapping

Purpose

In the ideal developer world, the technically best architecture wins. In the real world, the winning architecture is the one that does not get blocked or defunded by an influential stakeholder at the CIO level. Stakeholder Mapping forces technology leaders to arrange the people in the organization like pieces on a radar of power. It coldly diagnoses who must be won over, who can be ignored, and who holds the decisive veto.

Context of Use

Stakeholder Mapping is mandatory before major migrations such as switching cloud providers, moving from Scrum to Kanban, or introducing GraphQL. It prevents the fatal outcome where a thirty-person development team works for six months only to be stopped by the security officer because that person was left out of the architecture discussion.

Step by Step

The most common model is the power-interest matrix:

1.Identify: List all people and roles touched by the new architecture.

2.X-axis (Interest): How strongly will this person's daily work be affected?

3.Y-axis (Power): Can this person walk into a meeting and pull the plug by controlling money, policy, or regulation?

4.Place them in four quadrants:

High power + high interest: Key players. Stay close to them and manage them actively.

High power + low interest: Keep them satisfied. Do not drown them in code detail.

Low power + high interest: Keep them informed. They often bear the consequences.

Low power + low interest: Minimal effort.

Example

A team plans to roll out a new identity and access management system. The project lead skips stakeholder mapping and starts coding immediately. After eight weeks, Legal and Compliance stops the project because the external authentication tool is not ISO-certified. A prior stakeholder map would have placed them in the keep-satisfied quadrant, which would have meant that the first meeting should have been with compliance about ISO constraints rather than with frontend developers about JSON Web Tokens.

Diagram

How Diagnosis Turns into Action

Software engineers often misread power. You may assume the enterprise architect on the fifth floor has all the influence, but the map can reveal that the senior release engineer who alone holds the SSH keys to production has much stronger real veto power in day-to-day operations. Stakeholder Mapping forces you to distinguish formal authority from effective authority.

When This Method Fits Best

Stakeholder Mapping is closely related to CATWOE but is more tactical and political in project terms because it converts power and veto authority into four direct action fields. More subtle and relational influence is better explored through Social Network Analysis.

How to Use the Diagnosis in Everyday Work

In strategy sessions, be honest about what the matrix shows. One of the hardest lessons for technical people is that the users of the software often sit in the high-interest, low-power quadrant. They suffer under the architecture but cannot stop it. Use Stakeholder Mapping to make an ethical choice as an architect and occasionally push back on key-player demands in order to protect the people who bear the cost.

First Analysis Steps

Connect stakeholder mapping to architecture documentation. If the high-power stakeholders are not represented in the sign-off for an ADR, the document is not worth the risk of implementation. Stakeholders also move over time. Someone with low interest at the beginning can become a key player the moment the migration becomes painful.

How You Recognize a Useful Diagnosis

During the last rollout of a developer-productivity platform, was the platform engineer who has to fix incidents in PagerDuty at 3 a.m. classified merely as "inform" or, more realistically, as someone to manage closely?

Sources

R. Edward Freeman — Strategic Management: A Stakeholder Approach (Pitman, 1984)

Mendelow — Power/Interest Grid (1991)

Wikipedia: Stakeholder Analysis