Stakeholder management: enthusiasm gets the yes, structure keeps it

Read enough writing on stakeholders and you would think the job is charm plus a two-by-two grid. Map who has power, work the high-power skeptics, listen actively, speak the language of the business. It is not wrong. It also misses that this is two separate jobs with two separate toolkits, and most of us are only ever taught half of one.

The first job is getting people to want the thing. Not to approve it, not to stop objecting to it: to actually want it, enough to defend it when you are not in the room. The second job is making the resulting decision durable, so it survives the reorg, the new director, and the quarter where everyone forgets why it was decided. Enthusiasm produces a decision. Structure keeps it. Skip the first and you get compliant, unloved software that people quietly work around. Skip the second and you watch good decisions get re-opened until they die of attrition.

What the standard advice gets right

Mapping is worth doing once. Knowing that the quiet VP is a skeptic and the enthusiastic manager cannot approve anything will save you a quarter. Learning to state a design decision in business terms is genuinely the difference between being consulted and being informed.

But most of the genre treats the organization as weather: something you read, dress for, and endure. And it treats enthusiasm as a personality trait, as though some people are just persuasive. Both halves are more buildable than that.

Nobody argues with a thing that moves

The single biggest change I ever made to how stakeholders responded to me had nothing to do with stakeholders. I stopped presenting specifications and started bringing working prototypes.

A static spec invites interpretation, and interpretation is where the meeting goes to die. Eight people read the same flow diagram, form eight different mental models, and then argue about their models rather than the product. Put something clickable in front of them and the conversation changes register entirely: they stop theorizing and start reacting. Reactions are specific, immediate, and usually correct about the thing that is wrong.

It is also the fastest way to generate genuine excitement, because excitement is a response to seeing something work, not to being told it will. I now check technical feasibility early and prototype fast, lately with AI in the loop for the throwaway versions, precisely because a prototype ends debates that a document keeps open indefinitely.

Make people co-authors, not reviewers

On the procurement platform I ran weekly sessions with the subject-matter experts who actually did the work. Formally it was a review. In practice it was co-authorship: they shaped the semantics of the interface, which terms appeared, how a data point was represented, what context traveled with it.

That is the mechanism people miss when they talk about buy-in as though it were a communications problem. Nobody defends a design they merely reviewed. They defend the one they can point at a piece of and say that part was my idea. Every hour I spent letting operations people put their fingerprints on the vocabulary bought me an advocate in a room I would never be invited to.

Which means the useful stakeholders are the ones who reject things, and my job is to arrive with something specific enough to be rejected. Vague input produces vague output, and a stakeholder who cannot find anything to push back on has usually not understood what you showed them.

Momentum is a resource you have to keep topping up

Long platform work has a confidence problem built into its shape. The valuable parts take quarters, and enthusiasm does not survive quarters on its own. I used to treat stakeholder confidence as something you earned once at kickoff and then drew down. It is not. It decays, quietly, and you usually notice at the exact moment you need it.

So visible wins get sequenced deliberately rather than saved up. Something lands early, in front of the people who care, even when the architecturally interesting work is nowhere near done. Incremental visibility beats a big reveal every time, not because the reveal is worse but because nobody stays enthusiastic through eight months of trust me.

Small pleasures are not decoration

There is a version of enterprise design that treats delight as frivolous, on the grounds that users have no choice and the budget holder is not the user. I think that gets the economics backwards.

On a localization platform, one of the pieces people talked about most was a drag-and-drop builder for composing workflow templates. Strictly speaking a form would have done the job. But a small pleasure inside an operations tool is what gets that tool opened voluntarily, and voluntary use is the whole game when nobody can be ordered to adopt anything. Craft is not the reward for getting the serious work right. It is part of why the serious work gets used.

The moment worth designing for is the turn: the meeting where a screen everyone called complicated starts getting called obvious. That is enthusiasm arriving, and it arrives through the interface rather than through the argument.

Then make it hard to overturn

All of the above wins you a decision. None of it keeps one. A map goes stale in about three weeks, and persuasion has to be redone for every new person and every new quarter, which means it does not scale past roughly five people. On a platform serving a thousand people across four time zones, with a governance function reviewing everything, there is no version of the job where you charm your way to a coherent product.

So the second job is structural, and dull, and it is the half I was slowest to learn. On that platform every significant decision needed validation on three axes that genuinely could not be asked in the same room.

1. 01Would it survive the work weekly, with the business owners whose operations it changes.
2. 02Was it buildable as drawn a cross-domain review where design, data, and engineering reconcile three views of one feature. Most expensive surprises live in the gaps between those views.
3. 03Did it serve where the business was going quarterly, with leadership. Both a report and a negotiation, and it is a mistake to pretend otherwise.

The mechanical part matters more than the calendar. Each agenda names the decision it is asking for; the record afterward names the decision that was made, the options declined, and the reasoning, kept where the work lives rather than in a deck nobody reopens. A review that cannot conclude anything is a status update wearing a decision's clothes, and those are the first meetings I delete now.

The immediate payoff is that teams stop re-litigating: the same question stops returning every few months with a new person attached to it. The larger one took me longer to see.

Auditability buys latitude

This runs against the instinct. Designers mostly treat governance, compliance, and risk as the enemy, the function that says no slowly and late. In a procedural organization it is closer to the opposite. Anything that cannot be audited will not ship, so a process that produces its own audit trail is a process that gets to move.

Because the question the organization is really asking is not whether the work is good. It is whether anyone can defend it in a review six months from now, when whoever approved it has moved on. Answer that in advance and a surprising amount of freedom follows, including on the things designers usually have to fight for.

Change the unit of measure, not the volume

The presentations I gave leadership on that platform deliberately contained no wireframes and no flows. They covered time-to-decision, data integrity, cross-market reporting, and delivery risk. That was not simplifying for executives, which is both condescending and ineffective. It was changing what was being measured.

Show a senior stakeholder a flow and you have invited them to art-direct, because the flow is the only artifact in the room they feel qualified to have an opinion about. Show them time-to-decision and you have invited them to weigh a tradeoff, which is what they are genuinely good at and what you actually need from them. Do that for a few quarters and the perception of design shifts from interface production toward something nearer strategic enablement. I would not have predicted how much that mattered.

Name the tensions you are not going to resolve

On the localization platform, kickoff named three forces the product had to hold rather than fix: global standardization against local autonomy, automation against control, adoption against disruption. None of those has a solution, and pretending otherwise would have produced a system that split every difference and satisfied nobody.

Naming them stopped people waiting for a synthesis that was never coming, and gave every later decision a frame. The question stopped being whether a choice was right in the abstract and became which way we were leaning on autonomy this time, and why. Rooms can answer that.

The proof is what happens when nobody is made to use it

Here is why I think both halves are load-bearing rather than one being the real work. That procurement platform replaced years of personal spreadsheets and local approval chains. There was no directive requiring anyone to switch, and no formal onboarding program. Within three months about eighty percent of the early pilot markets had moved anyway, and those groups reported roughly a sixty to seventy percent drop in day-to-day spreadsheet reliance.

The structure is what got it shipped through a compliance-driven organization. But nothing in a decision log makes a buyer in another time zone abandon a spreadsheet they have trusted for six years. That happened because the thing removed pain they recognized, and because people they knew had shaped it, and because opening it was not a chore. Enthusiasm did that half.

What it costs

The structural half is slower at the start: agendas that name decisions, a log kept current, three cadences where a team previously ran one status call. Real overhead in month one, paid by you, before anyone sees the benefit. It is also unglamorous and does not look like design. Nobody has ever put a decision log in a portfolio, and I am aware I am currently writing an article about one.

The bigger risk is running any of it as bureaucracy rather than as clearing, which is the version most people have suffered through and the reason process has the reputation it does. The test I use on a ritual is whether it removes ambiguity: who decides, what was decided, what done means. If it answers none of those it is ceremony, and it should go, mine included. When it does answer them, senior teams get faster rather than slower, because they stop paying the tax of re-aligning on things that were already settled.

And none of it replaces judgment. You still have to know which room to raise a thing in, when to spend credibility and when to bank it, and when a stated objection is standing in for an unstated one. That last skill has saved me more often than any framework.

Contribution, not notification

You are going to lose some of these. A fair number you should lose, because the business knows things about cost, timing, and risk that never reach your desk. Others you will lose for reasons that are genuinely bad, and you will still have to ship the thing on Monday. Being unable to move forward after losing a call is its own kind of unprofessional, and it spends credibility you will want for the next one. Losing without withdrawing is a real skill, and I was slow to learn it.

What is worth being immovable about is not the outcome. It is the difference between a decision you contributed to and lost, and a decision you were simply told about. The first is an organization working as intended. The second means design was not in the room where the thing actually got decided, and no amount of craft applied afterward repairs that. So if you keep finding out late, the problem is not the decision. It is where you are standing relative to it, and that is the thing to go and change.

Which is why this job quietly wears so many hats, none of which appear in the description you were hired against. You end up evangelizing the product internally, and sometimes the discipline itself. You do a fair amount of managing whether or not anyone gave you reports. You negotiate. You sell, genuinely sell: the idea, the prototype, occasionally your own team's time. For years I treated all of that as the tax on doing the real work. It is closer to the opposite. It is what buys a seat at the point where the work gets decided, instead of a summary of it afterward.

Both, or neither

If I could tell a younger version of myself one thing, it would be that these are not the same skill and you cannot substitute one for the other. I spent years trying to be persuasive, which is per-person and expires. Then I overcorrected into process, which protects decisions nobody was excited about in the first place.

The structure is what outlives the meeting, the quarter, and eventually you. The enthusiasm is what makes anyone care while you are still here. Build one and the work is durable but unloved. Build the other and it is loved right up until the reorg.