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 week's 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