Speak in their currency: how architects earn influence without authority

A well-understood organization and a well-documented decision get you nowhere if people do not want to act on it. Karol Wiszowaty on stakeholder currencies, strategic empathy, storytelling, treating resistance as a signal, and the trust pyramid.

Published
Series
Architecture starts with people, part 5
Reading time
9 min

The previous four articles were about understanding the organization around a system: Conway’s Law and the temporary project organization, walking it more than once, mapping the people, and recording why decisions were made. One piece is still missing. Even a well-understood organization and a well-documented decision get you nowhere if people do not want to act on it.

To talk about that piece I invited Karol Wiszowaty to a Walking Talking episode. Karol is an architect who works closely with business, a conference speaker and, as he agreed when I suggested it, a “retired programmer”. We worked together for seven years, and he was the first line of escalation when projects went off track or missed their deadlines. The ideas below are Karol’s unless I say otherwise; I add my own comments and some supporting literature.

Every stakeholder has a currency

In the third article we mapped stakeholders. Karol starts where the map ends: once you know who is who, you have to talk to each of them in their own language. When you make a transaction with someone, you pay in their currency.

His examples are simple. A C-level executive will probably care about return on investment or the growth of the company. A project manager or product owner cares about deadlines and getting new features to market. Developers care about the technology stack and autonomy. If a pitch does not take that currency into account, Karol argues, it will simply not be interesting to the person hearing it.

The metaphor has a long history in management literature. Allan Cohen and David Bradford built their book Influence Without Authority on an exchange model: you get cooperation from people you do not manage by understanding what they value, their “currency”, and offering something of value in return (Cohen and Bradford, 3rd ed., Wiley, 2017).

Three questions before you pitch

Karol asks three questions before going to anyone with an idea.

  1. What does this person care about? Money, deadlines, something else. A pitch that does not aim at that will probably not work.
  2. Where are they in the decision process, and are they in a crisis? Timing matters a lot. Karol means any kind of crisis: financial, a deadline, a project in trouble. If someone is being pressed by the CFO about money or by customers about promised features, they will not be open to a big refactoring, however good it is.
  3. What are they afraid of? Karol warns that we may underestimate fear: of losing control, or of failing in front of management. Sometimes people prefer that things stay as they are, so that their boss does not see something go wrong.

Karol calls the result “strategic empathy”: learning people’s needs and fears, and building your pitch so that what you want to deliver helps them reach their own goals. Then it has a chance to work.

Nobody has to follow your diagram

When I asked Karol for a secret recipe for finding those needs and fears in a new organization, he said there is no holy grail. What he described instead was influence.

Coming in and saying “this is my architecture diagram, these are the rules, everyone has to follow them” never works, in Karol’s view. Developers drift away, nobody feels connected to the decision, and nothing comes of it. What works is listening, negotiating and presenting your idea. We do not have to be an authority for these people or manage them. We have to make them want to work with us. In the end, he says, we are usually trying to convince people we do not manage, who may not like us or our idea, to join us and build it together. Empathy is the best tool for that, and it takes long, hard work.

Gregor Hohpe makes a similar point about the architect’s role. Citing Erik Dörnenburg, he describes an architect who works like a tour guide: someone who knows the place, can tell a good story about it, and guides people without being able to force them, and who therefore has to lead by influence (The Software Architect Elevator, pp. 17-18).

I told Karol a saying I once heard somewhere: you have two ears and one mouth, so listen more than you talk. He agreed and took it further. Listening builds trust by itself. When we listen and ask follow-up questions, the other person feels noticed and appreciated.

Stories travel further than bullet points

One of Karol’s favourite tools for building influence is storytelling. He contrasts two pitches.

The first: we need microservices, because they scale and give teams autonomy. The second, which Karol gave as an illustration, not as a real incident: before Christmas our systems froze, nobody knew why, customers could not buy anything, revenue dropped and people were angry. It took four hours to find that the problem was in the cart, at payment, because the servers were overloaded. With microservices we could have handled five times more traffic without any loss.

The second version stays with stakeholders, because they see the pain, the consequences, a turning point and a solution. As Karol puts it, they buy why we do something, not how. And a good story gets retold from person to person and team to team. In his words: “a good story works for us even when we are not in the room.”

Karol also gives the story a structure:

  1. Problem: for example, the servers went down.
  2. Consequences: shown explicitly, because we see them in our heads the moment we name the problem, but the other side may not. Nothing could be bought, revenue fell, users were angry, the brand suffered.
  3. Solution: how we could have avoided it, for example with a different architecture.
  4. Gains: what we get from it.

The language has to fit the audience. Nobody on the business side buys “we implemented observability”. What interests decision-makers, in Karol’s illustrative example, is that an outage that used to last four hours will now last fifteen minutes, which means less downtime and fewer customers leaving.

Tanusree McCabe describes the same technique for presenting architecture decisions: storytelling couples logic and facts with a conflict and a solution, which creates an emotional connection that a conventional problem, options, recommendation format does not (Fundamentals of Enterprise Architecture, p. 152).

Resistance is a signal

Karol has seen many times how people react to a proposed change with automatic resistance: leave it as it is, it is too hard, we tried that. Many of us then jump in to defend the idea by force.

Karol’s view is that resistance is natural, because people try to use as little energy as possible, and that our job is to work with it, not fight it. “Resistance is really only a signal for us,” he says: people are afraid of something, or they care. If they did not care, they would say “go ahead, it makes no difference to me”. So the worst move is to defend your idea. The best is curiosity: why do you think so, what worries you, how would you do it?

He describes the path from rejection to adoption in stages:

  1. Initial pushback: “it will not work, we tried it, it is too hard.”
  2. Curiosity and engagement: “fine, maybe in some cases, but not across the whole system.”
  3. ”Leave it, I will do it better”: this is the moment to hand over the keyboard.
  4. Belief: “this might actually work.”
  5. Pilot: a small project in a controlled environment that builds confidence and momentum. Hard evidence replaces arguments.
  6. Adoption: across the system or the company.

His most practical advice is to find the biggest critic of your solution and engage them, not drag them along: “how would you do it?”, “come and help me design it”. A critic who becomes a co-author feels responsible for the result and starts pushing it forward.

This matches management research. Jeffrey and Laurie Ford argue in Harvard Business Review that resistance should be treated as feedback, and that resisters, who often care most about getting things right, should be invited to help (Ford and Ford, 2009). Hohpe adds that complex organizations settle into patterns and actively resist change, so if you want different behaviour, you have to change the system (The Software Architect Elevator, p. 287).

My own confession from the conversation: I used to like winning arguments, sometimes even getting into a verbal fight because I was sure I was right. At some point I realized it was enough to give the idea away, to guide the person so that it becomes their decision and their idea. The conversation goes completely differently. It sounds trivial, but it helps a lot.

Trust, built slowly

I asked Karol how to calm things down in an escalation, since he had been in so many. His answer started with listening again: listen and actually hear what the other side wants, instead of waiting for your turn to contradict them. Then be professional. If something really is wrong, admit it plainly: we did not take this into account. Taking it on the chin builds trust, because people stop suspecting that you will always hide your mistakes.

Everything comes down to trust, and Karol describes it as a pyramid built over a long time:

  • At the base: consistency. We show up when we have to. When we say we will do something, we do it.
  • In the middle: listening, hearing the needs of others and responding to them.
  • At the top: results and technical excellence.

The order is not accidental. Technical excellence matters, but it is only the tip. Without consistency, empathy and listening, Karol says, the other side will not trust you, and even the best system or solution will not get through. With trust, you can spend some of it in a conflict: sorry, this did not work, but we know how to fix it.

Closing the series

Karol ended the conversation with a thought he says he repeats often. Our ideas, our products and our architectures are worthless unless someone believes in them, pays for them, funds them and implements them. Whether they happen depends on us and our communication. The best ideas in the world will never happen if we cannot pass them on so that someone cares.

That brings the series back to the start. Conway’s Law says the system will copy the communication structure of the organization that builds it. Everything after that was about the communication itself: walking the organization, mapping the people, recording why, and finally earning enough trust that people want to build what you designed. McCabe makes the same point from the enterprise side: without a partnership with business, technology and product leaders, an architecture deliverable is nothing more than a piece of paper (Fundamentals of Enterprise Architecture, p. 20).

For a client choosing a vendor, I would add one practical question to the ones from earlier articles: does the vendor’s architect talk to you in your currency, or in theirs?

Karol has written a book on exactly this kind of work: The One Minute Architect: The Story of the Most Invisible Job in Software, published by Arpeggia.studio, the company I work for, so take the recommendation with that in mind (theoneminutearchitect.com). It follows a young engineer, Joe, through his first role as an architect, with a retired building architect, Bill, as his mentor. What resonates with me most is the idea of invisible work: it is hard to define what an architect does, but when there is a good one in the team, things simply move forward.

Sources

Choosing a vendor or shaping a project team?

Tell me what you are deciding and who is involved. I will tell you honestly whether I can help.

Work with meAll writing