Leading from the Middle Part Two: Selling Ideas and Playing Politics

In an earlier post, I described how a transformational leader who is not at the top of the organizational hierarchy can still begin the process of driving change. I left off my description at a critical moment. The change agent has implemented changes within his or her scope of authority, carved out a sandbox for trying new ideas, and successfully completed a demonstration project or two. Now it’s time for that change agent to spread his or her cultural change across the enterprise by winning over senior leaders. This is when the change agent must take on two of the roles most foreign to IT: the change agent must become a salesperson and play politics.

“Selling” and “politics” make most technologists uncomfortable. I often hear: “I’m not good at playing politics” or “I’m an engineer, not a salesperson” from employees. Some even end their explanation of a new plan to me with, “…and then youcan take care of the politics.” But it’s important to understand that the change agent doesneed to sell ideas and “play politics” (not really a good term, thus the scare quotes), because selling and playing politics are simply examples of effective communication.

What “selling” means in this context is simply explaining to each leader how the changes will benefit the enterprise, particularly in the area that leader is responsible for. If you are selling your idea to the CFO, for example, you might want to explain why your idea will result in a better deployment of the enterprise’s capital and a lower risk profile that will make the auditors happy. To the CMO, you might want to talk about how your new approach will help the enterprise understand its customers better, Sales and politics are not things to be ashamed of practicing. They are about understanding the person you are communicating with.

The first step in selling ideas “up” the hierarchical ladder is to be clear on what you are asking for and why you’re asking that particular leader. This is precisely where many change agents go wrong. Do you want the CEO or the CFO to approve your use of Scrum? Do you want them to let you have daily standups and manage a backlog in Excel or Jira? If so, then you’re asking for the wrong thing from the wrong person. The CEO doesn’t much care, and he or she might not care to learn your jargon. You don’t want to get stuck in a theoretical argument about the problems with Waterfall, unless you wind up havingto have that argument.

What you do want is only the precise thing you need from that specific person in order to proceed with your transformation. And the way to get it is to explain why that ask will lead to benefits for the person you are asking. A simple way to prepare for this conversation is to take a piece of paper, divide it into two columns, and write your ask on one side and the benefit you are proposing on other side. Then have the conversation.

Of course, it’s not enough to just state the benefit—you have to provide evidence that the benefit will be obtained. This is where the results of the laboratory project and the support from the sponsoring business lead become important (see my earlier post). You should also be prepared to discuss how you are mitigating risks—and this is where your skunkworks and technical initiatives might become important (again, refer to my first post). But I have found that the most important thing is to get the “ask” right: “Ms. CEO, what I am asking for is that we divide our initiatives into smaller pieces, with a separate investment decision for each one.” “Mr. CFO, I want to move to the cloud and shift some of our CAPEX to OPEX.” “Ms. CIO, I want to eliminate the handoff between Dev and Ops. And here’s why and what the benefit will be.”

I have found that risk plays a surprisingly large role in these change management conversations, enough so that several of my recent blog posts have been devoted to this topic (see Reducing Risk in the Cloud by Overcoming the Status Quo Biasand Risk is Lack of Agility). First, it needs to be clear that the change leader is willing to take risk upon him or herself—this is a gauge of the change leader’s confidence in the idea and his or her willingness to energetically implement it. You advocate for change because you passionately believe that it will lead to good results, don’t you? Second, the more you can mitigate the risk of the change, the easier it will be to sell it. Finally, the clearer you can be about the risk of notchanging, the more urgency there will be behind the change. So plan out the risk conversation in advance.

A good way to give leaders confidence that the change is sound is to be able to cite other companies that have pulled off similar transformations successfully. Being the first company to do something is risky, but when—in the case of a DevOps transformation, for example—it has already been done by companies like Capital One, Nationwide, Disney, Target, Nordstrom’s, Nike, and…a very long list of others…it’s a lot less risky.

To show you what a sales conversation can look like, here is an exaggerated example of how I might approach a Line of Business (LOB) owner to get her participation in a laboratory project:

Me: “I know we haven’t prioritized your work much lately, and it seems like your “Bobblehead” initiative is really important to you.”

LOB Head: “That’s right.”

Me: “Well, do you mind if we do some work to help you out on that initiative? Is that OK?”

LOB Head: “Uh…yes?”

Me: “And is it OK if we start right away?”

LOB Head: “How can you do that?”

Me: “Don’t worry about it, it’s that new Agile IT thing. But we will need your best person, Norbert, working with us, and I know he’s busy.”

LOB Head: “Well, that’s OK. I can free up Norbert’s time if that’s necessary.”

Me: “By the way, instead of spending eighteen months on this, I think we can accomplish most of your goals in just three months. Is that OK?”

LOB Head: “Uh, sure.”

Me: “But don’t think it’s going to take three months to get some results for you. We’re actually planning to finish something every week and give it to you. For example, by next week I think we can deploy the Tap and Bobble feature for you to start using. Is all of that OK?”

LOB Head: “Uh, yeah. Yeah, good.”

Me: “Hey—I have an idea. Why don’t you and I meet with the project team next Wednesday to see what they’ve produced and maybe have a little celebration of their first deployment? IT will buy the doughnuts.”

LOB Head: (faints dead away)

See what I mean? If you know that what you’re doing is the right thing, these kinds of conversations become easy.

There are a couple of mistakes I see often in these conversations. The first is to become careless in wording just because we have our everyday way of saying things. “Fail fast” is an expression we use in IT to talk about accepting that some experiments will not give the desired results. But the CEO does not want failure. The CEO’s understanding of that term is very different from yours. Remember this and change your language accordingly.

A second common mistake is to focus on the internal mechanics of the new process. We IT folk can see how brilliant those mechanics are, but the senior leader cares only about what the implications are for them. You may be planning to have sprint reviews, refactor into microservices, or have a rubber chicken that squawks whenever a build fails. You may have some great ideas for experiments you will try to find the most effective architecture. But the CEO doesn’t care what experiments you try, just the end result.

Don’t say, “We have something called a backlog which gets reprioritized by a product owner.” Backlogs are not the point. Instead, try, “We adjust course frequently, based on what is most important to the enterprise. We can shift on a dime depending on your needs!” That is a senior leadership message.

Here are some more examples:

Please note that these messages are not some kind of marketing fluff or a sleazy way to hide what you are doing. They are a translation from mechanics-language into benefits-language, because benefits are what’s important to your audience.

In summary, your change conversations should be mapped out like this:

• Who are you talking to and what do they care about?
• What do you want from them?
• How does it benefit them?
• What are the risks and how will you manage them?
• What bad things will or might happen if they don’t give you what you are asking for?
• How certain are you that this is a good idea, and how much ownership do you take in its success?

Good—you are now a salesperson. Go ahead and “play politics!”

–Mark
@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value