Mid Coordinator: how to build a business-unit stakeholder map that cuts escalations by 80%

Stakeholder mapping at the mid level is not a list of names: it's a governance tool that, done well, cuts escalations to your senior by 80%. This guide explains how to map the sponsors, contributors and blockers of your BU with levels of influence and interest, manage expectations without wavering on your position, and intercept latent conflicts before they explode. Three tier-1 case studies (Atlassian Stakeholder Communications Plan, GitLab DRI handbook, Spotify Squad model with DACI), five anti-patterns typical of the L2, and a 12-item operational checklist to verify the map.

TL;DR

The L2-C2 cell of the career matrix in our Team Collaboration & Event Building cornerstone describes the mid event coordinator as the person who explicitly maps the sponsors, contributors and blockers of their BU with a level of influence and interest, and who handles 80% of conflicts directly with the sponsors without having to escalate to the senior. The leap from the junior (who manages stakeholders only of the direct team and engages with vendors under supervision) is significant: the mid is the single point of synthesis between conflicting needs within the BU. The proposed structure derives from three tier-1 frameworks - the 2x2 matrix of the Atlassian Stakeholder Communications Plan, the concept of the Directly Responsible Individual from the GitLab Handbook, and the DACI variant used by Spotify and formalized in its Squad Model whitepaper. The conceptual framework is the 2x2 matrix (high/low influence by high/low interest) that produces four quadrants - Manage Closely, Keep Satisfied, Keep Informed, Monitor - applied to the BU subset. What's new compared to the cornerstone is the verifier rule: the map must be validated with a peer from another BU before considering it finished. The five L2 anti-patterns are: forgetting the middle manager with informal blocking power, confusing friends with sponsors, over-classifying into the Manage Closely quadrant, under-classifying the blockers, and mapping once and forgetting to update it. If you have 2-5 years of experience and you're designing your first end-to-end BU event, start from the Operational steps section. If you already have a map but suspect you're missing something, jump to the Anti-patterns section.

When you need it / Prerequisites

This guide is written for those who have just taken on a BU event end-to-end (see L2-C1) and find themselves having to understand who really matters for the success of the initiative. The typical profile: 2-5 years of experience in marketing operations, employee experience, learning & development, HR business partner, internal communications, junior chief of staff. The event is for your own business unit, with a size of 50-300 participants, an internal audience (with possible external industry guests), and a duration of half a day or one day.

There are three operational prerequisites. The first: access to the company org chart of your BU (Workday, BambooHR, Notion People, intranet). Without this input the map is built on personal memory and you discover after three weeks that two or three important nodes are missing. The second: already having a 1-pager brief with the explicit objective of the event. Stakeholder mapping isn't done in a vacuum, it's done as a function of the objective: who matters for this event depends on what this event has to produce. The third: having visibility on the political perimeter of your BU - who is aligned, who is in latent conflict with whom, what the known functional rivalries are (e.g. the Engineering BU and the Product BU competing for primacy over the roadmap). This visibility is built over months in your company; for those who have arrived recently (<6 months) a political onboarding session with your manager is useful.

If the third prerequisite (political visibility) is missing, a good move is to postpone finalizing the map by a week to spend that time in discovery conversations with three or four key people of the BU. A 20-minute coffee with four different people - a peer, a middle manager, an old-timer of the BU, a newcomer - produces a far more reliable political snapshot than any formal document.

A note on what you do not need. You don't need a dedicated tool for stakeholder mapping (Miro, Lucidchart, Figjam): an Excel or Google Sheets file with 6 columns does 95% of the work. You don't need the 2x2 matrix drawn on a whiteboard: the matrix is a mental device, the output is the classified list. You don't need the senior's authorization to conduct discovery conversations: asking colleagues "what do you think of this event?" is your prerogative as an L2.

Conceptual framework: the 2x2 matrix applied to the BU perimeter

Atlassian's matrix (influence x interest) is the starting point, but at the L2 level it is applied to a narrower perimeter than the cornerstone. The perimeter is your BU + the cross-functional functions directly involved in the event (typically: the BU's HR business partner, the BU's IT support if necessary, the BU finance controller, and possibly legal if there are external guests with GDPR privacy concerns). Everything else - corporate IT, corporate HR, corporate communications, the executive team - typically sits in the Monitor quadrant (low interest, low influence for this event) and doesn't require detailed mapping.

The four quadrants have precise operational meanings. Manage Closely (high influence + high interest): typically the BU sponsor, your manager, the 2-3 area owners of the event (program, logistics, comms). Communication cadence: weekly 30-minute meetings during prep, daily 15-minute ones in the last two weeks. Keep Satisfied (high influence + low interest): typically the BU VP who sponsors the event but is too busy to follow it in detail, or a C-level who approved the budget and now just wants to be informed at the end of the event. Cadence: a monthly half-page brief, no operational details, focus on the main KPIs and P0 risks. Keep Informed (low influence + high interest): key event participants, the team dev lead who does a demo, an internal speaker, the HR business partner who gives a talk. Cadence: a dedicated bi-weekly newsletter with an updated calendar and materials. Monitor (low influence + low interest): everyone else. Cadence: a notification one week before the event via the BU all-hands email.

An important subtlety at the L2 level is the deliberate shift rule. Some names should be moved between quadrants relative to where they would "naturally" be classified. A typical example: a team dev lead who is key to the success of the event (he speaks, gives a demo, is the reference point for technical participants) is hierarchically a peer of the L2, not a superior - but for the specific event he should be treated as Manage Closely. Another example: a BU finance controller who hierarchically is a support function should be treated as Keep Satisfied if the event has a budget >€15k (their approval of the payment flow is a bottleneck), or as Monitor if the budget is <€5k (their authorization is a formality).

GitLab's DRI concept is one level of abstraction above the RACI. While the RACI assigns roles for tasks, the DRI assigns a single person for each important decision. For the BU event, the typical important decisions are: venue choice, keynote speaker selection, definition of the final agenda, budget allocation by area, approval of the communication messaging. For each one you identify a single DRI, and you make it explicit on the map. This scheme prevents the frequent pattern in which two or three stakeholders all feel they are the decision maker of the same thing and the decision drags on for weeks.

The DACI variant (Driver, Approver, Contributor, Informed) is particularly useful for events in companies with a flat or squad-based structure. The Driver is the one who keeps up the momentum (the L2 themselves, typically), the Approver is the one who signs off the final decision (one only, typically the BU sponsor), the Contributors are the ones who execute, the Informed are the ones to be informed afterwards. Spotify, in the famous Spotify Engineering Culture whitepaper by Henrik Kniberg, codified DACI as the standard pattern for cross-squad decisions. For the L2 in scale-up tech, DACI is typically more applicable than the classic RACI because it distinguishes who keeps the project alive from who formally approves.

A fourth framework - less cited but useful for the L2 - is Bain's RAPID (Recommend, Agree, Perform, Input, Decide). Originally published by Bain & Company in 2006 and later taken up by HBR, RAPID separates the act of recommending a decision (the L2 does the analysis and produces the recommendation), agreeing (those who must give explicit consent before the final decision, e.g. a finance controller for expenses), performing (those who execute once the decision is taken), giving input (those who should be consulted, equivalent to the RACI's Consulted), deciding (the final decision maker, one only). RAPID is heavier than DACI but more precise when there are many veto holders (a typical situation in companies with a strong compliance culture). For BU events in regulated sectors (finance, healthcare, pharma) RAPID is frequently more effective than DACI; for lightly regulated scale-up tech, DACI remains preferable.

A meta-framework consideration: none of these tools (RACI, DRI, DACI, RAPID) is "better" in absolute terms. They are different lenses on the same problem - who decides what, who is responsible for what. The mature L2 doesn't dogmatically pick one tool and apply it to everything; they pick the tool suited to the specific context. BU events under 100 participants, flat scale-up: DACI or DRI. BU events of 100-300, traditional hierarchical structure: classic RACI. BU events in regulated sectors or with many veto holders: RAPID. The ability to choose the right tool is part of the L2 maturity that the junior doesn't have yet.

Operational steps: the six steps to build an L2 map in 4 hours

The six-step sequence is calibrated to produce a solid map in 4 hours spread over 2-3 days - not in three weeks of iterations as happens to those who are new. The L2 rule is that the map must be ready by step 1 of the end-to-end framework (see L2-C1): in the first two days of prep, not halfway through.

Step 1 - Extraction from the org chart (30 minutes)

You open the BU's org chart on Workday, BambooHR, Notion People or the intranet. You list all the names within ≤2 degrees of your event sponsor - so the sponsor, their directs, and the directs of the directs. For a BU of 50-100 people, this step produces 15-25 names. For a larger BU (200+), the filter should be narrowed to the branch directly touched by the event (e.g. only Engineering if the event is a technical workshop, not the whole Product BU).

The deliverable is a spreadsheet with 4 pre-populated columns: name, role, direct manager, BU of belonging. Nothing more at this point.

A note on the digital org chart versus the mental one: for those who have arrived recently in the company (<12 months), the digital org chart is the authoritative source. For those who have been in the company for 2-3 years, the mental org chart (who really matters, who makes the real decisions, who is "dead on their feet" - formally in charge but in practice disengaged) is more accurate. For the L2 with 2-5 years of experience, the right starting point is the digital org chart enriched by 2-3 discovery conversations with long-standing colleagues. If you notice that the map extracted from the org chart contains names that have "fallen off the radar" (e.g. a team lead who has been promoted but hasn't yet had a formal handover to their successor), it should be annotated on the map with an asterisk and actively verified in the following days.

Step 2 - Cross-functional functions (30 minutes)

To the existing rows you add the relevant cross-functional functions: the BU's HR business partner, the BU's IT support (if the event requires technical resources), the BU's finance controller (always, for the budget), legal (only if there are external guests with GDPR privacy concerns), internal or corporate comms (only if the event is visible outside the BU). The operational rule: you include a cross-functional function only if it has an actual impact on the event, not by default. Including functions "just to be safe" that aren't needed produces bloated maps that can't be maintained.

At this point the map typically has 20-30 rows.

A quick checklist to decide whether to include a cross-functional function: does the function produce an output that enters the critical path of the event (e.g. the finance controller produces the payment authorization to vendors - critical path)? Does the function have formal veto power over the event (e.g. legal on GDPR for external guests - veto)? Would the exclusion produce political damage (e.g. corporate communications if the event is visible beyond the BU)? If the answer to one of the three questions is yes, the function gets included; otherwise it stays out. This checklist prevents the "I include everything to be safe" pattern and keeps the map lean and manageable.

Step 3 - 2x2 classification (60 minutes)

For each row you determine the quadrant of the 2x2 matrix (Manage Closely / Keep Satisfied / Keep Informed / Monitor). You add a fifth column to the spreadsheet with the assigned quadrant, and a sixth column "why" - a single line of rationale for why that name is in that quadrant. The "why" column is seemingly bureaucratic but makes an enormous difference: it forces the L2 to explicitly justify every choice, and it produces a defensible document when the sponsor asks "why did you put Marco as Manage Closely and not Keep Informed?".

The rule of prudence: the number of names in the Manage Closely quadrant should not exceed 8-10 for a BU event. If there are 15-20, you have over-classified (and you'll produce 15-20 weeklies to manage in parallel - impossible). The fix: you review the Manage Closely list and demote to Keep Satisfied those who are "high influence but actually low interest" - typically the C-levels who approved the budget but don't want details.

Step 4 - What each person needs (45 minutes)

You add a seventh column: what they need to know. Not what we want to tell them, but what he or she wants to receive as information. Examples: the BU sponsor wants to know weekly "we're on track" + the three active P1 risks; the dev lead who does a demo wants to know at T-4 weeks whether the technical materials are confirmed; the finance controller wants to know at T-3 weeks the spend forecast to manage the approval flow; the VP who sponsors wants to know at T-1 week the final number of participants and the list of executives attending.

This column is the single element that transforms the map from static to operational: once it's filled in, writing the communication plan (see step 6) becomes almost automatic.

Step 5 - Verification with a peer from another BU (15 minutes)

The verifier rule is what's new in the L2 compared to the L1. You bring the map to another coordinator of the same level in another BU - not to your senior, not to your manager - and you ask only two questions: "who's missing?" and "is anyone in the wrong quadrant?". 15 minutes, two questions, no debate.

Almost always the peer finds 2-3 missing names - typically people in middle management with informal blocking power but no visible title, or stakeholders from cross-functional functions that the L2 forgot because they seemed obvious. The peer has no emotional investment in your event and sees the gaps more easily. Five minutes of verification with a peer avoid two weeks of political damage.

A variant of the verifier rule for L2s who work remotely or in scale-ups where peers aren't physically close: you do the verification async via Slack/Teams DM. You send the spreadsheet and ask "Hey, can you look at this in 15 minutes and tell me who's missing / who's in the wrong quadrant? No need for exhaustiveness, just a gut check". The peer typically responds within 24 hours with 2-3 useful comments.

Step 6 - Communication plan (60 minutes)

You transform the map into an operational calendar. For each quadrant you define cadence, channel, content. Manage Closely: a 30-minute weekly in a fixed calendar slot, channel Google Meet/Zoom, content status report + risks. Keep Satisfied: a monthly half-page brief, channel email, content KPIs + top 3 risks. Keep Informed: a bi-weekly one-page newsletter, channel a dedicated Slack channel or email, content updated agenda + materials. Monitor: a notification one week before, channel the BU all-hands email.

The final deliverable is an 8-column spreadsheet - name, role, manager, BU, quadrant, "why", "what they need", "cadence+channel" - plus a shared calendar (Google Calendar) with the Manage Closely weeklies already scheduled for all 8-12 weeks of prep. This calendar is the operational signature of the L2: whoever sees it immediately understands that the coordinator is organized and reliable.

On the subtlest aspect of communication - the tone of voice per quadrant - it's worth spending a few extra lines. The tone for Manage Closely is collegial and detailed: you go into the operational details, you name P0/P1 risks frankly, you show the slips without hiding them. The person in Manage Closely knows the project is alive and expects transparency. The tone for Keep Satisfied is executive and concise: you prioritize KPIs and strategic decisions, you omit tactical details. The person in Keep Satisfied doesn't want to know that vendor X delivered the brochures late; they want to know whether the event is on track and how much it cost. The tone for Keep Informed is participatory and visual: you use images, graphical agendas, a clear calendar. The person in Keep Informed is typically a key participant (speaker, dev lead who does a demo) and needs practical context to prepare. The tone for Monitor is brief and functional: a notification of 4-5 lines at most, with the essential facts (date, time, calendar link, attendance confirmation required within X days).

An L2 practice that's worth a great deal: after writing the communication plan, you do a 15-minute simulation walk imagining the next 8 weeks from the point of view of a single Manage Closely stakeholder. What do they receive from me in week 1? In week 2? How many total messages do they receive over 8 weeks? If the number exceeds 12-15 total messages per Manage Closely stakeholder, the plan is too aggressive and will produce fatigue. If it's below 6-8, it's too sparse and the person will lose context. The sweet spot is 8-12 total messages over 8 weeks, distributed as a weekly meeting + 1-2 email updates between consecutive meetings when news emerges from one weekly to the next.

Real case: Atlassian Stakeholder Plan, GitLab DRI handbook, Spotify Squad DACI

Three case studies that cover three different vantage points on the problem: Atlassian for the classic 2x2 matrix, GitLab for the single responsible person (DRI), Spotify for the DACI variant in a flat structure.

Atlassian covers the "how to classify". GitLab tackles a different problem: how to decide who is truly accountable for decisions.

The third case study is another evolution of the concept: the DACI variant in a squad-based structure.

For those who want to dig deeper: Harvard Business Review - The Decision-Driven Organization (Marcia Blenko, Michael Mankins, Paul Rogers, 2007) is the foundational academic article on the idea of mapping decisions and responsibilities as a tool of organizational management. PMI published in PMBOK 7 (2021) a chapter dedicated to stakeholder engagement with more formal frameworks than those cited here - useful for those aiming at the CMP or PMP certification in the medium term.

Anti-patterns: the five most frequent ways to break a BU map

Templates, checklists and next steps

The cross-BU RACI-DACI template is the single most useful resource after completing the map: it transforms the map into an operational task-per-decision matrix. It's downloadable as an Excel file with two sheets (classic RACI + DACI for cross-squad decisions), pre-filled formulas, labeled sections, and includes a link to import it into playtheevent.com.

A 12-item operational checklist to verify the map before kick-off:

1. The map has 20-30 rows (no fewer, no more)
2. Every row has an explicit name, not a generic role
3. The "why" column is filled in for every row
4. No more than 8-10 names in Manage Closely
5. At least one middle manager without a prominent title is present
6. The "what they need" column is filled in
7. Cadence+channel is defined for each quadrant
8. The Manage Closely weeklies are in the calendar for all 8-12 weeks of prep
9. A review of the map with a peer from another BU has been done
10. The key decisions have a DRI or DACI Approver identified
11. A bi-weekly review is in the calendar to update the map
12. The sponsor has seen and signed off the map via email

The next step of L2-C2 growth is toward the cluster article L2-C3 on mid project & risk management (budget management +/-10%, P1 risks, operational Gantt or Kanban plan). And then toward the L3-C2 senior, which extends the map to cross-BU and introduces the management of priority conflicts between different BUs.

What I learned writing this