The Frozen Middle—Part Two: Thawing

In my previous post I talked about the presumed challenge of the “frozen middle”—the middle managers who seem to resist transformation even when both the leaders of the organization and the hands-on executors want to see it happen. In that post I discussed the changing role of middle management and the critical role middle managers must play in the digital future—a role of creativity, inspiration, and the application of resources. What appears to be a “frozen middle,” I said, is the set of managers whose role and goals need to be redefined. The reason they seem to be resisting transformation is that, as good employees, they have continued doing what they believe they have been asked to do.

The old management model was based on a functionally siloed hierarchy through which tasks and budget were delegated; a structure based on “span of control”—the optimal ratio of managers to employees to ensure that the delegated functional tasks were actually performed. In the digital world, we want to engage cross-functional teams in accomplishing a shared business objective, rather than in merely performing a functional task.

So how do we get there from here?

One thing should be obvious: middle managers cannot participate in this new game if they are incentivized based on the old management model. If you want your middle manager to be an “engineer of victory,” you have to stop managing him or her to simply pass down centrally made decisions to subservient employees. You can no longer delegate tasks and evaluate the manager’s performance (formally or informally) based on the accomplishment of those tasks. For example, maintaining the middle manager’s former goals and adding a new task—move to the cloud or to DevOps, for example—just adds one more task that might or might not conflict with previous objectives.

Instead, you have to engage the middle manager’s ingenuity in accomplishing new goals whose impact can be tied to business success and which collectively with other goals supports the new ways of working. An important task for leaders today is to creatively find ways to redefine the goals and incentives of their middle managers to align with transformation. This is not easy.

Let me give a few examples of how I used this principle to work with middle managers to drive transformation at USCIS. The first example concerns Quality Assurance (QA), which plays an especially important role in government IT, acting as a check on IT initiatives to make sure they deliver the value that the public expects. Before our transformation, we had defined the role of QA in terms of inspecting systems before they went into production to make sure their quality was adequate, and inspecting documentation to make sure it met all of the government oversight requirements. Our QA leader jokingly referred to himself as “the Grinch”—his job as we had always defined it was to spoil the party when the developers thought they had finally finished building a system.

Of course, QA resisted a transformation where—as I told them—the developers would be able to deploy code any time they thought it was ready, with no opportunity for QA to review it or its documentation. This directly conflicted with their mission and their incentives! No amount of arguing that this was a best practice could convince them that this was a good idea.

The key, I found, was to agree on new objectives. First, we tackled the question of documentation. In the old model, QA’s job was to make sure that documentation was complete—that each required section of the official template had been filled in with enough information to satisfy our overseers. But in conversation, the head of QA and I agreed that concisenesswas also an important aspect of quality. The project teams had been spending a lot of time writing text that was never read, creating documentation that was repetitive and in places inconsistent. Some sections of the templates made no sense for the types of projects we were doing. So the goal of QA, we agreed, should be to make sure that every document was as shortas possible and didn’t include any irrelevant information, even if that meant leaving template sections blank.

Of course this wouldn’t please our government overseers, who expected every section to be filled out in great detail, but that was my job to take care of—a kind of impediment removal. QA’s job was to ensure quality, which included concision and effective use of time. So QA began to demand simplifications to documents rather than insisting that they be padded with unnecessary words, and I went off to negotiate with overseers on their behalf.

When it came to the quality of the code, we took a similar approach. The goal of QA, we agreed, was not to reject bad code, but to make sure that code was written to a high level of quality in the first place. The head of QA took this challenge back to his team and they came up with some great ideas on how to get there. For example, since the developers would be writing their own automated tests, QA decided to periodically review a sample subset of those tests to make sure that they were well-written and tested the right things. Because Agile processes should involve working closely with users, they reviewed team processes to see how users were included. Because peer code reviews were critical to our DevOps practice, they set up automated checks to make sure that all code was peer-reviewed.

The exciting part, the part that convinced me that we were on the right track, came a few months later when the QA lead came to me with a strange proposal. Since QA was responsible for making sure that the developers wrote good code, he said, they should also be in charge of training the developers. It was an odd idea—I had never heard of QA being responsible for training—but it was entirely consistent with what we were trying to accomplish. We tried it and the results were powerful.

After I left USCIS I found myself speaking at a DevOps conference and noticed that our old head of QA was speaking there too. It turned out that he was presenting a new idea his team had developed, one that involved looking for “faint signals” that might predict quality issues (I will write a blog post with more details later on). Middle management had continued to innovate after I had left the agency.

We could not have pulled off such a thorough transformation if QA hadn’t been so creative. What made it successful, I think, was engaging QA middle management by working with them to frame their goals and incentives differently. The same technique worked for engaging security and procurement. Security was given the challenge of ensuring security even in an environment where we could deploy code ten times a day. Procurement was given the objective of using a Lean approach to reduce our lead times for completing procurements from 6-36 months to one month.

Middle management is necessarily an impediment to change—a “frozen” middle—until their incentives and missions are redefined. That is because they are generally competent—they are working toward the objectives they have been given in the past. Their incentive has been to support the status quo, because it has made them successful in the past (sometimes arguable, but at least that’s the perception). Once success is achieved, everything organizes to reproduce it—culture, bureaucracy, organizational roles—and hardens over time. It freezes.

Melting the middle is an output of transformation, driven by the redefinition of roles and the application of creativity, not a prerequisite. The middle needs to have a new definition of success (its incentive) and help and support in accomplishing it. It must then find its own way to achieve that success.

And don’t forget, the new objectives must have a sense of urgency, or managers will wait them out. This too is a kind of competence that has led to success in the past. Rather than being diverted by every idea that flits through the mind of a more senior leader, we have all learned to wait and see if the idea goes away. Middle managers—all of us—have become highly skilled at sitting through meetings that don’t result in action. Still water freezes fastest.

–Mark

@schwartz_cio
A Seat at the Table: IT Leadership in the Age of Agility
The Art of Business Value
War and Peace and IT: Business Leadership, Technology, and Success in the Digital Age