Influence Without Authority. Cohen Allan R.

software platform (and were rewarded for seeing that individual products worked as part of an integrated platform, which would reduce overall costs and reduce complexity).

      The new product was supposed to go live in December 2015. The marketing campaign had started, the sales team was ready to sell (and cared about the new products to help meet sales targets and achieve their bonus goals), but the tech team was way behind schedule. Despite this, the product team decided to showcase the incomplete solution to the entire sales force, thinking the demo would buy some time. However, the product crashed during the national sales demo!

      Millions of dollars had been spent, and emotions were running high. The product team blamed marketing, sales, and technology. The technology team blamed product and marketing. Even though everyone was from the same company, people treated each other as contractors, often blaming each other for breach of contract and trust.

      Sachin Bhat Is Asked to Step In

      A few months later, Sachin Bhat, an engineer in another division and a new MBA who had recently joined the platform team, was asked to lead the project, which included getting the finger-pointing product and technology teams to work together.

      What would you do?

      Before reading further, consider how you would go about tackling this messy, highly charged situation. How would you identify the core problems, gain the trust needed to get people back to work, and salvage the new product if possible or kill it if necessary?

      Here is Bhat's account of how he used influence to address the many challenges of gaining collaboration:

      Until then our platform team was not involved with the execution of this project due to other obligations. My first two weeks into the project was to understand the reason for failure from different perspectives – I interviewed product folks, engineers, project managers, marketing managers, program managers, and engineering managers. Because I wanted to understand the product and people, I was carefully observing the dynamics between people and quickly wanted to understand the “currencies” that I could trade with all of them.

      I spent two weeks talking to every single person, lowest to highest. All were good at pinpointing everyone else's issue. I wanted to understand power, who could influence the power holder, and be sure not to step on landmines. They had spent $140M; they all thought I would identify one person to blame it all on. I said “No, we all missed it.”

      I caught the problem. At the end I presented to my SVP [senior vice president] and said it was not tech capability, but that the process had been badly managed. The product team only knew products, didn't know how to run software development, and it was the same with the tech team. (Unlike with manufactured products, a product team has to “thin slice” a software project, not give the tech team the whole thing all at once, or they won't know how to tackle it and the problems until the last minute. By receiving the project in orderly, small, thin slices, the tech team can make steady progress and not be overwhelmed.)

      It was all blame games; every team blamed the other teams. They did not know how to prioritize. If I took a side, it would be a problem, because it would be stepping on toes.

      Both technology and product senior management had worked together elsewhere, so in the big meeting I couldn't publicly say who was right or wrong, because it was highly political. But I told my manager and he told the SVP offline.

      In the big meeting people were saying I would clean up the mess; I didn't like that; [I] knew I had to get everyone on my side. I had to be subtle, saying we would fix the problems.

      The VP [vice president] was happy because I was not stepping on his shoes. I gave him my observations and asked him to give the reports in all big meetings, and let him run the show. It wouldn't fly for me to say, “I would do it.”

      The product team in Los Angeles blames the tech team in Seattle all the time – I went back and forth. I kept saying, “Blame is not a help; we all win if this works or lose if it doesn't. Think of it as delivering a product together; not one side wins, and the other one loses if it fails.”

      Every time I visited the tech team I talked to every engineer; I asked about their families, took them to dinners. I wanted not to sound artificial, so they wouldn't feel threatened, or that I was out to get their jobs. After two [to] three months it worked. Now when I go they reach out to bring us issues, and there's no more talk about superior or inferior groups. They would tell me their concerns, which helped me understand worries within engineering. Since I have an engineering background, I often knew when they were approaching problems incorrectly.

      I wanted to understand the root issues. Then I would talk to the engineering manager and help him solve the problems. If you talk only to the managers, they just say that all is fine.

      I knew November–December would be a big milestone. The first three or four releases should be on time, even if we just do one thing, without bells and whistles. Weekly I gave quick updates to my VP and SVP; all four product releases I promised were on time. They were happy because that had never been done before. I wanted the perception that the process was working. We had a biweekly meeting just to tell what we were doing and going to do. Previously, the process was not transparent, which did not work.

      The previous day before the demo, we met sales district managers and they were totally skeptical about this product. We accepted their skepticism as understandable because of the history. After we conducted a successful hands-on demonstration meeting with 500 sales folks, they said, “You have transformed the product; we will sell it.” And they even gave me a huge shout-out.

      Also when the SVP was in town, I asked for a short meeting about how I was doing and watched the reactive body language. I am ambitious, so that way in the reporting process I could show my unique contributions without going behind my manager's back to brag. It was a byproduct of “just reporting on progress.”

      At the beginning, the marketing officer was completely negative because of the previous fiasco, but it worked in my favor: when I kept quiet, people asked me in front of my director why I didn't respond. I said, “I do not want to fight; my goal is to just deliver, that's my answer. Wait for two months then see what progress we have made.” After the two months, every time I see her, she says, “Oh, Sachin Bhat has done a great job.”

      This example, without all the detail of how Sachin did it, foreshadows many of the book's themes. Several individuals and groups are pursuing their own agendas. No one person or group has the correct answer and cannot be ordered to help. Collaboration is needed. Groups working at a distance can easily stereotype one another. Mistrust blocks open and honest communication, causing poor and costly decisions. Instead, careful listening and responsiveness are needed to regain sufficient openness to really understand the issues. The various parties must feel that they are gaining something they care about to get them to cooperate. Early successes lead to greater cooperation. Individual recognition has to come from accomplishment, not obvious self-promotion.

      With so much interdependence required, wielding influence becomes a test of skill. Going hat in hand to throw yourself at a colleague's mercy may work once or twice, but is seldom a powerful or effective option. At the other extreme, trying to bull your way through by sheer nerve and aggressiveness can be costly as well. Antagonizing crucial peers or superiors is a dangerous strategy that can easily come back to haunt you. So, what is the alternative?

      When you want to influence those you don't control, you will have to get to know them, figure out what they want, build reasonable trust so they will consider making exchanges, satisfy them, and slowly build cooperation. If you already have close relationships, mutual influence is a free-flowing byproduct that seems to happen naturally.

      Why an Influence Model?

      Aren't these points self-evident? And don't you use them already? “Yes” to both of those; when you already know how to influence individuals or groups to get needed cooperation, just do it. But if you are stuck or frustrated, can't figure out what is really wanted or don't care to give it, are having trouble connecting, don't seem to have anything to offer, or want to be certain how best to approach someone, then a systematic model can be incredibly helpful in making sure you have covered all the steps or make