The Frozen Middle And Agile Transformations

Frozen Middle Management depicted by a pair of frozen eyeglassesI was recently asked what in my experience was the most likely cause of gummed-up Agile transformations.  I didn’t hesitate in answering “the frozen middle.”  

Top-level management buys into a transformation because they hear faster, better, and more predictable. Teams buy in because it is simply more fun (I’m told “funner” isn’t really a word) and they get to build cool stuff. What about the folks between the teams and executive management? Middle management may be ill-prepared for what is needed from them in the course of a transformation.

The Frozen Middle

The “frozen middle” concept was described by Jonathan Byrnes in “Middle Management Excellence” in 2005. “[T]he essential idea was that whatever initiative top management decided the company would pursue, it would be slowed to a standstill by the unwillingness and inability of the company’s middle management team to carry it out.”  In the article, Dr. Byrnes goes on to talk about the importance of strong middle management and how they are absolutely critical to the success of an organization.

I’ve seen a few people in middle management who just didn’t want to have anything to do with an Agile transformation, but those are few and far between.  The vast majority want to see the company improve and thrive, and if Agile can help do that then they are all for it.  The problem, as I see it, is that they aren’t given the time or opportunity to get properly trained and gain experience in actual “live fire” practice before they are tossed in the deep end of the pool.  What’s worse, they are often expected to continue doing all that stuff they were doing before the transformation even if it is no longer applicable or can be replaced by something better.

Meet Pat, Director Of Product Management

Let’s take a look at a simple example. Pat is a director of product management in a large enterprise. The product managers reporting to Pat are responsible for the sales support system in the organization, with responsibility for about two dozen major applications. As is always the case, the user community is desperate for new features, and development is plagued with support pressures, slipping commitments, and turnover.

Pat has become a director because Pat has gotten good at coaxing the system to get things done. She maintains a dashboard for executive management on the health and status of projects, using “green, yellow, red” indicators; the dashboard has been based on waterfall methodologies.

Now Pat is part of a newly formed Agile Leadership Team guiding and assisting the organization in an Agile transformation as they shift to using a Scrum-based approach for their development process.  Pat’s dashboard, which essentially was indicating delivery of phase items against a committed timeline (percent complete) instead of actually delivered software, is no longer a useful measure of progress.  Now Pat is in the uncomfortable position of either recasting the new measures of progress into a format the execs are used to or getting the execs to be able to read and understand a new set of (more accurate!) measures.

What should Pat do? Pat isn’t lazy or stubborn here, but may still find it hard to move the organization to an Agile mindset when people outside of the engineering teams weren’t expecting they’d have to change too – it isn’t just the engineering organization that is affected.

3 Ways To Support Middle Management During An Agile Transformation

  1. Empathy — Let’s have some empathy for middle management.  They really want to do the right things, and most welcome new learning and approaches. There is a healthy amount of “picking up and letting go” where the self-organizing Scrum teams get comfortable picking up responsibilities and commitments, and management correspondingly lets go of chunks of their command and control. A question we answer from middle management often is “What do I do now that I’m not managing tactical work?”
  2. Training — Middle managers should also receive training on principles and practices before we let the teams dive in. If we just train the teams and management are left on the sidelines, then we’ve put management in the position of not knowing what is happening or why.  No one likes to be in this sort of quandary — and this may result in a “frozen middle.”
  3. Servant LeadershipAll of the management team needs to shift from tactical leadership to servant leadership. Use the available time to remove organizational impediments that the team cannot resolve on their own. This can include additional team members or restructuring teams (from component to feature.” Leaders should also focus on creating “safe space” for the teams to make commitments and learn from mistakes. Practice patience as teams gain confidence and pick up speed. This means changing your questions from “what did you accomplish today” to “what did you learn today?” In a company practicing Agile well, managers no longer have to drive teams to achieve results, but rather become enablers for development so the teams can hit their best velocity.  Managers can find their jobs become easier; data is readily available about how teams are doing, progress is demonstrable in the form of working software, and the self-organizing teams are making decisions that used to be awkwardly taken on by management. We are now seeing “faster” and “better” coming about because of these committed and energetic people delivering valuable products.

Middle management should also expect to be drivers in an Agile transformation.  They are the ones who can see the whole picture and how the parts work together, as well as directly affect changes in teams and groups.  The best approach, in my opinion, is for the Agile Leadership Team to use Agile to do Agile.  Perhaps use a Kanban board, visible to all (an “information radiator”), to manage the various work happening to move the transformation.  In this way, the whole organization gets to see what is happening, can get involved, and can see that leadership is committed to making the change a success.   

Join the discussion 3 Comments

  • Dave says:

    Here’s an example of what not to do. A QA manager tells testers that they need to tell developers to change something. It turns out that the QA manager has not consulted the development and product managers and gotten their commitment to make the change. Since most decisions are made by agreement within the Agile team, the tester meets resistance. When Agile team members are cooperating effectively, it is not helpful if their managers still sit in silos. Communication is vital not only among the members of the Agile team, but also between middle managers.

  • David Gardner says:

    Agreed! There are several feedback loops you mentioned in addition to the loop within the Agile team itself. Getting the other groups to self-organize, be transparent, and keep their communications flow going smoothly are some of the key aspects of an organization looking to become agile.

  • Moez Ben Dhahbi says:

    Hi, thanks for sharing this. I am convinced that a part of current mid managers will have to move to a what is called “servant leadership role” through (a lotf of) awareness & trainings and so
    However, an agile organization requires a way less “servant leaders” than current classic orgs requires managers. Especially in latin countries, where companies have been accumulating managers and management layers to reward/retain their employees.
    So IMO the real challenge is not to transform managers to “servant leaders” but to re-skill these managers to the roles highly needed in the big companies (around data, IT, Security and even compliance), that requires hard skills and knowledge that are not that easy to acquire for senior people and also will question the privileges they used to have with their position of managers.
    This is IMO one of the biggest challanges of agile transformations, the other one being the lack of handsight with the necessity to run this transformation quite quickly

Leave a Reply