Leading Change from Deep in the Org Chart

In earlier posts in this series, I talked about the challenges and techniques of driving change from a senior position in the organizational chart (Driving Change from the Top Down: Wielding Organizational Powerand Top-Down Transformation: Shu-Ha-Ri to Go Beyond Command-and-Control) and from a middle management position (Transforming Up and Down: Leading Change from the Middleand Leading from the Middle Part Two: Selling Ideas and Playing Politics).

This post is dedicated to change agents who are at the implementation level: executors—you know, the people who actually get things done! While many of the readers of this blog are CXOs and senior leaders, I’m hoping these ideas will help them spot people in their enterprises who are struggling to promote new ideas. And if you happen to be an implementor in an enterprise that has multiple layers of management and something of a hierarchical culture, then these suggestions may give you some ideas to work with.

Let’s consider the advantages and disadvantages of driving change from this position. On the plus side, you can actually implement changes yourself, which many in management cannot do. You are also responsible for the quality of your own work and your productivity, so in many cases you are free to make changes that demonstrably improve one or both of those things. On the minus side, you do not have direct control, or even much influence, over most of the organization, so scaling your changes is harder. You need to ask permission for many of the things you do, especially if they require money or go against current policies. So…let’s find ways to leverage those pluses and overcome the minuses.

The first principle is to start small. One of the leadership tricks that I have learned is to have a big vision—know where you are trying to go—but actually execute small, moving incrementally toward that vision. What is the smallest and quickest thing that you can do that will move the enterprise toward whatever you are passionate about changing? It will often be something that you can do without asking permission. So instead of fighting the bureaucracy by advocating for a major change—a transformation, which is a perceived risk to the enterprise—I would start small.

For example, if you are a software developer trying to move your organization toward DevOps, maybe the place to start is by writing automated tests for your own code using best practices for testing. We both know that if you do this right, it will reduce your development time and increase the quality of your work—so, probably, no one will object. Next add automated builds. Then perhaps change your branching structure. Then implement continuous integration. If tools are not available, see if you can use open source tools so that you don’t need a budget. Keep going until you hit an unmovable impediment.

The next step is to take advantage of the relationships you have built, particularly with your close teammates. To continue the DevOps example, perhaps you know a sys admin who likes to script changes. Perhaps you can get him or her to collaborate on writing deployment scripts. Or perhaps the team will agree to a better branching strategy and continuous integration. Again, continue until an immovable obstacle appears.

Now we must cross the chasm into selling ideas upward in the organization. The key is to figure out the next increment of change and what you need to get there. To sell it, keep two things in mind. You need to show a concrete benefit (if possible, through working examples) and you need to minimize risk for the manager. When I say a concrete benefit, I mean notsomething like “DevOps is a best practice” or “everyone else is using DevOps” (though these points do have some use—see below). Instead, something like this is more likely to work: “Hey, manager. You know how we keep taking down the system every time we do a deployment? Well, I measured and found that 60% of our deployments cause problems. But I think I can fix that. Companies using continuous deployment usually average less than 1%. Let me show you this working CD prototype.”

This positions the new idea as something that solves a real problem or adds a measurable benefit. But it is still necessary to minimize risk. The working prototype is a good risk mitigator, but it’s a good idea to imagine every “what if” that the manager might bring up. I say that as a very experienced manager full of “what ifs”.

Your case will be strengthened considerably if you can make it clear that you have invested personal time and effort and will continue to do so. It also reduces risk, as management will know that someone will continue driving the effort and taking on the challenges.

Let’s assume that you have had some success in your corner of the enterprise. Now it’s time to scale it across the enterprise. Eventually this might require selling ideas to senior leadership, but there are a few other paths to pursue first. In order to get a grassroots movement going, you might be able to create a “birds of a feather” group internally, set up brown bag lunches, or pair with others who are interested in your topic, thereby improving your practices. You can also attend meet-ups outside the enterprise to see how others have managed their transformations.

If you are able to get something of a movement going, you might then look at bringing in experts. Perhaps you can invite people with expertise to come speak or lead discussions. You might be able to seed the environment with books or get people to attend lectures from thought leaders. Now is the time to bring in ideas about “what everyone else is doing” or “what best practices are” in order to strengthen your case. What you’re doing is planting seeds and gently changing culture and established ways of thinking.

Finally, it will be time to take the ideas to senior leaders. It might not be necessary, but I have found that changes tend to ripple out only very slowly until you get that senior leader on board. You can introduce DevOps practices, for example, but if the enterprise doesn’t change how it chooses investments, plans initiatives, and measures success, then those DevOps practices will not lead to the business results you hope for.

Hopefully by this point you will have built grassroots support and support through a number of layers of management. When they arrive at this stage, many people think they should put together a business case that shows how the new initiative will have a good return on investment (ROI). While this is not necessarily a terrible idea, I would suggest that in many cases it is the wrong strategy. Any ROI justification case will have lots of assumptions, and senior leadership are experts at picking those assumptions apart. The ROI case is likely to seem too abstract on the one hand, or too detailed on the other.

Instead, I think it works best to focus on concrete pain points or objectives and show how your new ideas will address them. An ideal conversation would sound something like this: “Hey, big boss. I wanted to ask you to support a new initiative that we already have underway. I know that you sometimes think our IT approach doesn’t allow us to respond quickly enough to new business needs. Well, this technique we’re using seems to be helping with that. For example, in the BobbleHeadFeature case, we were able to deliver new bobbling patterns in just two weeks. Mr. Toymaker is really excited about it. We already have 20 teams using this new approach, and it seems to be working well. The thing is, we’re hitting a roadblock. What we really need from you is…”

If you can put a conversation like this together, then you have mastered the art of managing change upward through an organization. Congratulations! Let me know how it goes so that we can share your success stories with others in the same position!

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