The Fundamental Purpose of Middle Management: Context Down, Information Up

Middle management¹ gets a bad rap. Some of it’s deserved: middle management is often where the Peter Principle is most prevalent. But some of it is because middle managers – particularly new ones – don’t know the fundamental purpose of middle management: context down, information up.

Individual contributors have the most (and most accurate) information: nobody knows more about how a system works than the developers who wrote the code. This is why good engineering managers ask for outcomes but leave implementation details up to individual engineers. It’s hubris for a manager to believe they know more about the technical details than their staff who are doing the hands-on implementation. The best results come from trusting those with the most information to act on that information.

This gets more true the further you go up the organization chart. A director knows less about the systems under their purview than each line manager; VPs and executives even less. The further removed someone is from the hands-on work, the less accurate information they’ll have about that work.

However, these people at the top of the organization do have context. Executives should understand the greater context of the business: what the broad business goals and targets are, why those targets exist, how they fit into the broader long-term vision of the company. As you drop down the organization chart, context decreases. A director of engineering understands how the various teams under them fit together into the company’s larger engineering strategy but knows less about how that engineering strategy ties into, say, sales goals. An individual engineering manager will understand how their team fits into the director’s strategy, but might not know as much about the overall engineering organization. And so forth.

Here’s where the problem can arise: individual contributors have the most information, and so should be the ones making the day-to-day technical decisions. But those same ICs have the least context, and so those decisions will trend towards local optimization – what’s best for the individual and their direct team. Often this is fine, but sometimes it’s not: sometimes that IC would make a better decision if they knew some additional context.

For example, a team I was working with once spent several weeks improving authentication on an internal app. What we didn’t know was that another part of the organization was negotiating a deal with a single sign-on provider, with plans to roll out SSO to all internal systems. If we’d known about this, we would have chosen to scrap our custom authentication system and use the SSO provider instead. But we lacked the context, so we wasted some time. My boss, our director, failed to give us the necessary context.

This brings us back to the fundamental job of middle management: push context down, and information up. The job of a middle manager is to gather as much information from your reports as possible, synthesize it, and pass it up to their manager. At the same time, they should be collecting as much context from their management chain and peers, and passing that important context back down the chain. If you’re a middle manager this should be your guiding principle.