Location: Blog Menu ▼

10 behaviors for more influence

  • In the last two years, I mentored several UX designers at Google on improving communication and cross-functional influence. Similar topics started to surface with each person, so I decided to note them down.
  • I gave an internal talk about the ten behaviors. Then I gave an external talk. This article is an adaptation of the talk transcript.
  • The list is not exhaustive. Ten was a nice round number that was easy to convey.
  • Even though I initially came up with content for UXers, everyone can benefit from it (analysts, software developers, and project managers attended the external talk, and found it helpful). Just ignore UX-specific language.

Behaviors:

  1. Be in the loop
  2. Speak the language
  3. Know something others don’t
  4. Share information
  5. Invite yourself to meetings
  6. Speak up in meetings
  7. Paint a picture for others
  8. Socialize ideas in 1:1s
    Game theory interlude
  9. Find allies
  10. Hold the line

Intro

Influence is the ability to affect someone’s behavior. When I talk to people about influence, I often hear, “You’re just manipulating people.” It can be confusing, but there’s a distinction, at least in my mind. Let’s look at an example.

You want to go to a party, but it’s far away. Only your roommate has a car. Let’s consider two things you can do.

  1. You can persuade your roommate to give you a ride to the party. You also say that they can stay at the party with you and that you’ll ensure they have fun. If you come to the party and follow through on your promise, you influenced someone. You changed their behavior and got a better outcome for both.
  2. You start the same way, but when you get to the party, you disappear and leave your roommate alone, and later find someone else to drive you back home. You weren’t honest about your real intentions. You used your roommate as means for your ends.

You affected someone’s behavior in both cases, but with very different outcomes for people around you. The former is influence and the latter is manipulation. Even though the techniques are pretty much the same, outcomes and intentions make all the difference.

I want to influence my cross-functional peers—over which I have no formal authority—because my UX team has great ideas and can bring a lot of value to the broader team and the company. I want to push my team to be a part of the decision-making process for our products with product managers, engineers, and other roles.

Let’s start with behaviors.

1. Be in the loop

You need to understand what is happening around you. As a part of day-to-day activities, people write documents, schedule and conduct meetings, chat on internal messaging systems or over coffee, and create and track issues. UXers sometimes avoid getting involved under the excuse that it’s technical and something that only product managers and engineers do. It’s not specific to their roles; it’s just what they’re using to communicate and make stuff done.

In addition to day-to-day, can you list all projects that are happening at the moment? What about those that were deprioritized, and why? What are the yearly goals of your team? Quarterly? What are your customers’ issues or challenges?

If you keep out of these conversations and say, “Oh, I’ll just wait for others to come to me and ask me for advice,” you’re in for an unpleasant surprise. Nobody will ask you anything if you don’t know what’s happening. It’s essential to be in the loop.

When I joined my team, the team was six to seven people across all roles. We went together for lunch every day, and that was enough to understand what was happening. Now we’re more than thirty. I need to find a different way of communicating. Maybe it’s through people who report to me or setting up 1:1s with area leads; there are different ways of communicating within groups of various sizes.

2. Speak the language

Imagine an Italian relocating to Finland. After some time, the Italian becomes frustrated that nobody understands Italian and that everyone speaks Finnish. You might say, “Oh Merlin, that is a silly example.” It is, but when it’s transferred to work, suddenly nobody can notice the silly example anymore.

Google is a tech company founded by engineers, so it’s not surprising that there are more software engineers than designers, user researchers, or product managers by order of magnitude. When software engineers speak, they don’t speak English, which is the official language at Google, but a language full of technical terms and jargon like databases, classes, interfaces, machine learning, continuous integration, version control, and similar. This kind of language dominates because most other people around software engineers are software engineers too.

The second most common spoken language is the language of business. Product managers and salespeople use it all the time. In addition to having a rich vocabulary around revenue, costs, profit margins, product-market fit, and growth, it’s also full of industry-specific terms.

Merlin, I’ve been trying to talk to product managers, but they don’t listen to me. And engineers don’t care about design.” Maybe some don’t want to listen or don’t care. However, I’ll assume that many of them don’t understand what you’re talking about. Personas, information architecture, user journeys, whitespace, padding, micro-interactions, sliding panels, serif typefaces, formative user research — what sense do these make to anyone who is not a UXer?

I’ve witnessed first-hand how UXers come to meetings and can’t follow what’s being discussed. They’re afraid to ask what the strange words mean. For example, if you’re a designer, an engineer might say to you, “The code is not going to run on the client. It is going to run on the server.” What does that mean? Due to a server roundtrip, latency is going to be a factor unless something extra is done to mask it. You need to check the data connection and design for situations where it’s absent or spotty. What if the server doesn’t respond? Or what if it responds, but with various errors? You need to prepare all the loading states and error messages.

When engineers say client-server, it’s a done deal for them. If you, as a designer, don’t understand this, you’ll design something suboptimal or even wrong. You’ll probably have to make several revisions in the future when engineers start implementing it. It’s a waste of time for everyone, and you’ll lose some credibility. However, if you know the language, you can make communication more efficient and avoid mistakes later. You’ll be considered a group member just because of having the same vocabulary.

But Merlin, why don’t THEY learn our language first?” The argument goes both ways. Someone has to start first, and since it’s harder to change the majority, why not you instead of them? Once you know their language and can influence, you should also educate the other side. Multilingual environments are the best.

3. Know something others don’t

When I joined Google, my team consisted of one product manager and several engineers. They didn’t have any UXers for almost a year. They would go in a room, make a decision, come out and say, “Merlin, this is what you need to do.” “Okay. But why didn’t you invite me too?” “Oh, we forgot. Sorry.”

I was never invited in the beginning. I was constantly asking myself why. Why wasn’t I in the room? The main question I should have asked myself is why would anyone have me in the room in the first place? What is the value I can bring to the team? What is the value YOU can bring to YOUR team? The question is hard to answer. But once you do, I promise you the answer will transform the way you work.

My story. When I joined the team, I started working on an internal enterprise tool. Users hated it. The product team wasn’t talking to users (Googlers in another organization) regularly. I reached out to our users and said, “Look, I work on this. I know it’s horrible. Let’s talk. Tell me all about your problems.” I slowly learned about their challenges and gathered some insights into how we can fix the product. Those insights were the value I brought to the team.

I got an interesting performance review from a senior engineer soon after that: “Merlin is doing this weird thing: he goes out and talks to people. It seems like it’s working.”

4. Share information

Once you know what value you bring to your team, you have to send out that information. It’s not helpful if it’s in your head only; you need to share it. The way you’re going to do it will depend on understanding how your team communicates (the first point). Are you sending weekly emails? Are you sending snippets on chat? Are you meeting people over coffee and sharing in person? It’s critical to signal to others that you have something of value which all of you can use together to do a better job.

5. Invite yourself to meetings

When I was giving this talk, I asked several audiences if they ever invited themselves to a meeting. There were always people who raised their hands. When I inquired if they’ve been asked to leave the meeting after joining it, everyone said, “No.” That’s my experience too. Whenever I did this, people were either neutral or happy that I joined; they had forgotten to add me or thought I wouldn’t be interested.

Even though my sample was small and potentially skewed by friendly company cultures, my stance is that inviting yourself to relevant meetings is something you should consider doing until it becomes a habit for others to add you from the start. Relevant is the critical word here. If your product team dropped you from an invite, there’s a big chance you should be there. However, executive strategy meeting for a completely different part of your organization isn’t the right place to start practicing this behavior.

6. Speak up in meetings

By now, you know what’s happening, you have good ideas others are not aware of, and you invited yourself to a meeting. If you don’t use this opportunity to say something, why are you even there? Why go through all that hassle?

I get it—it’s hard. We want to stay safe by not exposing ourselves. As social creatures, we’re inclined to conform, especially if there’s a possibility of saying something stupid. It’s still not a good enough reason to stay silent forever.

I received a piece of excellent advice on how to break the speaking barrier from several senior people: start by asking questions. It can be only one question at the beginning, and it can be only to clarify something. The tactic has two benefits:

  1. When you do it several times, you’ll notice nothing terrible has happened. You’ll be more comfortable asking additional questions or even suggesting your ideas.
  2. People will get accustomed to hearing your voice. I’ve seen situations where someone is coming to meetings, but says something only after a year. Others were so surprised that the person said something out loud that they didn’t give their full attention to what was said. It doesn’t mean you should speak just for the sake of speaking; you should have something valuable to say. At the same time, others should expect that they will hear from you in some way.

7. Paint a picture for others

You are arguing a complex topic with several people. Varying opinions fly around. The conversation goes in circles, usually because people think they’re talking about the same thing even though they aren’t. (Un)fortunately, we’re not able to read each other’s minds.

One potential resolution is to take a piece of paper or walk to a whiteboard, and to try to externalize everyone’s thoughts. Start from one person, say, “This is what I’m hearing,” and mark it down. Use text, lines, arrows, boxes— keep it simple. There are two possible outcomes:

  1. Yes, that’s exactly what I meant.”
  2. Not really. This part on the left…”

If it’s the latter, you’ll update your picture until it’s right. During that time, everyone else in the room will look at the picture and have the same reaction: either they agree with it, or they can point to a specific part they disagree with. It’s much easier to discuss if you can see what you’re talking about.

Keep in mind that the person who is holding the marker wields a lot of power. If you do it, the way you facilitate, ask questions, and put it on a whiteboard can influence the direction the discussion is heading.

8. Socialize ideas in 1:1s

Have you ever worked on what you thought was an excellent idea for several weeks without telling anyone, stood in front of your peers and bosses, and unveiled your piece of art, which was followed by a standing ovation and cheering? I’ll assume “no.”

It’s extremely rare for people to make a group decision about a complex topic after the first hearing. Group meetings usually serve two purposes:

  1. To notify people that a decision will have to be made in the future and have a forum when they can ask questions
  2. To let people know that a decision has been made and that everyone sees that everyone else agrees with the decision

So, where are decisions made, and how can you influence them in case you are presenting an idea? In one-to-one conversations. One person alone is more likely to speak their mind, and you can hear their concerns, wishes, and goals. If the feedback is valid, you should incorporate it into your idea—you’ll get a better idea, and they’re more likely to approve it later on.

You should talk to everyone who is involved since skipping someone who can affect the decision might lead to dire consequences. It takes time to talk to everyone, and you might even need to do a second round. However, I haven’t found a better way that gives such a high chance of success.

Game theory interlude

Before I cover the last two behaviors, we need to look at game theory, which is an umbrella term for different fields of studies about how rational decision-makers interact. It’s always tricky to put “rational” and “humans” in the same sentence, but experts in the field came up with good approximations of behaviors that are successfully applied to real life.

One famous example from game theory is the prisoner’s dilemma. Two perpetrators commit a crime, but the police get them. Unfortunately, the evidence isn’t substantial for a more significant charge, so the police take the offenders to different rooms for questioning, hoping at least one of them will rat on the other.

Three outcomes can happen:

  1. If both perpetrators stay silent, they get a short prison sentence and will walk out soon.
  2. If one betrays the other, the former is released immediately, and the latter receives a lengthy prison sentence.
  3. If they both betray each other, both get a prison sentence of medium length.

What would you do in that situation if you were one of the offenders? If you always stay silent, you’ll undoubtedly stay in prison for a short or long time. If you always rat out your partner, you’ll either walk away free or remain in prison for a moderate amount of time. It looks like the most rational thing to do is always to betray. All this doesn’t sound good because it seems being selfish is the best strategy. However, humans have been working together and collaborating since the early days of humanity, so something must be off, right?

Political scientist Rober Axelrod was wondering the same thing in the late 1970s and early 1980s. He decided to do an experiment. It would place in the form of a tournament where agents play a game of prisoner’s dilemma against each other, but with a modification that agents play two hundred consecutive rounds instead of only one. And instead of going to prison, agents got points when they collaborate or defect. You can see the payoff matrix in the accompanying table.

Cooperate Defect
Cooperate 3,3 0,5
Defect 5,0 1,1
The payoff to the row agent is given first in each pair of numbers.

The agents were computer programs that tried to employ strategies that would maximize gains in the tournament. Some strategies are simple. For example, always cooperate or choose your action randomly. Others are more nuanced and include remembering earlier interactions and responses from the other agent to come up with a probability of success for future cooperate and defect moves.

(For in-depth analysis and results, I highly recommend reading the original paper titled Effective Choice in the Prisoner’s Dilemma or Robert Axelrod’s book The Evolution of Cooperation that covers the same topic. I’ll draw some high-level conclusions from the paper, but it’s hard to convey all the nuances in one short article.)

So, how did the tournament go? It was full of surprises.

The best predictor of scoring high was how nice an agent was. If it cooperated more than it defected, it usually landed in the top half.

The highest scoring agent was also one of the simplest: tit for tat (or equivalent retaliation). It would start by cooperating and then repeat whatever the other agent did in the previous round. If the other agent defected, tit for tat defected too; if the other agent went back to cooperating, tit for tat followed suit. Reciprocity, mirroring, an eye for an eye, call it however you want—this behavior seems familiar to us. It’s essential to recognize the fact that tit for tat didn’t win every game against another agent; it was the overall winner in terms of total points earned. Also, the best strategy for every situation doesn’t exist.

The tournament showed that tit for tat is a bit too aggressive. It always responds to defection and it never de-escalates. A strategy that might work even better is the one that allows for occasional forgiveness. Think of it in terms of day to day work. Maybe a person did something that you consider bad, but it was just an honest mistake. If you weren’t invited to a meeting, it might not be that they don’t care about you. Instead, they could have been distracted while preparing an invite. It’s always prudent to hold back for the first time, but if it starts to happen more, you need to react.

Robert Axelrod later tried different experiments. One was a two-dimensional territory where agents could only interact with adjacent agents. Agents can adopt successful behaviors from agents around them. He wanted to know when one strategy spreads and when others overpower it.

He showed that if you put a nice strategy into an environment where nobody wants to cooperate, it’s impossible to break free. Since nobody is cooperating, you can never prove your value to the other side. Cooperation never emerges.

But if at least one other neighboring agent is willing to cooperate, then the two of them, through repeated interactions, accrue so many benefits that others adopt that strategy. In other words, others see who is winning and want to join. It might be for selfish reasons, but if the consequence is spreading good behavior, it’s not a bad outcome.

9. Find allies

Let’s go back to behaviors and use what we learned about game theory. When you join a new company or team, it’s almost impossible to make a change or improve a situation if nobody is responding to your ideas,

I was fortunate that in my team at Google, the software engineering manager was receptive to UX. That was enough for me to start. I didn’t need support across the board, just an opportunity to show that working well together is going to be beneficial to all of us. Today, the team is five times bigger, and most members consider UX a critical part of product development.

One senior designer in my team formed an excellent relationship with one software engineer working on the front end. They occupied a corner in our office, put up some whiteboards, and continued to have such a good working relationship that other people around them said, “Wow, they’re producing excellent work. We also want to be part of it.” Everyone who joined the team later didn’t have to overthink what mindset to adopt. The good behavior spread.

In summary, find people who see the benefits of working with you, even though they might not share your goals. You can’t do it alone.

10. Hold the line

Let me tell you about a situation that happened to me. As a design manager, I’m in charge of allocating work for designers. The team was considering starting a new effort in the future that would require significant resourcing. A part of that was staffing, and the effort would be big enough that it required hiring new people. When I heard the team discuss how many engineers and product managers we need, I immediately jumped in and explained how many additional UX people we would need to build and launch the effort successfully. It was impossible to support it with current staffing.

Fast forward six months. The executives approved the effort, and staffing came through. Except for UX. No additional people.

The team came to me and asked who is going to work on the effort from the design side. At this point, I had two options:

  1. Push my people hard, institute overtime work, and overall go crazy to support current and additional work.
  2. Say, “I told you this is going to happen six months ago. You ignored me, and now, unfortunately, you’ll have to choose which effort is going to be left unsupported.”

I’m hoping the game theory interlude hints at what I did next. I went with number two. And I can assure you that it was uncomfortable—for me, for my team, for everyone—because most people want to help as much as possible and this standoff was preventing that. Being nice most of the time is the best approach overall, but always being nice becomes counterproductive because you’ll be prone to exploitation. Sometimes you need to hold the line at all costs.

The story has a happy ending. Several weeks later, executives approved additional staffing for UX. And six months later, when we were preparing for another similar effort, UX staffing was already accounted for in the initial request by the team.

Out of all behaviors, holding the line might be the hardest to apply. UXers often join a company or team later than other functions. The track record and trust still need to be formed, and that takes time. One incident of being trampled over in a public forum is enough to undermine everything you’ve been trying to build for months or years through other behaviors. The outcomes are asymmetric—gain almost nothing when you do it, lose everything when you don’t.

Juniors, women, and underrepresented groups are often on the receiving end of unpopular decisions. If you’re in a senior role, it’s up to you to help them hold the line.

Conclusion

Why am I calling these ten items “behaviors”? Because they’re not a checklist. They’re more similar to good practices for health, nutrition, and hygiene — you need to do all of them consistently every day. Going to the gym or for a run makes sense if you do it every week, not only after New Year’s Eve. If you brush your teeth seven times on Sunday, the cleanliness won’t last throughout the whole week.

The best performers are not consistently great, but they’re great at being consistent.”

— from the book Peak Performance


Don’t miss this one:
Paper or digital books?

Back to top ▲