“Get Alignment Before You Decide”
Never Says Who Needs to Be Asked.

Your team runs the website for a chain of sporting goods stores. It spends every Friday answering new requests from other teams, like a wrong price to correct or a store’s holiday hours to post. So the work it started on Monday, such as a new page where customers can book a bike repair, is still unfinished when the week ends.

You propose keeping Fridays for finishing work like that page, with no new requests that day. Your team agrees at its meeting, and your director says yes in your one-to-one. Nobody mentions anyone else who might be affected.

Two weeks later, the manager of store marketing talks to your director. Her team sends most of its requests to yours on Fridays, asking for each weekend’s sale prices to go on the website. The stores set those prices late in the week. Nobody had asked the manager how Fridays with no new requests would affect her team. Your director lets requests come in on Fridays again, and your team is back to answering them that day.

Getting your team and your director to agree first is what leaders are told to do. The advice is to get alignment before you decide, and it is good advice. People carry out decisions they agreed to. They also raise their concerns early, while a decision can still change.

The usual way to get alignment is to meet each person a decision affects, and each person with influence, before you decide. With each one, you describe what you plan to do in terms of what that person cares about.

You still have to work out who those people are and what each of them needs. Many leaders learn that over time, from social cues and everyday conversations, and the people who trust them help get things done. When no process lists those people, each leader has to guess. The guessing adds to their cognitive load, the mental effort a process or a tool could save. Nobody had listed store marketing, so you proposed keeping Fridays free of new requests without planning for its sale prices.

Leaders can also work out on paper who a decision affects, using a method called stakeholder analysis. In 1984, the management scholar R. Edward Freeman defined a stakeholder as any person or group who can affect whether an organization reaches its objectives, or who is affected when it does.

I am autistic, and I do well when people say things plainly. So before I ask people to agree to a decision, I make a stakeholder map, using Freeman’s definition to decide who goes on it. On it, I write one line for each person, saying what they need from the decision. I check each line by asking that person. I do the mapping myself, and Claude, the AI I use, helps me get through it faster.

Anyone who wants to lead can learn this method, however their mind works, without relying on social cues or charisma to win people over. With the map, I can work out who has power over a decision, what each person wants, who answers to whom and how the decision gets made. Working from a map makes leadership accessible to autistic people especially.

Before you ask anyone to agree to a decision, make your own map. List everyone who can affect the decision or whose work it would change, on your team and on other teams. Note who will support it and who will push back. Then write each person’s line in four parts:

Their role in the decision. My Decision Charter names three roles: making the call, holding the facts the decision depends on, and owning how it turns out. If they hold none of these roles, write “none.”

Who they influence. Some people have no role in a decision but can still change it through someone who has one.

What they need from the decision, in their own words once you have asked, and marked as a guess until then.

How they want to hear about it: one to one, in writing or in a meeting, and from whom.

Then decide who needs your attention first. Start with the people who can change the decision most and care most about it. Talk early, too, to the people whose work it changes most. Here are the lines for your proposal to keep Fridays free of new requests:

Your director and your lead developer are likely to support keeping Fridays free of new requests, and the manager may push back. So after you talk with your developer, you ask the manager what her team needs. Then you write a plan built on all three lines and take it to your director in your next one-to-one, with your developer’s count of Friday requests.

In the plan, Fridays stay for finishing work like the bike repair page. Store marketing sends its other requests, such as new banners for the website, earlier in the week. It sends the sale prices on Thursday afternoon, once the stores have set them, and your team puts them on the website that day.

Your lead developer can take the plan to the rest of your team, and your director can take it to the other department heads.

Your organization can make a stakeholder map part of how decisions get made, with time for leaders to ask people plainly what they need. Then a team like store marketing says what it needs before a change starts. A team like yours keeps the Fridays it planned around.

Below is a proposal that needs agreement, followed by the lines I wrote for it, one for each person it affects. First, read the proposal. List the kinds of people who can affect it or are affected by it and who are missing from my lines. Then check the role on each line against these three roles: makes the call, holds the facts the decision depends on, owns how it turns out, or none of these. Tell me where a role looks wrong, and why. Where a line is marked as a guess or leaves a part empty, write the one question I should ask that person. Do not fill in what anyone needs or whom they influence. Do not rank anyone. Put each question under the person it is for. The proposal and my lines: [paste here]