People who work in software are smart people. We take pride in our ability to understand complex information and solve difficult problems. What about that other IQ, our Influence Quotient? Much of the work we do requires the help and cooperation of other people, and that means using influence. In this column, Esther Derby helps us listen in on two conversations to see what we can learn about improving our everyday influencing skills.
To some of us, influence is a dirty word. We think of influence peddling, organizational politics, or strong-arm tactics along the lines of "I made him an offer he couldn't refuse." But much of the work we do depends on our ability to work through and with other people, and that means influence. You don't have to be in charge to have influence; the elements of influence are available to us every day.
Let's eavesdrop on two conversations to see what we can learn about influence.
Brandon has been charged with designing a new table structure for the next product release. He has also been told to reduce the pain of installing new versions of the software for existing customers. He knows there are two requirements in the backlog that will require table updates: one requirement 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.
Brandon needs to convince Cindy that his idea is the right approach, so he stops by her desk and walks through his design:
Cindy: You can't do the tables that way, Brandon.
Brandon: Let me tell you why I designed it this way…
Cindy (cutting Brandon off): We'll have to write lots more code in the application with this table setup. Did you think of that?
Brandon: It might take another access call, Cindy, but in the long run, it provides much more flexibility.
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 design.
Cindy: Do you really want us to blow our project deadlines? Is that what you want?
Brandon (trailing off): No, of course, I don't want you to miss your deadlines…
Brandon felt like he was being pressed into a corner and it felt like Cindy was picking a fight.
After a couple more browbeatings from Cindy, Brandon gave up and redesigned the tables the way she wanted them. Arguing with Cindy wasn't worth it.
Cindy, however, felt a little rush of pride. She believed that she had exerted her influence and moved Brandon to see things her way.
Cindy is exhibiting one sort of influence, perhaps the 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. Is this a good time to walk through my design?
Tom: Sure, show me what you've got.
Jason walked through the design.
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 did the analysis 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. We're already on a really tight schedule.
Jason: Can you tell me more about that?
Tom: The project manager is sweating the deadline. We just got hit with a big new feature, and we don't need one more thing to make us late.
Jason: Oh, so your concern is that the extra coding and testing will make you miss your project dates.
Tom: Yep, I don't see how we can add this to the plate.
Jason: I see. Well, what if we talk to the project manager about the tradeoffs and see if we can shift something around to make this work?
Tom: Well, all right. I'll agree to have the conversation with the project manager.
Okay, so 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:
- When Jason approached Tom, he checked to make sure it was a good time to walk through the design before he started.
- Jason stated his goal explicitly, and tied it to something they both cared about, customer satisfaction.
- When Jason heard Tom's objections, he asked for more information rather than starting to explain his position.
- He acknowledged Tom's concern, and obtained Tom's agreement that he'd heard the concern correctly.
- He showed his willingness to help Tom overcome that concern by talking to the project manager.
So what's your IQ? What strategies do you use to work through and with people? When have they worked best, and when have they backfired?
