Slava Shestopalov

I decided to write this because human-centric design, user experience, usability, accessibility, or whatever we end up calling it later, are noble disciplines that benefit society, regardless of technology or the latest frameworks prescribing how we have to build new stuff. To keep things short, let’s call all of this design.

In 15 years of design work, mostly in B2B and enterprise, I’ve seen very few examples of design-led software creation, and in the mass-market apps we use every day, one can easily spot hundreds of dark patterns and poor design choices. It’s a paradox: the one thing that puts people at the center has so little power in most companies. All I want as a human is for technology to serve humans, okay? So to help make the world better, not worse, design needs real influence. That’s why I want to talk about the nature of power in organizations, what makes some jobs strong and others weak, and how to make an impact anyway.

Just like at school, they teach us about amoebas but not taxes, designers learn a million things, really good things, but almost nobody tells us:

• what design influence is based on;
• how to build influence and trade influence like currency;
• and finally—what real, systemic influence looks like, as opposed to winning a single argument in that meeting with a pesky head of product.

What’s inside this article:

---

Chapter I. Why a senior designer loses to a junior manager

1.1. The bases of power

If we were peasants in the Middle Ages, we’d know that power comes from the king, and he got it from God Himself. But where does power in a modern organization come from? Back in 1959, social psychologists John French and Bertram Raven identified five sources of power: coercive, reward, legitimate, referent, and expert. A few years later, Raven added a sixth: informational power. To be fair, the model has its critics who questioned how it’s been measured, but decades later, it’s still the go-to map of power at work.

1. Coercive power (“I can fire or demote you”)—works only under surveillance, meaning that the person using the power has to keep watching for it to work.
   • Managers have it by default.
   • A designer can’t get it and shouldn’t even try.
2. Reward power (“I can promote you or give you a bonus”)—works only under surveillance.
   • Managers have it by default.
   • A designer can get it indirectly by making others look good.
3. Legitimate power (“My position says I’m the boss here”).
   • Managers have it by default.
   • A designer can only get it through decision rights, for example, by becoming the official approver for how shipped features look and feel.
4. Referent power (“People admire me and want to be on my side”).
   • Anyone can have it if people respect and like them enough.
   • A designer can definitely build it over time.
5. Expert power (“I can do what others can’t, and what they need”).
   • Anyone can have certain skills.
   • A designer can do discovery, ideation, prototyping, testing, and so on.
6. Informational power (“I control information that persuades people or that they need”).
   • Anyone can hold useful information.
   • A designer has research evidence, user data, and interface patterns.

As you can see, a designer, even a senior one, has neither of the two powers that come with a manager’s title, the stick and the carrot. Designers can gain others, but everyone else can too, so it becomes a competition over who ends up with more influence. And even then, there’s a catch: your expert power only works if the other side believes you have superior insight; being right privately is worth nothing. Informational power, on the other hand, persuades through content, so it keeps working when you’re not in the room. No wonder every design textbook keeps telling you to gather user evidence.

Now, let’s look at how French and Raven’s bases of power play out in modern organizations. They never wrote about digital tech companies, of course, but their model fits pretty well.

1. Headcount ratios.
   When designers are outnumbered by engineers and product managers, which is often the case, they sit in fewer forums and miss early decisions. It means the legitimate and informational power are not on their side. Bigger functions also come with bigger titles. If your engineering org is 300 people and design is only 15, whoever runs engineering will naturally be at least a vice president, while design gets a head of design at best.

2. Organizational maturity.
   Nielsen Norman Group’s UX Maturity Model runs from absent to user-driven across strategy, culture, process, and outcomes. At the lower stages, design is seen as a service desk, no matter how senior anyone is or how big the team gets.

3. Design as a downstream function.
   When a product manager owns “what” and engineering owns “how”, design gets squeezed into “what it looks like.” Peter Merholz’s essay “How design succeeded its way into… irrelevance” explains how in-house design won headcount over the recent decades but lost strategic weight by focusing on delivery velocity instead of real decision impact.

4. Design looks like opinion.
   Design judgment is easy to dismiss as subjective, so in a disagreement it loses to whoever has legitimate power—in simple words, a higher title. The fix is to turn judgment into solid evidence that speaks for you, even when you’re not in the room. And I’ll repeat it: no wonder every design textbook keeps telling you to gather user evidence.

1.2. The design moat is silting up

Jurisdictional disputes

In medieval times, moats, often filled with water, protected castles from invaders. The design moat is what has been protecting designers from other people’s opinions and taking over design work. Andrew Abbott’s book “The System of Professions” (1988) is the standard sociological account of how professions defend their territory. It also helps understand why once-respectable medieval professions like fletchers (arrow makers) and flatulists (entertainers farting in a musical way) have all but disappeared, while the design of digital products hasn’t (yet).

Abbott’s central idea is that professions evolve in a contest rather than developing one by one. They compete for the same problems, so when one profession gains or loses territory, its neighbors move too. The history of professions is a chain of what Abbott calls jurisdictional disputes:

• 14th–18th century: physicians vs. barber-surgeons vs. apothecaries over the sick body;
• late 19th–early 20th century: pastors vs. neurologists vs. psychiatrists over “personal problems”;
• mid-20th century: accountants vs. lawyers over tax;
• 1980s–1990s: typesetters vs. graphic designers over the printed page;
• 2010s–now: therapists vs. wellness influencers over the same “personal problems,” all over again;
• 2020s: designers vs. product managers vs. engineers (and AI tools) over the user experience.

But what exactly is this jurisdiction that professions are fighting over? It’s the link between a profession and its work. In other words, it’s what makes people who call themselves designers the ones expected to solve a certain set of problems. Abbott adds that a jurisdiction gets claimed in three arenas:

1. Legal arena.
   It covers state licensing and protected titles, like those of doctors and lawyers. It’s the strongest arena and the slowest to change. Design has almost no legal jurisdiction. Anyone in the EU and beyond can call themselves a web designer, a UX designer, or a product designer, while, for instance, “architect” is a protected title that requires registration. There are a few pockets where the law reaches design work, but none of them protect designers. The European Accessibility Act (2025) makes accessible digital products a legal requirement for many companies. But it requires the outcome, not a designer, so an engineer with a checklist can satisfy it. Medical devices are another example: they require formal usability engineering under IEC 62366, but again, the law mandates the work without saying which profession should do it.

2. Public opinion arena.
   This reflects what the public generally believes a profession is for, and oh boy, design has a problem. Ask anyone outside the tech industry what a designer does, and you’ll hear “makes things pretty” or “makes the logo.” People do say “usability” or “UX” when an app annoys them, but they mean a quality of the product. The public cares about the outcome, not about who delivers it. Inside companies, it’s not much better: maturity surveys—from McKinsey’s 2018 “The Business Value of Design” to a 2024 survey by Ornamo, the Finnish design association—keep finding that companies see design as a support function. Design had its best moment in the 2010s, when “design thinking” was everywhere and every company wanted to be the next Apple. But that peak came with a cost: design thinking turned into a workshop format anyone could run in a day, which made design look easy to borrow. Today, the dominant story is that AI lets anyone design. Just look at how prompt-to-prototype tools are marketed directly to product managers and founders. That story doesn’t have to be true to do damage.

3. Workplace arena.
   This arena describes the real state of things: who does the work day to day. It’s the messiest aspect, because boundaries in tech companies have always been blurry, and non-designers pick up the work simply by doing it. Product managers sketch wireframes, run user interviews, and write UX copy. Engineers assemble interfaces straight from design system components. And now AI tools generate screens and flows on demand. The irony is that designers built many of these tools themselves: design systems, component libraries, and research playbooks were meant to scale design, but they also codified it. And in Abbott’s terms, codified work is routine work, which is the first to be taken over.

At its core, design aims to shape things with intention so they help people and improve their quality of life, which is exactly why I find it ironic that the moat protecting designers is so fragile. Naturally, I wanted to figure out why. How come our moat isn’t moating? According to Abbott, every profession works through the same three acts: diagnosis, inference, and treatment. Below is what they look like in design. I’ll use examples from safety management software, which is a big deal for chemical plants, oil refineries, and mining companies:

1. Diagnosis—classifying the problem.
   Low adoption of our safety incident reporting tool is connected with low trust. Field workers see reporting as bureaucracy that leads to blame, and prefer to close their eyes to issues that feel insignificant.
2. Inference—reasoning from the diagnosis to an action.
   If reporting feels punitive and slow, polishing the form won’t change behavior. We need to separate quick capture from formal investigation and show people what happens after they report.
3. Treatment—producing the fix.
   A 30-second mobile capture flow, an anonymous option, and feedback that closes the loop with the reporter. Hmm, or maybe something more contemporary? Voice reporting in the worker’s native language, with AI turning a 20-second voice note into a structured report, plus a live hazard map on the site’s digital twin that shows reporters what changed because of their report. No, wait, even better! Gas detectors and proximity sensors flag likely near misses automatically, so the worker only has to confirm a pre-filled report; an AI agent handles the formal investigation, and the site’s digital twin shows every report as a pin that updates when the hazard is fixed. Perfect.

For designers, treatment is the most exposed act. Once it becomes routine (assembled from prefab building blocks, a.k.a. the design system) or tool-driven (generated by AI), outsiders take it over. Design defended itself mostly through treatment: wireframes, flows, and prototypes were hard to make, and usually only designers had software licenses, so making them looked like expertise. AI prototyping didn’t break the moat so much as reveal that it was never defensible in the first place.

Economic moats

Digging further into Abbott’s ideas, I stumbled on another kind of moat, the economic one. The idea comes from investing. Over decades of shareholder letters and talks, American investor Warren Buffett popularized the “economic moat” concept: a durable advantage that stops competitors from taking a company’s profits. In 2002, the investment research firm Morningstar turned it into a formal rating based on five sources. But the most modern version I’ll use in the further explanation was polished in Hamilton Helmer’s 2016 book “7 Powers: The Foundations of Business Strategy”:

1. Cornered resource—exclusive access to something valuable.
2. Switching costs—leaving is expensive for the customer.
3. Process power—hard-to-copy ways of working.
4. Network economies—more value as more people use it.
5. Branding—trust that makes people pay more.
6. Scale economies—cost per unit falls with volume.
7. Counter-positioning—when you do something better in a way your rival won’t copy, because copying you would hurt their own business.

For design, the logic of economic moats needs some translation. In our case, the “market” is the organization’s decision-making: what a company chooses to explore and to build and where it steers its products and services. The “customers” are product leaders and business owners. The “new entrants” are non-designers equipped with various tools, and the “substitute” is automation, like AI agents that skip the traditional design process. I’ll illustrate the following with the safety industry again, which I’ve learned too well in recent years.

Cornered resource

In B2B, users don’t come cheap: they sit behind your company’s account managers and customers’ security policies. Designers who hold a research panel, say 40 safety managers and shift supervisors across a dozen customer accounts with signed research agreements, own something a product manager can’t spin up in an afternoon. Add a repository of hundreds of interviews, testing sessions, and site visits, searchable by industry and role—and you hold evidence nobody else in the company has.

The moat holds only if the panel stays active, the repository gets cited in roadmap decisions, and, most importantly, designers can contact customers without going through sales each time. Once access needs someone else’s approval, the resource is no longer yours.

Switching costs

In the designers’ world, this is when design rules are deeply embedded in where the actual work happens. Picture this: the constitution file that every AI coding agent reads before generating code includes your accessibility and interaction rules. The design system’s tokens and components are what engineering builds against by default. No spec moves to development without passing a design review gate. Remove designers from this setup, and inconsistencies will pile up, so someone will need to rebuild the whole pipeline.

Such a moat is strong once all of this is embedded. A design system nobody is required to use or review gates that can be skipped “just this time” creates no switching costs. Another catch: the rules only stay yours while they need maintaining; if they become stable enough, the moat silts up.

Process power

Process power is how your team turns raw customer signals into decisions—better than anyone else in the company. For example, the team recruits users and arranges consent in days. Every interview and site visit gets tagged within 48 hours using a shared taxonomy. Synthesis happens right after each study, not months later. The resulting insights then flow straight into specs as acceptance criteria. Helmer’s classic example is Toyota’s production system. Competitors toured the factories and read the books, and still couldn’t copy it, because the real advantage was in worker habits and judgment built up over years. The same goes here: a non-designer can buy research tools, but not the team’s sense of what counts as a real insight.

This moat holds only if the process is measurable, for example, the time from a customer signal to a spec change. AI tools are already commoditizing transcription, tagging, and first-pass clustering. What stays defensible is the judgment layer, which is Abbott’s “diagnosis” stage.

Network economies

This means the shared system gets more valuable with every team that uses it and contributes to it. For example, a portfolio of 15 product teams draws on one evidence base and one design system. When one team discovers that shift supervisors wear gloves and can’t use small touch targets on tablets, that finding immediately shapes the mobile flows of three apps. When another team builds an offline mode pattern, ten teams reuse it instead of building their own. As a result, going rogue becomes expensive, as it means losing access to findings and components one could never produce alone.

The moat only works if other teams contribute. If designers are the only ones feeding the system, it’s a service instead of a network.

Branding

Helmer defines it as attributing higher value to an objectively identical offering. For a designer, it’s the trust that makes people value your recommendation more than someone else’s. For example, design predicted that separating quick incident capture from investigation would lift incident reporting, and then indeed, the pilot showed tripling in reports within a quarter. Keep a decision log of calls and their outcomes, and after a few of these, leaders stop asking for extra proof and start inviting design into early planning.

This moat is slow to build, yet quick to lose. One high-profile wrong call, like a redesign that drops adoption, can undo years of credit. Brands also tend to belong to people rather than functions, so when a respected head of design leaves, much of the trust leaves with them.

Scale economies

The cost of each unit of design work falls as more of the company uses it. For example, one study with 30 maintenance planners informs six products at once, so the cost per team is a sixth of running separate studies. A design pattern, designed and tested once, serves the whole portfolio instead of being reinvented by every team.

This moat is weak and tricky for designers. Scale benefits the company, but it tends to invite further cost-cutting. If design’s value is “we’re cheaper per team,” the obvious question is whether an even smaller team, an offshore team, or an automated tool could be cheaper still. Worse, competing on efficiency is exactly the trap Peter Merholz warns about: proving design’s worth through speed and output, and mistaking that for influence.

Counter-positioning

This one means adopting a model your rivals could copy but won’t, because copying it would hurt their own position. It took me the longest to grasp this one and apply it to design:

1. For example, design makes all research freely available to anyone in the company. People whose influence rests on controlling information can’t open up the same way without giving away their informational power.
2. Or the design team commits to removing features and simplifying workflows. Product teams are usually rewarded for adding features, and B2B sales often sells software per feature. Neither can champion removal without harming its own metrics.
3. Or, while AI tools compete on how many variations they can generate per minute, designers focus on delivering one option tested with real users in real conditions. AI tool vendors can’t pitch “fewer options.”

But all of these are tricky: they may bring a quick win, yet they can also damage designers’ already shaky power. To work, counter-positioning has to target the competitors you actually care about; it shouldn’t drain another moat; and it shouldn’t be easy to copy.

1. The first example fails. In 2026, people who hoard information aren’t really design’s competitors for jurisdiction. The real rivals are product managers with AI tools and AI vendors. Open evidence actually helps them.
2. The weakness of the feature subtraction move is that it’s easy to copy: if leadership starts rewarding simplicity, product managers will adopt it overnight.
3. One tested option has the right direction, but is easy to copy as well. A product manager with good customer access could do the same. It also depends on your branding, since less stuff delivered slower needs a solid track record to be accepted.

So, is it hopeless? Not quite. Look at which moats actually hold and which ones don’t. The weak ones are scale and counter-positioning; they’re focused on what designers produce: cheaper, faster, fewer, simpler. Anyone with the right incentives or the right tool can copy that. The strong ones—cornered resources, switching costs, and process power—are places where design sits:

• in the customer access nobody else has;
• in the rules every agent and engineer builds against;
• and in the judgment that turns raw signals into decisions.

Design in the company’s value chain

After professional and economic moats, I thought I had the full picture. Then I found one more perspective, and it’s essential for understanding how the value of design flows from an individual designer all the way to the company’s bottom line. Or does it? This is where American economist Michael Porter comes in. In his 1985 book “Competitive Advantage: Creating and Sustaining Superior Performance,” Porter introduced the value chain. He divides a company’s activities into two types:

• Primary activities directly create and deliver the product or service.
• Support activities only make the primary ones more effective or efficient.

Design falls into the support category, usually alongside technology development, process engineering, IT, and analytics, so companies often treat it as overhead rather than a source of value. Since 1985, MBA-trained managers have been using this as a default mental model. But Porter built his model around industrial-age factories, where materials move through a fixed sequence of steps. Is there anything that fits software better? Yes, but you won’t like all of it.

In 1998, Charles Stabell and Øystein Fjeldstad of the Norwegian School of Management argued that the chain is only one of three ways companies create value.

1. A value chain transforms inputs into products step by step, like a car factory.
   • Customers pay for a finished product.
   • Growth is driven by volume, scale, and efficiency.
   • Leadership looks at cost per unit and release throughput.
   • Core roles are in operations and sales.
2. A value shop solves specific problems for clients, like a hospital or an IT consultancy.
   • Customers pay for a solved problem.
   • Growth is driven by reputation and expertise.
   • Leadership looks at problems solved, expert utilization, and outcomes.
   • Core roles are experts who diagnose and solve—for instance, designers.
     (When I worked at a tech consultancy, designers sitting on the bench without a project were the first to be let go, but the moment a client was paying, they were the most revered resource in the company.)
3. A value network connects people who need each other, like a bank, a telecom, or a software platform.
   • Customers pay for access to others or to a shared service.
   • Growth is driven by more users and connections.
   • Leadership looks at active users, transactions, and network size.
   • Core roles are in platform operations, growth, and partnerships.

Software companies are value shops and networks, but many of them still manage themselves with value-chain thinking. Design is a primary activity in a value shop, yet gets budgeted as support if the mental model hasn’t been updated since the industrialization era.

I’ve worked at chain companies dressed up in shop language, and maybe that’s exactly what pushed me to research this article. So I know first-hand what it feels like when everyone talks about solutions and outcomes, but what actually counts is scale and sales processes. Look at the financial reports of such companies, and you’ll often see margin improvements credited to a better revenue structure and efficiency programs. Design doesn’t show up there at all, or at best it’s buried somewhere in research and development costs.

So if you’re on an in-house team at a product company, chances are it runs on value-chain logic, despite all the talk about customer centricity and innovation. A quick test: look at what your leadership celebrates in town halls and shareholder reports. If the slides are about release counts, cost savings, and quarterly bookings, you’re in a chain. And in a chain, design is a cost to optimize.

Alright, if so many software companies should, by their own logic, be shops or networks, why the hell are they still running like factories? Unfortunately, I found more than one reason:

Design doesn’t run the show

In “The Transformation of Corporate Control” (1990), American sociologist Neil Fligstein showed that every era has its own worldview for running large firms. In his later work, he described the current one, the shareholder value era, which began about 40 years ago. So guess which department solves this era’s defining problem? Finance. (Ah, so that’s why, as a design manager, I had the least visibility into what they do and waited the longest for a meeting with them!) Finance speaks the language of cost and margin, so anything with a slow, diffuse payoff, like design, ranks low. “How much money has design brought in Q4, huh?” See? This is impossible to answer.

Wait a minute, what about Apple under Steve Jobs? Product ran the show, so it’s possible! Unfortunately, that anomaly was tied to a personality. Jobs was one of those product-obsessed leaders who elevated design (just like Erwin Braun, who gave Dieter Rams free rein at Braun, or Airbnb’s designer founders, Brian Chesky and Joe Gebbia). However, Jobs’s successor, Tim Cook, came from operations, and Jony Ive, the company’s design chief, left in 2019. Once the personality was gone, the system took over.

Accounting can’t see what design builds

Under most accounting rules, intangibles like design and research are expensed rather than treated as an investment. In “The End of Accounting” (2016), Baruch Lev and Feng Gu argue that this is why financial statements have lost relevance for companies whose value is mostly intangible, like biotech firms, software companies, and digital platforms. Yet most tech companies still run on those statements, so design work keeps showing up only as a cost. The value it creates—such as fewer “how do I” calls from users or more license renewals because people actually love the product—shows up somewhere else, disconnected from design, or nowhere at all.

As a result, design rarely owns a number. Sales owns revenue. Engineering owns delivery. And design… well, design’s outcomes are shared with product, engineering, and marketing, so it can’t make a financial claim on budget or seniority. McKinsey found that only a minority of companies track design metrics with the same rigor they apply to revenue and costs.

Mediocre design doesn’t move the needle

McKinsey’s 2018 study of 300 listed companies found that top-quartile design performers grew revenue 32 percentage points faster and shareholder returns 56 points faster than their industry peers over five years. What about the other three-fourths of firms they surveyed? Among them, the differences in revenue growth and shareholder returns were negligible. In other words, companies with poor design and companies with mediocre design end up in roughly the same bucket. Only going all the way to excellence pays off, which requires top management to embrace design early. For a finance-led company, a big bet with uncertain, delayed, hard-to-attribute returns (yes, I’m looking at you, design) is an easy “no,” so designers get stuck in mediocrity. Unless, of course, one of those product-obsessed leaders shows up and elevates design against the system, but you cannot count on miracles.

Power theories in a nutshell

1. A manager’s title has the built-in stick and carrot, while ordinary designers have to earn every bit of influence themselves.
2. The best power you can realistically grab is decision rights, so stop asking for a seat at the table and ask for a signature instead, like being the official approver of how shipped features look and work.
3. Invest in powers that work without you, because the meetings that decide your work are often the ones you’re “too junior” to be invited to.
4. Make evidence your main currency, because once people are convinced by it, they stop caring about the title of the person who brought it—or the lack of one.
5. Outnumbered? Don’t start by begging for headcount. Get into the rooms where decisions start, help shape the strategy, and suddenly you’ll stop begging for more designers and start getting asked how many you need.
6. Check your company’s maturity stage before picking tactics, and resist the urge to prove design’s worth through speed. Shipping faster, cheaper, or just more is how design has always lost the argument.

---

If you like what you are reading, please consider subscribing:

Chapter II. How to influence in the power imbalance

2.1. Choose a game to play

The world is unfair, and good work doesn’t sell itself. You’ve probably seen a similar line on social media or in those catchy videos with dramatic music and a mic drop ending. It sounds like one more mantra from a hustle bro selling a bullshit course, which is exactly why nobody takes it seriously. But it’s not just a nice slogan. Jeffrey Pfeffer, a professor of organizational behavior at Stanford, has spent decades researching how power works in organizations and has written several books about this.

Pfeffer gives plenty of concrete advice on everyday influencing, but I value his ideas for something the mindset shift they demand, without which none of the advice in this chapter will work.

1. Influence is part of your job.
   In his 1992 book “Managing with Power,” Pfeffer argues that a decision, by itself, changes nothing. To make it more vivid, remember that detailed design guideline you carefully wrote and shared with the team, which nobody opened again. It’s tempting to see that as the team’s problem: “Ugh, nobody here respects design. I spent two weeks on this, and they didn’t even open it. Engineers only care about tickets, product managers only care about deadlines, and I’m always the last to know anything.” But really, the designer’s job wasn’t finished. The real influence means overcoming resistance so people do things they otherwise wouldn’t. Yet designers often treat influence as “office politics” they unfortunately have to do on the side, believing that in a “better” team, they could just focus on designing. In Pfeffer’s terms, an unread guideline is a decision that was never really made.

2. Nobody’s coming to discover you.
   This one comes from Pfeffer’s 2010 book “Power: Why Some People Have It—and Others Don’t.” He says one of the biggest obstacles to gaining power and moving up in a company is believing the world is fair, so good work will eventually get noticed and rewarded. Designers tend to believe that if a solution is solid, backed by research, tested in real conditions, and reusable across the product, recognition will follow. But there’s no guarantee it will. We need to promote our ideas and build alliances, even if self-promotion feels uncomfortable.

3. Power is a tool.
   In his 2022 book “7 Rules of Power,” Pfeffer tackles the reason many people avoid power in the first place: it feels dirty. He insists that power is a tool that can be used for good or for evil, and blaming the tool just because some people do evil stuff with it makes little sense. Many of us, designers, chose this profession because we care about people and enjoy creating, and power-seeking feels like the opposite of that. But why do we want the cherished “seat at the table” in the first place? To stop dark patterns, to make products accessible, to make technology serve humans—every one of those needs power to happen.

So Pfeffer gives us reasons to stop avoiding power. But he writes about organizations in general, while designers deal with a very specific version of the problem—I’d even dare to say we play this game on a harder level. This is Peter Merholz’s territory. His take comes from two places: years of leading design teams himself and conversations with chief design officers on his podcast. He noticed that most of those leaders talked less about design itself and more about changing their organizations, so he concluded: design leadership is change management.

Peter Merholz expanded on the topic in a 2023 “Ask me anything” session hosted by Boye & Company, a European community for digital and design leaders. And here are his main points from that session and earlier essays:

• Distance from the top matters more than the department.
  It may feel strange for the most senior designer in a company to report into another function just because there’s no chief design officer. But Merholz doesn’t care much whether design reports into product, engineering, or marketing. What matters is that the head of design sits no more than two levels from the CEO in a smaller company, or from the general manager in a larger business unit of a corporation, because access to senior management is what gives design a voice and awareness of the company’s course.

• Fix what’s broken before pitching anything shiny.
  Merholz finds it problematic that so many design leaders try to impress senior management with bold, glossy innovation projects, while customers struggle with products that don’t work well. He claims that design earns its influence by solving problems people have today. That still takes a vision and alignment around a common goal, just not a vision that looks like a concept car so bizarre you can’t even find the door handle.
• Coffee chats beat presentations.
  When your title isn’t opening doors for your initiatives, another approach is to make people value you personally, so they say things like, “Joanna from design is great, and she’s sharp. Let’s bring her in.” Merholz shared the story of Kaaren Hanson, a design leader at JPMorgan Chase who grew her team from about 350 to over 800 designers and created about 100 design roles at director level or above. She used relationships as a key lever, building alliances before polishing deliverables. And if design leadership is change management, as Merholz says, it’s worth looking at the classic eight steps from John Kotter’s 1996 book “Leading Change.” His first two steps fit designers perfectly: create a sense of urgency, then build a coalition of people who can push the change with you. In other words, once you’ve shown why the problem can’t wait, find the few people with enough pull in the company to push the change with you.

• Executives aren’t as rational as designers assume.
  Finally, Merholz argues that designers wrongly assume business leaders make only rational, evidence-based decisions. I’d add that with the sheer number of decisions top managers make every day and all the variables involved, it would be nearly impossible anyway. So what do managers actually do? Many decide based on what others are doing. That means a brilliant design idea can easily get lost if nobody around the decision-maker is excited enough to rally behind it.

So Pfeffer, writing about business in general, and Merholz, writing about design specifically, reach similar conclusions: influence is a skill, and you have to build it deliberately if you want things to go differently than where the current carries you.

2.2. Build influence before you need it

The mindset shift can help you keep your sanity in this unfair world, but to actually make change happen, you need concrete methods. There are dozens of ways to influence as a hands-on designer or a design manager, so I picked the ones I’ve tried myself or heard about from the community, and arranged them by when you use them: from the foundations you need to set up long before a decision, to the last-minute moves just as you’re stepping into the room with stakeholders.

From day one: mapping the landscape

Your goal and its gatekeepers

Years ago, when I first learned about stakeholder management, I tried it on my own company right away. I drew the map, and it was a bit of a shock. The people I naturally got along with, the ones I’d grab a coffee with or chat to after meetings, had almost no say in my work. And the people I found hardest to connect with were the ones who actually shaped what I did. Since then, I’ve mapped stakeholders in every new team I’ve joined, sometimes on paper, sometimes just in my head. And I encourage everyone on my team to do the same, even mid-level designers who supposedly have nothing to do with “office politics.”

When I think about it now, this whole mapping exercise has two sides:

• asking the right questions and defining what you want from others;
• building a picture of who surrounds you and which partnerships are possible from where you stand.

For the first, we can draw on the wisdom of our old friend Mr. Pfeffer, who describes a sequence of steps to set the direction of your influence, so you don’t get lost among dozens of people. Here’s Pfeffer’s 1992 power process:

1. Decide what you’re trying to accomplish.
2. Diagnose dependence and interdependence patterns.
3. Forecast their likely points of view.
4. Analyze their power bases.
5. Analyze your bases of influence, including the ones worth developing.

Now let me illustrate these universal steps with a real-life situation I know all too well—it’s from the enterprise software world. Here’s the setup: a senior designer joins a product domain as its only UX expert, while formally belonging to a larger design team. The domain builds a set of connected features for a risk and control framework. Simply put, this is how companies in hazardous industries, like mining or construction, anticipate the worst things that could happen on a site, such as a gas explosion, and plan safeguards to prevent them: staff training, sensors, or procedures that keep welding work away from tank cleaning. When the designer joined, the software only supported a static view of risks and safeguards, a snapshot updated once a year at best. The domain’s big ambition is a dynamic, real-time view of risk.

1. Decide what you’re trying to accomplish.
   A vague goal like “make the product more user-friendly” won’t guide anything. A useful one is specific and time-bound, for example: “Within six months, make sure the first release of the real-time risk view is built on how risk managers actually monitor risk, not on whatever data happens to be easy to show.” A longer-term goal could be that no feature in this domain reaches development without a design review.
2. Diagnose dependence and interdependence patterns.
   The obvious names are the product manager, who owns the roadmap, and the engineering lead. But a real-time view also depends on less obvious people:
   • a data architect who decides what can actually be streamed in real time;
   • a risk subject-matter expert, whom the product manager consults before every decision because it’s faster than talking to actual users;
   • implementation consultants who know how customers really configure their risk frameworks;
   • customer success managers who control access to users;
   • designers working on connected features, like incident reporting or safety analytics, because a change in the risk view ripples into their workflows;
   • the designer’s direct manager (head of design), who controls research budget and backing.
3. Forecast their likely points of view.
   • The product manager may be under time pressure as sales has already promised a “real-time dashboard” to a big prospect. Discovery might be squeezed.
   • The engineering lead may worry that real-time means performance problems and a costly data pipeline, so they’ll lean toward cutting the scope.
   • The subject-matter expert may be skeptical of “real-time” altogether. Back when she did the work herself, controls were tested on a fixed schedule, so why disrupt processes that have worked for years?
   • Customer success hears weekly that customers export everything to spreadsheets to see current risk, so they’ll be your natural allies.
   • Designers of connected features want consistency and no surprises.
4. Analyze their power bases.
   • The product manager has legitimate power over the roadmap.
   • The engineering lead and the data architect have expert power—and effectively a veto on feasibility.
   • The risk expert has expert and referent power: when she says something doesn’t make sense, the discussion ends.
   • Customer success has informational power, since they hear the complaints.
   • Sales is under pressure itself rather than wielding real power, but a deal promised to a big prospect can still override the roadmap.
5. Analyze your bases of influence, including the ones worth developing.
   As a newcomer, the designer has expert power in research and design, but nobody has seen it yet. He needs to start with a quick fix of one existing painful issue so the team sees what design brings before the big debate starts. What he can develop next:
   • Informational power: with customer success’s help, interview a few risk managers about how they monitor risk today, including those makeshift spreadsheets.
   • Referent power: win the risk expert’s trust early, for example by asking her to review the interview guide.

An interesting caveat in this situation, which builds on Pfeffer’s ideas, is that the power people hold doesn’t always match their titles. Here, the subject-matter expert has no managerial authority, but she’s the go-to person for the product manager, who makes the final decisions. So in practice, her opinion often decides the outcome.

Pfeffer notes that power games intensify when people depend on each other more, and dependence grows when something is scarce, like budget or time. The domain I described has both. On the dependence side, the product manager leans on one subject-matter expert instead of users. On the scarcity side, there’s a sales deadline, and since the existing features have likely stopped bringing the growth the company wants, the new development has to succeed—and nobody wants to be the one asking for budget for a second try.

Who is who on the power–interest grid

This technique is usually attributed to Aubrey Mendelow, but its real origin is a bit more tangled. In 1981, Mendelow presented a paper called “Environmental Scanning: The Impact of the Stakeholder Concept” at the 2nd International Conference on Information Systems in Cambridge, Massachusetts. The paper was mostly about how closely a company should monitor different stakeholders, so his model plotted power against dynamism, meaning how fast a stakeholder’s situation changes. Hmm, not exactly what a designer needs, right?

The power–interest matrix we know today came later. It was Gerry Johnson and Kevan Scholes’s adaptation in their textbook “Exploring Corporate Strategy,” published in the 1990s. Its two axes create four quadrants, and each comes with a recommendation for how to treat the people who land there:

• High power, high interest—manage closely: involve them early and often.
• High power, low interest—keep satisfied: don’t overload them, but never surprise them.
• Low power, high interest—keep informed: potential allies and early supporters.
• Low power, low interest—monitor: a light touch is enough.

Remember the designer who joined the risk-and-control domain? Let’s put the stakeholders from that story into the four boxes.

• High power, high interest—manage closely:
  • The product manager: owns the roadmap and the final decisions, and is under pressure to deliver the real-time view.
  • The subject-matter expert: has no formal authority, but the product manager consults her before every decision.
  • The engineering lead and data architect: decide what’s technically feasible, which gives them a de facto veto.
• High power, low interest—keep satisfied:
  • Sales leadership: don’t care how the risk view works, but a deal promised to a big prospect can override the roadmap overnight.
  • The product director above the product manager: watches the domain’s results, not the design details, and can redirect priorities at any time.
  • The designer’s own manager (head of design): can back up the research effort, but follows many domains at once.
• Low power, high interest—keep informed:
  • Customer success managers: hear customers’ complaints and know their workarounds, which makes them the designer’s natural allies.
  • Implementation consultants: know how customers really configure their risk frameworks.
  • Designers of connected features: any change to the risk view affects user flows they are designing.
• Low power, low interest—monitor:
  • Marketing: nothing has been announced or promised to customers yet.

Mapping stakeholders helps a lot, but it takes careful observation of how the organization actually works, because the org chart can lie to you. Considering only the formal bosses is a common mistake. Besides, such mapping isn’t a one-time exercise, either, because people move between boxes. For example, the product director sits in “keep satisfied” for now, but if the designer shows how many customers export their risk data to spreadsheets, the product director might suddenly care a lot more and move into “manage closely.” That’s a bit scary, but look at the bright side: you’ve just gained a powerful sponsor.

Months ahead: trading influence

Okay, now you have a map of who holds power around you. It’s time to talk about trading influence, and this is where “Influence Without Authority” by Allan Cohen and David Bradford comes in (the latest edition is from 2017). The authors introduce what they call the exchange model: you offer something of value in return for what you need to do your job well. Of course, you have to know what the other person values, which the authors call their “currency.”

To make it actionable, Cohen and Bradford laid out six steps, moving from your own mindset to the actual exchange with others:

1. Assume everyone is a potential ally.
   Even the engineer who keeps rejecting your designs or the product manager who skips your ideas may support you once you understand what they need. If you label people as “anti-design,” you’ll paint yourself into a corner.
2. Clarify your goals and priorities.
   Know what you want from this person, like an earlier seat in planning or time for research. Without a goal, you’ll either ask for too much or waste your currency.
3. Diagnose the world of the other person.
   That’s a task for designers’ trademark empathy. Step into their shoes: understand their pressures and targets and who judges their work, because that explains their behavior better than their opinion of design does.
4. Identify relevant currencies, both theirs and yours.
   Figure out what each person values, whether it’s recognition or fewer rewrites, then check what’s actually in your pocket to offer. Designers usually hold more currencies than they realize: evidence, clarity, credit to share, etc.
5. Deal with the relationship.
   Pay attention to how much goodwill already exists between you, because the same request lands very differently with an ally than with someone you’ve never helped.
6. Influence through give and take.
   Make the exchange: offer what they value, ask for what you need, and make sure both sides come out ahead. Then deliver on your side, obviously.

But the exchange model can backfire: if you trade too often and too openly, it stops working. Relationships aren’t a series of bank transfers going back and forth every second. They’re messy and often unpredictable, and the authors themselves warn against treating the exchange model as a transaction. Here’s how I try to deal with it: I keep an internal “thermometer” for my relationships with different people, a loose sense of how warm or cold each one is. It tells me whether I have some credit I can use, or whether I need to warm the person up before I ask them for anything. And you can’t do that at the last minute. At best, it’ll look obvious, and at worst, it’ll feel manipulative and offensive.

Going back to our earlier example, here’s how the designer could apply it to some of the stakeholders:

• Product manager: cares about meeting sales expectations and looking good to the product director, so offer research that de-risks the scope. Or better yet, start it without asking for permission and show the results.
• Subject-matter expert: wants to be recognized and consulted as the knowledge keeper, so ask her to review the interview guide, and check with her when users’ answers get heavy with jargon.
• Engineering lead: wants fewer rewrites and a manageable scope, so offer clear evidence about which data users need most. That helps the team prioritize and ship something valuable quickly rather than getting stuck building an overgrown all-in-one solution.

Weeks ahead: getting in the room

For this section, I drew inspiration from designers’ close neighbors—software engineers. Two books are written specifically for staff engineers, the level above senior: “Staff Engineer: Leadership Beyond the Management Track” by Will Larson (2021) and “The Staff Engineer’s Path: A Guide for Individual Contributors Navigating Growth and Change” by Tanya Reilly (2022). Despite their engineering focus, both show that the staff level involves a lot of “people work,” so much of their advice on influence applies just as well to designers at senior level and above.

There’s no single room

When I first heard about designers craving a “seat at the table,” I imagined a director or vice president title, so that a design leader would be on the same level as the company’s other leaders. For some reason, I even pictured a round table, with the directors of engineering, product, marketing, and sales sitting around it, discussing important stuff. But in most companies, design sits a level lower because its headcount is smaller and it’s often seen as a support function. Still, getting into the room matters. The room just looks different from what I imagined: it’s every meeting, ritual, and process where decisions get made. As Will Larson points out, there’s no single room to get into, and getting into the right one isn’t a one-time challenge.

What does that mean for designers specifically?

• Quarterly planning decides what gets built and what doesn’t. The way in is to bring customer evidence about the problems worth solving, ideally framed around the business goals leadership already cares about.
• Discovery kickoffs frame the problem, and that framing decides which solutions are even considered. The way in is to offer to facilitate; designers are good at it, and whoever holds the marker shapes the framing.
• Technical design reviews decide what’s feasible, and data models often lock in user experience for years. The way in is to bring user scenarios engineers would otherwise discover too late.
• Customer escalation meetings decide which complaints become priorities. The way in is through customer success, who are usually glad to have someone who can turn complaints into fixes.
• Leadership offsites decide the strategy everyone else will execute. The way in is almost always a sponsor, which is the next part of this section.

This all looks overwhelming, but you don’t need to be in all of the rooms. Trace your last few frustrating decisions back to where they started, and you’ll see which two or three rooms matter the most.

Work the numerator and the denominator

Larson’s next point is that to get into the room, you need to develop a unique, useful perspective and deliver it in a way that fits the meeting. He uses a math metaphor: in a fraction like ¾, 3 is the numerator, and 4 is the denominator. In other words, having good ideas isn’t only half of the deal. You need to deliver them in a way the meeting can absorb.

• The numerator is your perspective: what you bring that nobody else in the room has, and that’s useful for the decisions being made there.
• The denominator is your delivery: how effectively you get that perspective across within the constraints of a meeting.

Here’s how that plays out for the designer in the risk domain:

• In quarterly planning, the numerator is evidence nobody else has: say, in most customer interviews, risk managers mentioned exporting data every week to see their current risk picture. The denominator is keeping it to a three-minute slot and one slide, tied to the domain’s growth goal, with no walkthrough of the research process.
• At a leadership offsite, the numerator is a strategic insight rather than a design detail: customers don’t need everything in real time, only early warning on a few critical indicators. That reframes the bet, since it means a faster launch and a cheaper data pipeline. The denominator is speaking the language of the room: two sentences on what customers need and one on what it means for revenue and cost; no screens and no personas.

You need a sponsor, and your sponsor takes a risk on you

Larson says someone has to sponsor your membership. That person is spending their own social capital on you, and their peers will judge them by how you act in the room. For designers, that means you’re asking someone, say a product director or chief technology officer, to bet their reputation on you, so it’s worth making that bet safe. For example, you are invited to the quarterly roadmap review, where the real-time risk view will be scoped.

• An unsafe version: the designer shows up with 15 slides about the research process, criticizes the sales team’s promise to a big prospect in front of everyone, and refuses to agree to anything until the data pipeline matches every user need. The next day, the director’s peers wonder why they brought “the design person” along, and the designer is never invited again.
• A safe version: a few days before, the designer walks the director through what they plan to say, so there are no surprises. In the meeting, the designer takes three minutes on one slide, showing how the user’s current workarounds link to a specific first release. Now the director looks smart for including design, and the next invitation is easy.

And don’t wait to be invited. Designers often do, but sponsors sit in so many meetings that they’d happily leave most of them behind, so, as Larson notes, they won’t assume you want to join one. They might even assume you don’t, so tell them. I’d add that sponsors have their own ambitions, too: they’re often looking for sponsorship themselves to play in even higher leagues. Make them look good in the room, and you’re giving them something they value.

Don’t block the room to get your way

Larson warns that you can sometimes force a group toward your view by withholding agreement until it comes around, but if you slow the group to a halt, you’ll likely get removed from the room the next day. For designers, this is especially painful, because the alternative to fighting in that meeting is a weaker design that gets shipped to customers and chalked up as yet another bad solution from the design team. So naturally, you dig in: “I won’t sign off until it’s right.”

Imagine the technical design review for the real-time safety risk monitor. The data architect proposes updating cumulative risk indicators every hour, not every minute, to keep the pipeline affordable. The designer is convinced that for some hazards, like a gas leak, an hour is far too long, so they refuse to approve the decision until it changes. The discussion goes in circles, the meeting runs over, and the decision gets pushed to next week. Next week, the review happens without the designer. A better move would have been to name the concern: “For gas detection, an hour-long delay could be dangerous,” and ask for it to be recorded as a risk with a named owner and a quick check with two or three customers. The team moves forward, while the concern stays on the table until resolved.

Don’t take it personally

Finally, Tanya Reilly offers some comfort to senior specialists in organizations that are still working out their hierarchies and roles, or that are simply less mature. If you don’t get into the room, it’s not necessarily about you. Remember the maturity models from earlier: at the lower stages, design is a service desk, no matter how senior anyone is. In that case, the room isn’t closed to you personally. It’s closed to design in general, and that requires a longer game. I’d extend this to design managers too, both those sitting a level or two below their counterparts in engineering or product, and new heads of design who find themselves in a vacuum of expectations.

Some changes take more than one “generation” of employees. More than once, I learned only after leaving a company that things I had started were carried on by those who came after me. Honestly, that never made me feel better. But it taught me that even the best intentions at work aren’t worth burning yourself out for, because change can outlive your time in a company.

Days ahead: going around the roots

“Nemawashi” (根回し) is a Japanese word made of “ne,” meaning root, and “mawasu,” meaning to turn or put one thing around another thing. It started as a gardening term: before transplanting a tree, you’d carefully dig around it some time in advance and trim the roots, so smaller roots would grow and help the tree settle in its new place. In business, it became an informal approach to decision-making. Before an important decision is made in a room full of stakeholders, you test your idea with each key person individually and try to win them over one by one. At the same time, you hear their criticism in private, which you can use to improve the idea, instead of being publicly humiliated at the final presentation.

Nemawashi is often criticized for being slow and hurting a team’s agility. But I’d argue that designers rarely have positional power, and this is one of the few tools we have—if not the only one—to move a decision our way.

Imagine a designer working on critical controls—the safeguards that stand between a hazard and a disaster, like gas detectors, emergency shutdown valves, or confined-space procedures. Today, companies verify these controls on a fixed calendar: every quarter, a control owner walks the site and confirms each one works. The problem is that the calendar treats every control the same. A gas detector in an area with three recent near misses gets checked as often as one in a building without a single safety event in years. So the designer proposes that on top of the calendar, the software watches for hints that a control may be weakening, like related near misses, failed past checks, or overdue maintenance, and suggests those controls for a priority check even if the calendar says it should be reviewed next year. It’s a fundamental shift, and in a big review meeting, it could easily get shot down. So, in the week before, the designer meets each key person one-on-one:

• The subject-matter expert is skeptical: fixed schedules are often required by regulators and corporate standards. The designer agrees that the calendar stays, but the software suggests checks on top of it.
• The product manager asks how an auditor would understand why one control was checked early and another wasn’t. So, they agree that every change in priority comes with a plain explanation of the signals behind it.
• The engineering lead warns that pulling in maintenance and workforce data would take months, so the first release uses only signals already in the product, like incidents and overdue actions.

By the time of the review, the designer already has the backing of three key stakeholders, and the meeting itself is almost a formality.

In many North American and European companies, open debate in the room is expected, while with nemawashi, consensus is built informally through side conversations and circulating drafts. So why would a designer working in a Western company use it? First, because of the power imbalance: you don’t want to be shut down by a very senior leader in the final presentation while nobody in the room backs you. Second, the idea of a single “Western” mindset is an oversimplification. In the Ukrainian tech companies where I started my career, reaching agreement person by person before the final decision was how things often got done, although nobody had a special name for it. In the Netherlands, where I live now, a tradition of consensus-building goes well beyond tech and is called the polder model. Its name comes from polders, patches of land reclaimed from the sea, where neighbors, even fierce rivals, had to cooperate to keep the dikes and pumps working, or everyone would flood.

I also like looking at nemawashi with empathy, from the perspective of the final decision-maker. If your idea catches them off guard in the final presentation, it’s no surprise they get defensive, simply because they’ve never heard of it before. So nemawashi doesn’t just help you get feedback and strengthen your proposal. It also gives stakeholders time to think about it before the formal discussion.

Minutes ahead: setting the frame

When the influencing groundwork has been laid months, weeks, and days before an important decision, what’s left is to walk into the room the right way. This is where I draw inspiration from Robert Cialdini’s 2016 book “Pre-Suasion: A Revolutionary Way to Influence and Persuade.” According to Cialdini, pre-suasion is the process of arranging for people to be receptive to a message before they encounter it, because what we present first changes how people experience what we present next. That’s why the frame has to be set right before the message. And in my experience, there’s another reason to plan this part last: a lot can change along the way. One of the stakeholders is sick and can’t attend, the slot gets cut, or someone with whom I had already nemawashi-ed last week sends me new feedback the night before.

In short, Cialdini says that the best persuaders win before they start talking, by deciding what their audience is paying attention to. Here are the ingredients of his approach:

Privileged moments

These are points in time when someone is especially receptive to a message. For example, the designer notices that every product review opens with the monthly safety numbers for customers. This month, the designer learns that a customer success manager plans to share the story of a near miss at a site where every control had passed its quarterly check just weeks earlier. So the designer asks to present right after that story. For a few minutes, everyone in the room is asking themselves the same question: how did all the checks look fine while a barrier was failing? That’s when the designer shows research from several customers that points to the same pattern, and proposes a solution.

Attention signals importance

Cialdini’s point is that whatever people are paying attention to right now feels like the most important thing in the world. He borrows the idea from Daniel Kahneman, the psychologist who won the Nobel Prize in Economics in 2002 for his work on how people make judgments and decisions, and the author of “Thinking, Fast and Slow.” Kahneman called this the focusing illusion: nothing in life seems as important as it does while you’re thinking about it. Kahneman found that students in the Midwest and in California were about equally happy, yet both groups expected Californians to be happier, simply because thinking about California brings the sunny weather to mind. In the same way, whatever you show the room first will feel like the most important thing.

For instance, imagine a design review for a banking system’s onboarding flow. If the designer opens with a competitor’s slick animated welcome screen “just for inspiration,” the next half an hour will be about animations. If the designer opens with the number of new users who give up at identity verification, and a short clip of someone struggling, the same room will focus on fixing the real problem.

Whoever’s in focus gets the credit

Cialdini describes a classic experiment in which two groups of observers watched the same conversation between two people. One group could clearly see the first person’s face, and the other group could clearly see the second person’s. Even though both groups watched exactly the same conversation, each group thought the person they could see best was the one driving it.

Now think of a quarterly review. The product manager walks leadership through the new outcomes, and narrates the research findings the designer spent three weeks gathering. The designer is a small square in the corner of the video call, with the camera off. Two weeks later, the chief product officer praises the product manager’s “great customer insight.” No one was trying to steal the credit; it just followed the spotlight. So if you want your evidence to count as yours, present it yourself, even if it’s just two minutes in someone else’s demo.

Openers that set the frame

This advice is also backed by experiments. Cialdini cites a study in which researchers asked people to take part in an unpaid survey, and 29% agreed. When the researchers first asked, “Do you consider yourself a helpful person?”, the share who agreed jumped to 77.3%. People searched their memories for proof that they were helpful, almost always found some, and then wanted to act like it.

For designers, the trick is to start with a question that gets everyone to agree on a principle your proposal already follows. Then your design stops being “the designer’s idea” and becomes the obvious way to act on what the room just said. For example:

• Before presenting a simpler incident flow: “Would we agree that a field worker should be able to report a hazard before they forget the details?”
• Before proposing dynamic control checks: “When was the last time a routine quarterly check actually caught a failing control?”
• Before pushing back on a feature request: “Which of the features we shipped last year do customers still use every week?”

Once people say yes, they tend to stay consistent with it. If someone later objects, you can gently bring them back to the core principle everyone agreed upon.

Frame it around the people who benefit

In a hospital study by Adam Grant and David Hofmann, signs saying that hand hygiene protects patients from disease increased doctors’ soap use by 45%, while signs reminding doctors that it protects them had no effect. People move more for others than for themselves.

For designers, that means framing a proposal around the people it helps, not around the design. “This redesign reduces steps needed to report a safety event from 40 to 8” is soulless feature-speak, while “This lets a worker report a gas leak before they’ve walked away from it” sounds like a serious reason to act. In safety software, that’s especially powerful, because the people who benefit are hundreds of workers on site, and nobody in the room wants to argue against keeping them safe.

Make it “our” idea

Cialdini says that unity, the feeling that “we’re on the same side,” makes people far more willing to say yes. He describes two kinds: being together, like being on the same team, and acting together, like building something jointly. For designers, the second one is gold. Asking for advice or a specific perspective turns a stakeholder into a co-author, while “What do you think of it?” keeps them in the judge’s seat. Besides, people who helped shape an idea by giving feedback and pointing out its weak spots rarely shoot it down later.

Here are a few better ways to guide the conversation:

• “How well does it solve…”
  In a conversation with the subject-matter expert: “How well does this solve the problem of control owners checking stable valves every quarter while busier areas wait for weeks?”
• “I need a fresh look from you at how well this…”
  Aligning with the product manager: “I need a fresh look from you at how well this would hold up in the context of the broader product vision for the next year.”
• “While we have evidence of X, I need your view on Y.”
  Clarifying things with the data architect: “While we have evidence that control owners lose time checking stable controls, I need your view on how often our data could realistically update to catch the ones that aren’t stable.”
• “What would make this…”
  Consulting the engineering lead: “What would make this hard to build in the first release?”

By the way, this technique combines well with nemawashi. Approaching people one by one works much better when you bring solid questions, instead of the kindergarten-level “Do you like it?” or its slightly more grown-up cousin, “What do you think of it?”

2.3. How to win the room (now that you’ve sneaked in)

Tame the HiPPO

The term HiPPO is usually credited to Avinash Kaushik, a web analytics expert who later became Google’s analytics evangelist, and Ronny Kohavi, who then led Microsoft’s experimentation team. They came up with it in 2006 to describe how most companies make decisions, which is by going with the opinion of the highest-paid person in the room. The higher the salary, the bigger the title, and consequently, the more important the opinion. Since then, the acronym has traveled from book to book and hardly needs explaining today.

I devoted the entire first chapter to the power imbalance, so it’s no surprise that designers run into HiPPOs more often than most. On top of that, design judgment often looks like opinion from the outside, even when it’s backed by research. So we know first-hand what it’s like to get steamrolled. A HiPPO isn’t necessarily a bad person who’s wrong or means harm. But because the group blindly obeys them, every word that leaves their mouth is a potential rotten tomato thrown at your work.

Luckily, as Kaushik himself observed, senior managers may be biased toward their own views, but they bow to customer data and competitive opportunities. In other words, evidence works. Here’s how that translates to design:

1. Prepare for the HiPPO before the meeting.
   Build evidence around the things the most senior person cares about most or is judged by, which is usually the financials.
2. Agree on criteria before comparing options.
   Before anyone picks a favorite option, get the room to agree on two or three things the solution must achieve. Then the HiPPO’s idea and yours are judged against the same bar.
3. Turn the opinion into a hypothesis.
   Don’t argue with the HiPPO’s idea. Treat it as a possibility worth testing, and offer a cheap, fast way to check it.
4. Don’t fight alone.
   Before a meeting where a decision is made, build consensus with others, so the group is informed and more likely to question the HiPPO. Hello, nemawashi!
5. Let them keep face.
   The goal is a good decision, not proving the boss wrong, so always leave the HiPPO a graceful way to change their mind.

For instance, in the review, the chief product officer cuts in: “Honestly, customers just want a real-time dashboard. Let’s build that and skip the integrations stuff.” The room goes quiet. Instead of defending the proposal, the designer says: “That could well be right. Can we check it against what we agreed the first release has to do: catch weakening controls earlier? In our interviews, control owners mostly asked which checks to do next, not for more charts. I can show both ideas to a few customers in the next two weeks—before we commit to the priorities.” The chief product officer agrees. Nobody called them dumb or uninformed, and the decision now belongs to customers instead of the org chart.

Hold the pen

You’ve prepared for months, got into the room, and survived the HiPPO. Now comes the part most designers skip: writing the decision down before anyone leaves. It sounds like admin work, but whoever holds the pen decides how the decision is worded, and the wording decides what people later remember agreeing to. Nobody holds a literal pen these days, of course, but a simple summary of three bullet points in the meeting chat is all it takes.

Engineers have been doing this for years. In 2011, software architect Michael Nygard proposed the architecture decision record, a short note that captures a single important decision: the context, what was decided, and its consequences. The idea spread widely, because six months later, nobody remembers why the team chose what it chose. Such a written decision only works if it names who made it. Without a decision-maker, or several, the record is just meeting notes, and anyone can later say, “I never agreed to that.” Naming the person who decided turns notes into a real commitment.

For designers, a written decision does three things:

• Makes the win last. Arguments get lost in the flood of information, but a record stays.
• Protects you when you lose. If you raise a concern, it’s on record with an owner, so if it comes back, nobody can say they didn’t know.
• Builds your track record. Over time, your decision log shows whose calls held up, which is the branding moat from Chapter I that keeps your role strong.

Going back to our example: five minutes before the end, the designer shared their screen and started typing a draft. The product director immediately corrected one line: “Not pilot, let’s call it an experiment. I don’t want to promise customers anything yet.” The engineering lead asked to add that sensor data is out of scope for now. The chief product officer, still not fully convinced, insisted on writing “real-time dashboard on hold” instead of “dashboard rejected.”

The final record: “Run an experiment with risk-based control check suggestions at five customers in the next two weeks. Decided by: product director. Data for the first release: incidents, past check results, overdue actions. Out of scope for now: sensor data. On hold: real-time dashboard, pending feedback from customers.”

Three days later, when someone asked why the dashboard wasn’t being built, there was a decision to point to.

Influencing in a nutshell

1. Getting your work adopted is half the job, so treat influence as part of your craft instead of a distraction from it.
2. Map the stakeholder landscape from day one, find out what each person values, and keep your relationships warm long before you need a favor.
3. Get into the rooms where decisions start, with a sponsor who’s willing to bet on you, and make that bet safe by being useful and never blocking the room.
4. Win the decision before the meeting, one person at a time, turning critics into co-authors.
5. Before anyone leaves, grab the pen and write the decision down.