Every so often it becomes popular for a certain type of thought leader to campaign against the existence of hierarchies in tech companies. Frequently, this is coming from founders or very early employee engineers. Basically, people with significant monetary interest in not sharing leadership responsibilities. In a slightly more informed, slower world, that would probably be enough to defeat the wave of thought pieces and blog posts. But this is not that world.

The reasons why this tends to catch on each time are kinda interesting, even if the causes for its cyclical resurfacing are distinctly not. Frequent readers of this terrible blog will by now know that I'm going to start with the structural approach, so let's get to that.

Reasons people might not think hierarchies are useful

• They don't understand the value proposition of management
• They don't understand the skill set of management
• They are in management and don't like to do management things
• They are not in management and would prefer to gatekeep persons unlike themselves from influence
• They've experienced unuseful hierarchies and not useful ones
• They're Libertarians and unused to considering how being in a group dynamic has tradeoffs that should result in an overall positive experience

I'm not going to address each of these specifically, and I won't address the last at all. No point. Let's instead take it as read that the value in having a hierarchy isn't obvious to most people, and it usually isn't obvious because they haven't seen it actually work. This is doubly more common (and frequently the source of the thought leadership cycle starting again is directly from) execs and founders who are in management roles and have no idea how to do that job, and as such don't value the job.

Many unfortunate readers will have experience with execs that are terrible at being execs, would be terrible at being managers, and because of that constantly do a bad job at both while making it difficult for anyone else to do a good job at either. Sorry.

How to derive value from your hierarchy

For each tier in a hierarchy, there is someone in the tier above, someone in the tier below, and peers at equivalent tiers in other sub organizations. Let's say we're talking about:

• VP
• Director
• Manager

Let's go through these a couple of times

• The Director owns EXECUTION of their org's functions and assigned SCOPE of RESPONSIBILITIES.
• Their VP owns providing necessary RESOURCES for success, and guidance for EXECUTION (how much varies depending on how far up we are in the hierarchy, at VP/Director, not very much)
• The Manager owns EXECUTION on the sub tasks of the Director's Org's functions, and the associated sub SCOPEs of the component RESPONSIBILITIES
• The Manager is owed necessary RESOURCES for success
• The Manager is owed guidance for EXECUTION from the Director
• The Manager is held accountable for success by the Director, possibly modulo resourcing
• The Director is held accountable for success by their VP, possibly modulo resourcing
• The Director (attempts to) hold their VP accountable for RESOURCES necessary for success of the assigned RESPONSIBILITIES

Hopefully you get the way these responsibilities and relationships stack across the levels. 

How hierarchies overlap with getting stuff done

OK so yea abrupt left turn but all the above is just context necessary to understand what this is about. It's this:

I'm usually having this conversation because someone is trying to contextualize what leadership does, how they should be interacting with a system, or there's something specific relating to career growth and responsibilities that we should cover

I also like to mention that this is sort of an idealized version of what it should look like, many of these parts are often missing or incomplete, and knowing where those voids of organizational ownership and accountability are can be a multiplier in effectiveness, because you can better understand why things are failing and look for implicit or invisible work that is helping things succeed or causing them to fail. Seeing real gaps where something isn't handled (or isn't handled well) because no one owns a tier of execution is incredibly illuminating.

This builds from the bottom up, with the rough following structure to the pyramid:

Learning Environment

This is the actual baseline work that needs to get done. Hands on keyboard, doing a thing. Usually executed as a component of learning your way around.

Technical Implementation

This is the things that surround the foundational technical work. You can't just type code into space, so there's some implementation stuff that you'll directly rely on. An example here is something like "we code in python, on an linux". 

Implementation Assumptions

These are the assumptions that are baked into the first two layers. Things like "I have a functional DNS system," or "I have access to other services that are outsourced to other teams". Roughly, it's an initial boundary layer between what is inside of your influence and what is outside of it.

Implementation Complexity

This is the meta-complexity of how those implementation assumptions interact. Someone can dramatically change the scope of work that needs to be done if they outsource a critical part of the service ownership, but are they pushing risk or concerns elsewhere that could lead to problems further up or down the chain. A common example of this is an executive saying "Well, this would be easy to do if we'd just use (other solution)," ignoring that implementation of that solution would be not viable for reasons that aren't in scope for the project. This is also known as Socializing the Risks and it's how a disturbing amount of people get ahead in life. 

Functional complexity

This is where we get into the broader scope of if the implementation serves meaningful goals - moving outside of the direct technical space and into "what function does this serve, and does it do it well?". You see examples of this being done poorly when can achieve the desired outcome, but it's incredibly toilsome to do so, or in the positive sense, when the system you're interacting with encourages a functional outcome with a minimum of overhead. 

Solution fit

Meta-change complexity

Long term vector impact

Organizational Health Impact

You're doing all of these things, but are you doing them in a way that is sustainable, healthy, and creates an environment that doesn't intrinsically burn people out? Does the organization recognize signs of overburdening and address them? Does it change when it sees them? Organizations by default want to consume people, have you made that more or less likely?

As the real fans in the chat know, I have to switch things up frequently or my ADHD gets bored. So, at this point, I'll cover the last 3 from the top down, because they're easier to explain that way. 

Execution on vision

The company has a vision of a thing it wants to achieve. The best SaaS provider on the planet, whatever. The executive leadership team is responsible for defining this and pushing that vision forward. 

Mission vectors

From that vision, there are specific areas of focus that leadership will prioritize and drive. You can't fix every problem at once, you can't go after every opportunity, this is the strategic negotiation and prioritization that executive leadership should be doing. What are they betting on? What are they giving up? The output of those conversations will be a set of mission vectors that they want to execute on. Something like "We want to capture this percentage of this part of the addressable market for our product". 

Company Function

This is how the company achieves the mission vectors - defining organizational level responsibilities, functions, how the company operates and manages moving forward, in pursuit of those goals. The decisions for things like reorgs to better move groups solving similar problems closer together, etc.

note bene: I may come back to this one to expand it some, and am interested in how it does/doesn't make sense to people.