Transforming Up and Down: Leading Change from the Middle

opensource.com

In several earlier blog posts, I discussed techniques for leading a digital transformation from the top of an organization. In the first of these posts, I discussed how to take organizational power—the power that comes from sitting high in the organizational chart—and, in an ironic twist, use it to lead the organization from a hierarchical, command-and-control model to a team-empowerment model. In the second postI talked about the martial arts learning framework of Shu-ha-ri and how it can be used to structure a top-down transformation.

But with many of the AWS customers I talk to, change is being driven from somewhere in the middle layers of the organization, and the challenge is often how to get support from those senior layers of management. I frequently encounter passionate, visionary leaders who understand exactly what their transformation should look like but who need to affect the behavior of those both higher and lower in the organization.

Although my role at USCIS primarily involved pushing change downward from the CIO position, I still had to influence agency leadership and those at DHS responsible for overseeing our IT activities. I also observed many employees within the IT organization as they were trying to get me on board with their ideas and what worked for them! As a participant in many cross-industry working groups, such as IT Revolution’s DevOps Enterprise Forum, I have had the opportunity to interact with many of the most successful drivers of transformation in large enterprises and to learn what worked for them. In this post I will share some of the ideas I have picked up from those experiences.

Break the Problem Down

The first step for a transformational leader is to consider carefully what they need organizational support for and what they already have the power to do themselves. What steps can they take without asking for anyone’s permission? If they believe in their own visions—and if they believe that they will get concrete business outcomes from their transformations—they should have faith that if they make changes within their own spheres of influence, they will produce tangible benefits for the enterprise. A transformational leader should have the confidence to move forward with these changes without needing external validation.

A good example: Often technical leaders have control over their own groups’ technical practices (of course!). It is unlikely that anyone will question their move toward good practices like continuous integration, automated testing, microservices, or containerization. If they are questioned, they can defend these as industry-wide best practices. Many of these techniques can be implemented cheaply and quickly, using common open-source software tools. I cannot stress enough how central to digital transformation these good practices are. Even by themselves, they will make the technical teams more agile, free them from some technical debt, and carve out some flexibility for the change agent to try new things. It’s true that bigger changes are necessary to take full advantage of the good technical practices, but this is a start that can be leveraged to drive those larger changes.

Broaden the Scope

The next step is for the transformational leader to push the boundaries of what is within her control, working to carve out a broader scope. The key word here is “skunkworks”: a group that flies under the radar of most of the company to try out new ideas. Perhaps there is extra budget that can be used; perhaps people and resources can be shifted because of the efficiencies found through those technical changes in step one. The skunkworks team might try out some new technologies or processes or might work on some set of business needs that are not otherwise being addressed, like retiring some technical debt. Ideally, it can surprise the company by suddenly releasing something unexpected and wonderful.

It is important that the skunkworks not be deceptive or sneaky. The skunkworks is not a way to hide anything or to get around company policies or approval processes. The key aspect of the skunkworks is that it is done with such a small commitment of resources—and therefore such a minimal risk—that it can proceed without an extensive approval process. It also must be consistent with the goals of the company and the scope of the change agent’s responsibilities. “Under the radar” simply means small and low risk enough that there is little interference.

In my role as the CIO of Intrax Cultural Exchange, I was able to take a skunkworks approach to putting together a small data analytics platform that quickly yielded some important insights that were useful to the rest of the business. It may be a slight exaggeration to say that we created an analytics tool to optimize the supply chain for au pairs that we were placing with families, but in a way, that was the vision we could demonstrate with our very basic tool. Because it was so unusual, it seemed necessary to have such a demonstration ready before approaching the rest of the business with the idea.

At USCIS my employees conducted some amazing skunkworks projects—below my radar, as it turned out. My favorite was “Network in a Backpack.” This was meant to address some of the challenges we had with our refugee program. Our agency periodically sent a number of Refugee Officers out to refugee camps, often in remote parts of the world, to interview refugees for admission to the United States and to collect their fingerprints for security checks. But connectivity could be difficult in some of these locations, constraining what our officers were able to accomplish.

One day my network infrastructure team came to my office with a small backpack and proudly dumped its contents onto a table. They showed me how the assorted pieces of hardware could be combined to create a ruggedized local area network, extremely secure (we sometimes worked in countries with hostile governments), that could find just about any form of internet connectivity that might be available in the area, finally defaulting to satellite if nothing else was available. It could withstand conditions in harsh climates and could be controlled remotely from our offices in the US. And it could be carried easily by a refugee officer in the convenient backpack. Without my realizing it, they had created “Network in a Backpack,” solving a critical business need.

Note my reaction, as a leader they were trying to influence: I was overjoyed. I thought it was the coolest thing ever, and I knew that the business unit would think so too—and be flattered that we had put this effort into solving their problems.

One final example: the “DID-IT” (Digital Innovation and Development) teams that we created at USCIS, which were in a way an institutionalized kind of skunkworks. They were intended to solve a problem: the proliferation of “shadow IT” projects in our distributed field locations. Our DID-IT teams made themselves available to the largest of these field locations to do whatever work was necessary, without a heavy centralized oversight process. The DID-IT teams were able to build many of the capabilities that would otherwise have become shadow IT systems, quickly and under the radar.

Get a Few Small but Critical Wins

The next step is to find a laboratory project. By this I mean a relatively small, generally (but not always) low-risk project that can be handled in the transformed way. This is a matter of convincing some progressive business unit leader to try the new approach within a defined scope. It is very important that this project be of short duration and lead to concrete business results. One approach is to seek out the iconoclastic business leader in the organization who thrives on change and disruption or is eager to quickly achieve business results. Another technique is to look for a corner of the business that is not well served by IT, perhaps because it is marginalized by the rest of the business. At USCIS, this was again the refugee program, which accounted for less than 1% of our agency’s total workload, and as a result, was rarely prioritized when deciding on IT investments.

The goal of the laboratory project is to build a happy partner or two who will vouch for the effectiveness of the approach, and to gather concrete data on the results that can be accomplished with the new way of doing things. These will both become important in the next step.

One quick side note. You might have noticed that I said the laboratory project is usually low risk. Actually, the best laboratory project is the highest risk one—the one that results from an urgent need that cannot possibly be met with the old way of doing things. Urgency in the USCIS environment could be something like a new presidential policy that had to be implemented in a short timeframe, a national security incident that had to be responded to quickly, or even the very visible failures of healthcare.gov or the OPM (Office of Personal Management) breach. If the old way of doing things cannot possibly respond effectively, that is a great opportunity for change that should be seized on. Urgency is the friend of the change agent.

Selling the Idea

On to the final critical step…and the next blog post. With the laboratory project in hand, with confidence and a strong vision, it is now time for the change agent to advocate for change on a larger scale and to try to get the support of senior levels of leadership. And that will be the subject of its own post.

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