Open Source and the Frozen Middle

If you’re like me, a term of art called the “Frozen Middle” meant nothing to you, except perhaps as a substance found inside a Klondike bar. It happens to be a business school term referring to middle management, specifically middle management that is “frozen” or not performing well. I first heard about it through a recent Twitter discussion and then looked up its source. The earliest reference I can find is from a 2005 HBS blog post, and that post references case studies from the automobile industry. I found the term intriguing because I am, in fact, middle management. And I have, as a matter of course, dealt with many many middle managers in the past. Some of those middle managers were exceptional, some were competent, and some were… hey, is that a Klondike bar??? “Great,” I can hear you say. “But what does this have to do with Open Source?”

The curse of broken middle management has plagued numerous large organizations throughout the years, and you can find an entire cottage industry around books, training materials and other things designed to “fix” the problem. Either these fixes are inadequate, people don’t listen or just don’t retain knowledge, or, as I believe is usually the case, middle management is really hard to do well. Upper executives have a luxury that middle managers don’t – they can spend all day looking at reports, creating power points, and thinking up crazy stuff for middle managers to do, sometimes by outright edict with little input from anyone else. Red Hat CEO Jim Whitehurst has touched on this subject in his book, “The Open Organization.” “OK!” I can hear you shout in your best internal monologue voice, “But what does this have to do with open source???!!!” I’m glad you asked, but there’s no need to shout!

If you’ve regularly read my articles – and really, why *wouldn’t* you? – you know that I’ve said that open source leveled the playing field of customers, partners and vendors (and individual developers and users). The old hierarchy of vendors and customers led to software that was bulky, overpriced and excessive, and usually left the customer with little choice in the matter. They could either buy bulky, overpriced thing from vendor A, or they could spend a lot of time and effort switching to the other bulky, overpriced thing from vendor B. This was the great innovation and “killer app” of open source. It upended that model entirely and allowed customers greater choice and flexibility. As I think about the frozen middle, I wonder if open source principles could be used to ameliorate that problem as well. This works well in engineering organizations, but similar tactics could work in other types of collaborative settings as well.

When you dive into the frozen middle problem and what can cause organization dysfunction, the topic invariably turns to the subject of “bureaucratic inertia.” At this point people usually shrug their shoulders, roll their eyes, and express exasperation, recommending that no one should beat their head against a wall in search of a solution. What is bureaucratic inertia, and what causes it? There are a couple of primary causes, some of which I’ve personally witnessed, and others I’ve read about in business case studies:

• Whiplash. How often do executives issue strategy edicts? How often do those change? I have a hunch that the more edicts issued per year, the less effective middle management tends to be. At some point, middle management begins to realize that their success at a particular job has more to do with managing day-to-day operations and performance metrics than paying close attention to any particular edict from upper management. 


• Ownership. When issuing a new strategy edict, what was the process of determining the planned execution of this edict, the goal of the edict, and the construction of said edict itself? Specifically, what role did middle management play in pursuing a particular edict? What about individual contributers? “None,” you say? Oops.


• Communication. How were the goals, execution and other aspects of the edict communicated to the rank and file? And how were their expectations and feedback communicated back up the bureaucratic food chain? To make the question simpler, let’s make the answer “yes” or “no”. Were these things adequately communicated up and down the org chart? No? Good luck, chumps!

Here’s where it gets interesting. What if internal projects were run just like any other open source project? The tooling for software engineering projects is probably more mature for this purpose, but the same principles could apply anywhere. It would serve the same objectives as open source did for the customer-vendor relationship. Now, instead of a strict heirarchy with little information ending up where it should, everyone in the organization collaborates, with information flowing where it should, whenever it’s requested. Think of it as equal parts Innersource, DevOps, and open source community management. Lest anyone fear that I’m suggesting an “Ark B” strategy for middle management, I believe that everyone in the organization has a role to play, including middle management. It’s not that there shouldn’t be hierarchy, it’s that hierarchy should be designed to function optimally.

In an open source collaboration scenario, edicts are not issued without close collaboration with those implementing the strategy. Strategies and implementation plans are developed transparently, with input from interested parties at every stage. This way, everyone owns it. In larger organizations, such initiatives can suffer from a glut of input, but open source projects have found ways to solve that problem. There is where a hierarchy comes in. In open source projects, these hierarchies are voted in by project members, with managers attaining their positions according to their contributions. This may not work in practice in many organizations, but managers can serve the same purpose. In an open source project, the manager’s job is to facilitate communication, unlock bureaucratic roadblocks faced by individual contributors, review their work, and use their influence to prevent stupid decisions both in upper management and from individuals. Upper management can benefit because they’re no longer divorced from the day-to-day experience, seeing more clearly the challenges faced by everyone else. Individual contributors benefit because they have more access to project leaders and, yes, can bypass middle management when appropriate. Yes, there’s a hierarchy, but it’s not rigid, and that’s important.

I’m going to stop here for this first post on the subject. There are several different directions I could go in a subsequent post or series, but I’d like to hear from the readers first. What are your experiences with middle management? Upper executives? Individual contributors? How did you push through bureaucratic obstacles? Did you have to “hack the hierarchy”? Let’s use this as the starting point of a conversation.