The Trouble With Hierarchy

A few words on why hierarchy is in fact the enemy, and how a network of teams is a simple answer to a complex problem. Most of my beef with hierarchy is around learning: who gets to learn what and what lessons are prioritized by the org.

Hierarchy enriches leadership, but not how you think

Here's a normal-looking team, reporting to a senior leader. Let's imagine that these seven people are running seven different projects (with teams supporting them, or running them solo). They're reporting progress, insights, getting guidance from the leader, getting unblocked, etc., on some sort of cadence. Let's say that happens weekly.

From this group of people alone – not including any other pieces of business they're running with peers or working groups outside their team – the leader has seven sources of curated information; if they can keep track of all of the moving parts, they have an opportunity to get very, very smart about a wide-ranging set of topics.

This information asymmetry solidifies the gap between leaders and teams – they may get very good at their craft, but never at the next pace layer of the organization, and is an under-reported issue with hierarchical structures in a world where leaders are largely white men.

It's an incredbile privilege to be in the leader role, especially if you're doing a good job with management, and your direct reports feel relatively contented with their work. The amount leaders learn from teams drives a daily improvement in personal capability, knowledge, and business insight – if at the expense of making skills.

Hierarchy pushes teams to learn more about the organization than about their customer

In order to get things done more quickly, and at higher quality, you might organize capable people from different divisions and functions of the business into a multidisciplinary team. On paper, and perhaps even in person, they've got what they need to succeed. Marketing, Product, Finance, Legal, R&D, Comms, Supply Chain – some set of core roles that are necessary are in the room and ready to get something new out into the world.

But each is also accountable to a different person, on paper and in reality. They're pulled in the direction of their boss' incentives, not toward the customer need. The Supply Chain team-member may want to go along with the team and push for responsiveness at the cost of efficiency, but the entire Supply Chain organization would need to come along with them in this effort. A wholesale org-change effort would be needed to make that happen, but in the meantime we can make do if at very least the bosses are all aligned.

So we create a steering committee. [In the distance, rumbling.]

Unfortunately, this compounds the problem – next to nothing productive is going to get done, as the working team and the steerco will spend more time working on the idea of working, rather than delivering for customers.

In practice, this is what "good" looks like. The team making the big decisions is mostly preparing documentation and getting feedback from their bosses, not the market.

In this specific instance, you might imagine that the working team is focused primarily on the planning activity shown in the timeline above, and the regional/local teams are intended to receive and activate the plans. While the local team learns through commercial wins and losses in real time, leadership and middle management are learning primarily about the political process of getting a plan approved.

Now, to be clear: I understand why these structures are created.

As companies grow to a certain scale, unrewarded complexity grows to a point where it's no longer valuable to have different regions, brands, functions, acquisitions, etc. doing their own thing. In technology-poor or poorly networked organizations (perhaps because of their longstanding hierarchies), these functions aren't able to naturally find alignment or build platforms for one another to facilitate emergent alignment, so the only solution is expensive, brute-force methods to get the org in line.

Stable, customer-focused teams can accelerate everyone's learning, equally

Consider the alternative: a cohesive, coherent team, with a clear purpose and a clear customer. They're all learning from each other: how to work well with each other; lessons from each teammate's rich life experiences; tricks and techniques gathered along the way; mental models, values, and expectations. They're also learning about the customer, gaining deep empathy for the folks that use the product. They'll use that empathy to make a compelling product, and their deep relationships to move fast without breaking things – or each other.

As a happy bonus, this team is learning how to run itself as a business, albeit a small one. (That said, how many people worked at Instagram when they were acquired? What about WhatsApp?)

Consider that our team might be supported by a network of similarly shaped teams that see us as their customer, and are making products and services that make our lives easier. Now the organization is learning a great deal about customers – some of them internal! – and is forced to learn very little about the ins and outs of structure, approvals, and big-picture forward planning.

Functions and COEs of old might create internal products that are so compelling that they can be made public – the Accounting team may create something so special that it becomes a SaaS offering unto itself.

The role of Leadership, now, is primarily to make capital allocation decisions and operate as a thin investment layer on thousands of interconnected but independent enterprises – "teams" – rather than micromanage the details of a go-forward plan.