Managing Through Influence

I can accomplish very little on my own. So I put a lot of time into influencing other people. This can be especially difficult in a large company, where I need to influence people above me in the hierarchy, people in other departments, and often people I've never even met. Here are some ways I manage through influence, with special thanks to Creative Good Council 1 for their help expanding and fleshing out the list. 

Think of this as 20 tips for developing the art of influence.

As I walk through the list, I'm assuming you have a "target"--a specific individual whose behavior you want to change. I'll group the tips into 3 principles:

1. Work the relationships
2. Motivate and inspire
3. Be practical

Work the Relationships

I can sometimes influence someone with whom I do not have a strong relationship, but it's a steep hill to climb. I always start by understanding, building, and leveraging relationships.

• Align around something shared. Find something in common with your target. It could be anything from shared values (e.g., we both care deeply about the future of our organization), shared goals (e.g., we both want to meet the June 1stdeadline), or even something completely unrelated to work (e.g., we both love Louis Armstrong's early recordings). The more specific you can get, the better.

• Understand the web of relationships. Everyone is influenced by someone else. Find out who your target trusts, obeys, follows, or listens to. If you can't directly influence your partner, find the path between you and your target. If your target is Alice, and Alice reports to Bernice, you need to influence Bernice. Maybe you have no influence over Bernice, but Bernice trusts Carlos, and Carlos has great respect for you. Once you've figured out this path of influence, you can get Carlos to talk to Bernice to give Alice an assignment.

• Identify the saboteurs; defuse the bombs. Take some time to think through who may oppose your work and how they might wreak havoc. Is there someone who will tell your target not to listen to you? Is there someone in a position to make your target's efforts ineffectual? If you don't know, ask someone who does know. Then make an explicit plan for how to neutralize the negative impact. By far the most powerful way to do this is to convert your detractor into your champion. Another tried and true method is to keep the detractor busy with something else--find a way to get them focused on some work that keeps them out of your way. This doesn't have to be cynical or Machiavellian--many people can serve their customers and company better by staying focused on things they can actually accomplish rather than sabotaging the work you're trying to accomplish.

How to demo software

The demo starts out nicely enough...

In a dark conference room, the vendor lays out a simple user scenario and starts walking me through the experience. But before he gets to the second click, he needs to mention the cool feature that he isn't clicking on, which leads to a short discussion of the underlying technology, which evolves into a few key points about their design process. When he finally finishes telling me about their unique value proposition and returns to the screen, I can't remember anything about the scenario, which is irrelevant anyway, because now he's running through the menu bar telling me about each of the features.

The thing that's screwed up about this story is that the story gets lost.

Stories are perhaps our most powerful tool when demo'ing software. As human beings, stories grab our attention--we can't help it. Stories are sticky. They stick in our minds much more than explanations, descriptions, or data, and once they get into our brains, all kinds of powerful things start to happen. We intuitively fill in gaps in the narrative; we make connections with other parts of our lives, and--very importantly--we remember. If you want your audience to remember what you said, tell a story.

A good story tends to have some typical components that can all be included quite easily in a software demo, even in a short demo that lasts only 60 seconds. Be sure to include:

1. The main character, your user--give him or her a name (let's use "Bored Bob")
   
2. The setting/context--when and where is Bob using the software (Bob's at home, sitting on his couch with his laptop on the coffee table and the tv on across the room)
3. The central conflict--every story needs a conflict, and for demos, the conflict is usually a problem the user is having that the software will help solve (Bob wants to go to a movie, but he doesn't know which movie to see)
4. The plot--what happens (Bob googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim.)
5. The resolution--in a demo, this is the "so what" part--what are the benefits to Bob and to the owners of the software? (Bob loves his movie and finds a new favorite musician on the soundtrack; my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale)

Five elements sounds like a lot, but it doesn't have to be. Here's what we ended up with in my simple example:

Bored Bob is at home, sitting on his couch with his laptop on the coffee table and the tv on across the room. He wants to go to a movie, but he doesn't know which movie to see, so he googles "movies near me" and clicks on my web site. He starts by browsing through a list of new releases, gets drawn into a couple of previews, purchases a ticket for the one he wants, and buys the soundtrack on a whim. Bob loves his movie and finds a new favorite musician on the soundtrack. And my movie site grabs a customer that would have otherwise gone elsewhere, and we make an extra $5 profit from the soundtrack sale.

A good demo of my web site will tell this story very early on and, very importantly, without interruptions. If I stop the story to explain a feature or why we did something the way we did, the story gets lost--much better to tell the story beginning to end, simulating Bob's experience on the screen, and then go back for explanations and details. When I'm done with the story, I can talk about the incredibly cool matching algorithm we developed to push the right movies to Bob, and the subtle up-sell techniques that prompted him to buy the soundtrack, and the projected increase in revenue due to these enhancements. Those are important things to tell my audience about, but they should never detract from the star of the show.

The star of any great demo is the end user experiencing the product.