People who work in software are smart people who take pride in their abilities to understand complex information and solve difficult problems. But much of the work isn’t only about smarts. Creating most software requires the help and cooperation of other people. Telling, convincing, and winning arguments won’t work to bring people along, change their minds, or help them help you. That requires influence.

To some of people, influence is a dirty word. The word may bring up images of sleazy organizational politics or strong-arm tactics along the lines of “I made him an offer he couldn’t refuse.”

But influence doesn’t have to be slimy or manipulative. Simply put, influences is the capability to affect the opinions and actions of others. You don’t have to be in charge to have influence; the elements of influence are available no matter what your role.

Let’s eavesdrop on two conversations to see what we can learn about influence.

The Alpha team is working towards their next release. One of the major goals is to make it easier for customers to migrate their existing data when they install a new version of the software.

Brandon knows there are two stories in the backlog that will require table updates: one story is scheduled for this release and one for the next. He has figured out how to design the table to accommodate both requirements with one table change, which means customers will need to do only one database conversion, instead of two. Plus, they can roll out the improvement with this release rather than the following one.

Brandon wants to convince Cindy–who is working on the story that’s part of the current release– that his idea is the right approach. Brandon stops by her desk to chat about his idea.

We’ll pick up the conversation after Brandon’s sketched out his candidate design.

Cindy: You can’t do the tables that way, Brandon.

Brandon: Let me tell you why I this this will work, and be easier for the customer…

Cindy (cutting Brandon off): We’ll have to write lots more code with this table setup. Did you think of that?

Brandon: It might take another access call, Cindy, but it makes it much easier for the customer to install the new release.

Cindy: We’re going to have to write ten percent more code, at least. And then we’ll have to test it all. It’s a bad idea.

Brandon: I don’t agree, Cindy. It’s not going to take that much more code. And there are several advantages to this approach.

Cindy: Do you really want us to blow our iteration goal? Is that what you want?

Brandon (trailing off): No, of course, I don’t want us to miss our commitments…

Brandon felt like he was being backed into a corner and it felt like Cindy was picking a fight.

After a couple more brow beatings from Cindy, Brandon gave up.  Arguing with Cindy wasn’t worth it.

Cindy, however, felt a little rush of pride. She believed that her powers of argument had moved Brandon to see things her way.

Cindy is exhibiting one sort of influence, perhaps a sort that gives influence a bad name: browbeating and emotional manipulation.

Brandon is missing the influence boat, too. He didn’t ask Cindy what she needed or what her concerns were to see if they had some common ground.

Brandon made two other mistakes:

• He responded to Cindy’s objection by explaining his position rather than exploring her objection.
• He responded to her second objection by arguing the facts.

In another part of the country, Jason and Tom are working on a virtually identical project:

Jason: Tom, the customers are really screaming about having to convert their databases with every release. I think I’ve found a way to eliminate a conversion for the next release–three months earlier we thought we could. I think they’ll love it. Is this a good time to walk through my idea?

Tom: Sure, show me what you’ve got.

Jason walked through his approach.

Tom: Well, the way you have it set up, we’ll have to write another call every time we access this table.

Jason: Ah. That’s true. When I was fleshing this out, I saw there would be an extra call. Can you tell me more about the impact you think that will have?

Tom: Well, I’m worried about writing and testing those calls.

Jason: Can you tell me more about that? You’re not concerned about performance?

Tom: Performance shouldn’t be a problem (but we’d need to test that). I’m worried about Teddy. Teddy is sweating the release plan. He just added a a big new feature, and he’s worried about upholding his commitments to one of our key customers.

Jason: Oh, so your concern is about what we can fit into the release.

Tom: Yep, I don’t see what we can take off the plate to fit this onto the plate.

Jason: I see. Well, what if we talk to Teddy about the tradeoffs and see if we can shift something around to make this work?

Tom: Okay. Let’s to talk to Teddy. And let’s talk to the rest of the team. They may see something we’re missing.

Maybe Cindy would need Prozac to be this mellow. But most people will hear more and be willing to cooperate when they feel like you have heard their concerns and understand that your goals intersect with their goals.

Here’s what Jason did:

1. When Jason approached Tom, he checked to make sure it was a good time to walk through the design before he started.
2. Jason stated his goal explicitly, and tied it to something they both cared about, customer satisfaction.
3. When Jason heard Tom’s objections, he asked for more information rather than starting to explain his position.
4. He acknowledged Tom’s concern, and obtained Tom’s agreement that he’d heard the concern correctly.
5. He showed his willingness to help Tom overcome that concern by talking to the Teddy, the product owner.

in short, he connected, listened, learned, and found a potential ally.  That’s high IQ.