What do leaders who are skilled at navigating complexity know how to do? What do they do differently? What would you observe if a leader had these skills?

That’s the question Tom (author of the Innovation Tactics card deck) and John posed themselves in a recent conversation. These skills are typically lumped under “soft skills” and “culture fit”.

But what if we made them explicit?

We started by describing general behaviors (“What would we observe?”) and then wrote definitions in the standard “the ability to…” format. We tried to keep the descriptions reasonably lingo-free.

We also included sample interview questions just in case you might want to try to hire people who have these capabilities or prepare for an interview at a company that might be looking for someone with these capabilities.

Note: In this post we used the word “capabilities” because while individuals shape their environment, many of these capabilities emerge as properties, behaviors, and “abilities” of groups of people—not single individuals.

• Accept We Are Part of the Problem

• Encourage New Interaction Patterns

• Patient Divergence

• Identify Plausible Contributors / Multiple "Causes"

• Power of the Present

• Blend Diverse Perspectives

• Patience and Self-Repair

• Anticipate Effects

• Curiosity and Light Touch

• Both/And

• Intervene Safely

• Abduction and Intuition

• Accept Diverse Strengths and Skills

• Collaboratively Sense and Shape

• Coherence vs. Alignment

• Plant Seeds—Watch Them Grow

• Tailor Ways of Working

• Facing Uncertainty

Accept We Are Part of the Problem

The ability to recognize and accept one's role in creating, contributing to, or perpetuating the current situation.

Interview Question:

Can you share a specific instance when you recognized your contribution to a problem? What led to this realization, and how did it influence your actions in the future?

Encourage New Interaction Patterns

The ability to encourage new interaction patterns within an environment rather than solely attempting to change (or remove) individuals. Help individuals connect and become exposed to new information and experiences.

Interview Question:

Describe a situation where you facilitated new ways for people to interact or share information. Or a situation where you exposed people to new kinds of information or experiences. What prompted you to make the change, and what was the outcome?

Patient Divergence

The ability to encourage productive divergence and resist the urge to converge on a solution or path forward prematurely. Fostering an environment conducive to creative exploration and following multiple "threads", allowing alignment to happen without forcing it.

Interview Question:

Tell me about a time when you guided a team through a complex issue without rushing toward a solution. How did you manage this process, and what led to finally deciding on a path forward?

Identify Plausible Contributors / Multiple "Causes"

The ability to identify multiple factors that could plausibly contribute to a problem, and to hold them all in mind even when some may seem contradictory. This includes resisting the urge to try to isolate a single root cause explanation.

Interview Question:

Discuss a complex problem you've encountered with numerous contributing factors. How did you tackle this complexity, and what was your method for deciding what to do next?

Power of the Present

The ability to harness the potential in the present context and situation instead of defaulting to identifying an idealized future "goal state" and "gap" as the only viable path to improvement. Starting where things are now and exploring adjacent options, instead of focusing solely on what we would ideally like the situation to be. The ability to identify and learn from what is working in the present and amplify that to overcome obstacles (versus focusing solely on what is broken, who is struggling, etc.)

Interview Question:

Often as leaders we struggle with the tension between two extremes. At one extreme, we push for a big leap towards our opinionated vision about where we want to get to. At the other, we start where we are right now, figure out what’s working, and take small steps to change the present situation. Can you describe a situation where you needed to explore this tension?

Blend Diverse Perspectives

The ability to seek diverse perspectives, especially those that challenge our beliefs and defaults. Resist seeking to be the most informed. Realize that the person who is most wrong in any situation is the one who believes they have the most holistic view. Instead see the blending of perspectives as a source of multiple possibilities, enabling many paths to emerge.

Interview Question:

Can you tell me about a time you needed to make space for many diverse perspectives, including those that you found particularly challenging? How did that inform collective decisions and actions moving forward?

Patience and Self-Repair

The ability to patiently let certain situations play out and "fix" themselves over time instead of repeatedly intervening.

Interview Question:

Can you share an example of a time you chose not to intervene in a situation, allowing it to resolve on its own? What informed this decision, and how did it turn out?

Anticipate Effects

The ability to anticipate (but not necessarily predict) the possibility of emergent behaviors and downstream Nth-order effects. Accepting that unintended effects are the rule, not the exception, we need to scan the situation for signals continuously.

Interview Question:

Can you tell me about a time you needed to try to anticipate the unintended side effects of a difficult decision? What did you watch out for?

Curiosity and Light Touch

The ability to approach situations with curiosity and a "light touch”. This means resisting the impulse to judge and act, while creating space to explore the thoughts and feelings that come up.

Interview Question:

Describe a moment you caught yourself making a snap judgment and instead opted for curiosity. What prompted this change in approach?

Both/And

The ability to recognize and appreciate the interdependence of opposing forces or ideas, understanding that many situations are not about choosing between either/or but navigating the both/and of seemingly contradictory elements. Avoid simplifying complex issues into strict trade-offs.

Interview Question:

Can you tell me about a time you faced something that looked like a simple trade-off on the surface—an either/or situation—but it turned out to be a both/and situation? How did you navigate the situation?

Intervene Safely

The ability to intervene in a situation in ways that minimize the chance of unsafe and harmful side effects and maximize the chance that positive behaviors, signals, and patterns will emerge. When harmful things emerge, the ability to quickly dampen the negative effects. When good things emerge, the ability to "amplify" and sustain those things. While we can hone this skill, it does not guarantee success or that we will be consistently right.

Interview Question:

Can you tell me about a time when you and your team tried out a new way of working, interacting, or behaving? How did you decide what to try? How did you figure out whether to double down or change again?

Abduction and Intuition

The ability to balance deduction and logic with abduction and intuition. The ability to "think outside" a narrow set of logical and obvious conclusions given a limited data set. Tapping into the human ability to make intuitive leaps given a "mess" of patterns.

Interview Question:

Can you share details about when you needed to balance logic with intuition? What was the process and outcome? How did you involve others? How did data play into this, or not?

Accept Diverse Strengths and Skills

The ability to accept and value strengths and views we do not personally hold or value. Understanding that we are not omniscient when it comes to recognizing skill and influence, and may unintentionally devalue important aspects of an individual or team.

Interview Question:

Can you tell me about a time you needed to assess strengths and skills unfamiliar to you and where there was a risk of devaluing those skills because they didn't match what you value? How did you approach the assessment?

Collaboratively Sense and Shape

The ability to engage others in making sense of and shaping the environment. Resisting the impulse to simplify problems (“we just need to ...”), or the urge to control or “own” the interpretation of a situation.

Interview Question:

Can you tell me about a time when you involved other people in making sense of a problem and then worked with them to shape the environment to allow progress to happen?

Coherence vs. Alignment

The ability to seek coherence instead of alignment—setting boundaries and "no go" areas but encouraging people to explore broadly and in multiple directions simultaneously within those boundaries. Acknowledging that forced alignment is fragile, and that generally coherent actions are resilient.

Interview Question:

Can you tell me about a situation where you were tasked with getting people to take action, and you did it without forcing everyone to align on every detail? How did you determine a generally coherent direction without defining an idealized end state?

Plant Seeds—Help Them Grow

The ability to see output as something organic that is planted/seeded and grows and evolves, not as something structured that is planned, built, and completed. Hold scope lightly, and use time as an enabling constraint instead of a requirement container.

Interview Question:

Can you tell me about an example demonstrating your approach to balancing the certainty of requirements, your use of timeboxes and timelines, and the potential for new, unexpected (and valuable) things to emerge?

Tailor Ways of Working

The ability to tailor ways of working to the situation and nature of the challenge. Based on context, mix and match:

• Simple and get it done

• Big and ordered plans

• Experiment to achieve a predefined outcome

• Looser diverse experiments, observing for emergence

…with an understanding that when humans are involved, you may want to lean towards the latter options. 

Interview Question:

Can you share some contrasting examples of how you tailored your and your team's way of working based on the nature of the challenge? How did you shift how you approached planning and execution?

Facing Uncertainty

The ability to balance A) gravitating towards the most uncertain parts of a situation and B) seeking the comfort/momentum of making "quick win" progress with the better-known and more familiar parts. Seeing uncertainty as a signal of opportunity and supporting an environment that is friendly to tackling complex challenges (vs. trying to make it "simple").

Interview Question:

Can you describe a time when you needed to balance quick wins with tackling a key area of uncertainty? What was your approach? How did you support your team and enable progress and learning?

Notes

1. Before using the questions in a real interview, we recommend discussing these capabilities internally and answering the questions. Are these capabilities valued in your company? Do people who exhibit these capabilities thrive or encounter challenges? How does the culture of your company influence how these capabilities manifest? What words do you use to describe these things?

2. We likely used more jargon and theory than we should have in this post. We apologize. The ability to lead with accessible language and practical application is a capability we are working on!

3. Describing explicit capabilities is a minor crime against complexity. These capabilities are not inherent in individuals but are intertwined with the environment and relationships. We realize that people deep in the community will take us to task. Feedback appreciated.

4. There are very few contexts where you want to use these approaches with everything you do. You’d burn out your team. We noted this in the “Tailor Ways of Working” capability. We indexed on complex problems and environments for this post, but you’ll always have a distribution.

5. Many companies have evolved ways of handling complexity without doing it explicitly, using jargon, or labeling techniques (using the word “complexity”). The capabilities listed above may be considered triggering or foreign to you or others in your company. Keep that in mind when discussing this post. Before concluding that your company “doesn’t do this,” ask yourself how you achieve these things in your way and context.

I have been thinking a lot about organizational design lately and how it relates to how we collaborate and how managers/leaders collaborate.

I have come to understand three principles:

Principle #1: Hierarchical Collaboration Parity

To be sustainably successful, the level of collaboration and alignment among managers or leaders in an organization must be equal to or greater than the level of collaboration required among their respective front-line team members to complete a task successfully. 

As a corollary, the effectiveness of an organization is rate-limited by the available bandwidth to build close, collaborative relationships or by organizational design decisions that facilitate more transactional relationships. This principle applies across all levels of the organization. Teams can make do, but not for extended periods (see Principle #3).

Principle #2: Alignment and Work Style Gaps

Building on Principle #1, three critical gaps constrain team effectiveness.

1. The divergence between leaders' perceived level of alignment and their actual degree of alignment

2. The mismatch between the level of alignment among leaders and the alignment level required by the real-world demands of the task at hand

3. The mismatch between the level of collaboration required to do the task at hand and the practical constraints of the environment (e.g., the ability to work together closely)

These gaps collectively limit the potential for success, representing a disconnect between leadership's understanding and the practical realities front-line teams face. Teams can pragmatically adapt (see Principle #3 below), but this approach is fragile.

To improve, you have to close these gaps.

Principle #3: Elephants and Front-Line Pragmatism

Organizations are optimized to avoid confronting deep-seated tensions or 'elephants in the room' at the leadership level. This avoidance manifests in front-line teams having to navigate these unaddressed challenges in their daily work pragmatically. 

This is a double-edged sword: on one hand, it showcases the adaptability and resourcefulness of humans. Humans naturally adapt by bending official rules and policies while adhering to the spirit of "doing their best".

In situations where clear alignment from leaders is absent and escalating things don't work, teams resourcefully 'figure it out' through informal adaptations and agreements. However, this approach invariably leads to increased stress and sub-optimal outcomes. The working relationship is often fragile—when breakdowns occur, they escalate with damaging results.

Ashby's Law

These principles will all seem familiar if you are familiar with Ashby's Law. Ashby's Law, also known as the Law of Requisite Variety, states that to manage a system effectively, a control system must have at least as much variety as the system it is managing. Note how this relates to our three principles:

1. The variety in responses and strategies at the managerial level must match the complexity and variety of challenges faced at the front-line level. Managers can't have a transactional relationship if their teams have highly collaborative relationships.

2. If leaders are not truly aligned with the realities of the front-line work, they cannot provide the necessary variety of responses to manage these challenges effectively. When there is a blow-up, they'll respond with quick fixes.

3. Front-line teams adapt and create workarounds for challenges, often without adequate guidance or alignment from leadership. The front-line teams are increasing their variety of responses to match the variety of challenges they face. However, if this increase in variety is not matched by a corresponding increase in variety at the managerial level, it leads to suboptimal outcomes.

4. For an organization to navigate complex challenges effectively, it needs diverse communication methods that match the complexity of its internal and external environments.

Just Trust Each Other More

Leaders and managers are frequently bombarded with advice emphasizing trust and accountability. However, this advice often overlooks the hard limits on the number of deeply collaborative and trusting relationships we can realistically maintain. Our bandwidth as humans is limited. This cuts to the definition of “Team” itself. Patrick Lencioni's concept of a "first team" is valuable, but there are limits to the size of a team, and limits to the efficacy of a team if it is is one of many teams someone is a member of.

Calls for increased trust, greater flexibility, or enhanced accountability tend to ignore these human constraints and the realities of complex work environments. We expect escalating levels of 'heroism' from middle management in juggling these competing demands. Yet, as a company grows and becomes more complex, managing (and harnessing) this complexity effectively is the real challenge.

The answer?

1. Encapsulate complexity to your advantage. Make sure people can collaborate closely when the work requires it.

2. Establish clear transactional relationships and interfaces between groups that don't require intensive collaboration. Good walls make good neighbors.

3. Make sure that managers and leaders maintain relationships that mimic the relationships required by the people doing the work.

4. If possible, genuinely simplify our business processes—true simplification, not just in name.

Article URL: https://fly.io/blog/macaroons-escalated-quickly/

Comments URL: https://news.ycombinator.com/item?id=39204314

Points: 157

# Comments: 102

I recently joined a startup to run an engineering org of about 40 engineers. My title is VP Engineering. However, I have been having lots of ongoing conflict with the CEO (a former engineer) around whether or not I am allowed to have or hire any dedicated engineering managers. Right now, the engineers are clustered into small teams of 3-4, each of which has a lead engineer — someone who leads the group, but whose primary responsibility is still writing code and shipping product.

I have headcount to hire more engineers in the coming year, but no managers. My boss says we are a startup and can’t afford such luxuries. It seems obvious to me that we need engineering managers, but to him, it seems just as obvious that managers are unnecessary overhead and that all hands should be on deck writing code at our stage.

I don’t know how to make that argument. It seems so obvious to me that I actually struggle to put it into words or make the case for why we should hire EMs. Help?

— Unnecessary Overhead(?!?)

Oh boy, there’s a lot to unpack here.

It is unsurprising to me that your CEO does not understand why managers exist, given that he does not seem to understand why organizational structures exist. Why is he micromanaging how you are structuring your org or what roles you are allowed to fill? He hired you to do a job, and he’s not letting you do it. He can’t even explain why he isn’t letting you do it. This does not bode well.

But I do think it’s an interesting question. So let’s pretend he isn’t holding your ability to do your damn job hostage until you defend yourself to his satisfaction.

I can think of two ways to make the case for engineering managers: one is rather complicated, from first principles, and the other very simple, but perhaps unsatisfying.

I personally have a … vigorous … knee-jerk response to authority; I hate being told what to do. It’s only recently that I’ve found my way to an understanding of hierarchy that feels healthy and practical, and that was by looking at it through the lens of systems theory.

Why does hierarchy exist in organizations?

It makes sense that hierarchy comes with a lot of baggage. Many of us have had bad experience with managers — indeed, entire organizations — where hierarchy was used as a tool of oppression, where people rose up the leadership ranks by hoarding information and playing dominance games, and decisions got made by pulling rank.

Working at a place like that fucking sucks. Who wants to invest their creativity and life force into a place that feels like a Dilbert cartoon, knowing how little it will be valued or reciprocated, and that it will slowly but surely get crushed out of you?

But hierarchy is not intrinsically authoritarian. Hierarchy did not originate as a political structure that humans invented for controlling and dominating one another, it is in fact a property of self-organizing systems, and it emerges for the benefit of the subsystems. In fact, hierarchy is absolutely critical to the adaptability, resiliency, and scalability of complex systems.

Let’s start with few basic facts about systems, for anyone that may be unfamiliar.

Hierarchy is a property of self-organizing systems

A system is “a network of interdependent components that work together to try to accomplish a common aim” (W. Edward Deming). A pile of sand is not a system, but a car is a system; if you take out its gas tank, the car cannot achieve its aim.

A subsystem is a collection of elements with a smaller aim inside a larger system. There can be many levels of subsystems that operate interdependently. The subsystems always work to support the needs of the larger system; if the subsystem instead optimizes for its own best interests, the whole system can fail (this is where the term “suboptimize” comes from ).

A system is self-organizing if it has the ability to make itself more complex, by diversifying, adapting, and improving itself. As systems self-organize and their complexity increases, they tend to generate hierarchy — an arrangement of systems and subsystems. In a stable, resilient and efficient system, subsystems can largely take care of themselves, regulate themselves, and serve the needs of the larger system, while the larger system coordinates between subsystems and helps them perform better.

Hierarchy minimizes the costs of coordination and reduces the amount of information that any given part of the system has to keep track of, preventing information overload. Information transfer and relationships within a subsystem are much more dense and have fewer delays than information transfer or relationships between subsystems.

(This should all sound pretty familiar to any software engineer. Modularization, amirite?? )

Applying this definition, we can say that a manager’s job is to coordinate between teams and help their team perform better.

The false binary of sociotechnical systems

You’ve probably heard this canard: “Engineers do the technical work, managers do the people work.” I hate it. I think it misconstrues the fundamental nature of sociotechnical systems. The “socio” and “technical” of sociotechnical systems are not neatly separable, they are interwoven and interdependent. There is actually precious little that is purely technical work or purely people work; there is a metric shitload of glue work that draws upon both skill sets.

Consider a very partial list of tasks done by any functional engineering org, besides writing code:

• Recruiting, networking, interviewing, training interviewers, synthesizing feedback, writing job descriptions and career ladders
• Project management for each project or commitment, prioritizing backlog, managing stakeholders and resolving conflicts, estimating size and scope, running retrospectives
• Running team meetings, having 1x1s, giving continuous growth feedback, writing reviews, representing the team’s needs
• Architecture, code review, refactoring; capturing DORA and productivity metrics, managing alert volume to prevent burnout

A lot of this work can be done by engineers, and often is. Every company distributes the load somewhat differently. This is a good thing! You don’t WANT an org where this work is only done by managers. You want individual contributors to help co-create the org and have a stake in how it gets run. Almost all of this work would be done more effectively by someone with an engineering background.

So you can understand why someone might hesitate to spend valuable headcount on engineering managers. Why wouldn’t you want everyone in engineering to be writing and shipping code as their primary job? Isn’t that by definition the best way to maximize productivity?

Ehhh…

Engineering managers are a useful abstraction

In theory, you could make a list of all the tasks that need to be done to coordinate with other teams and have each item be picked up by a different person. In practice, this is impractical because then everybody would need to know about everything. One of the primary benefits of hierarchy, remember, is to reduce information overload. Intra-team communication should be high-bandwidth and fast, inter-team communication should be more sparse.

As the company scales, you can’t expect everybody to know everyone else; we need abstractions in order to function. A manager is the point of contact and representative for their team, and they serve as routers for important information.

Graph theory: for each of n engineers to be connected ("aligned") w each other you need n(n-1)/2 links, i.e. you need 780 interactions just to keep consistency. Without a few engineering managers (and arks) he is allowing velocity to build up tech debt at blazing speed.

— HurtingBrain (@HurtingBrain) January 5, 2024

I sometimes imagine managers as the nervous system of the company body, carrying around messages from one limb to another to coordinate actions. Centralizing many or most of these functions into one person lets you take advantage of specialization, as a manager builds relationships and context and improves at their role, and this massively reduces context switching for everyone else.

Manager calendars vs maker calendars

Engineering labor takes concentration and focus. Context switching is expensive, and too many interrupts can be fatal. Management labor consists of context switching every hour or so, and being available for interruptions throughout the day. These are two very different modes of being, headspaces, and calendar schedules, and do not coexist well.

In general, you want people to be able to spend most of their time working on things that contribute to the success of the outcomes they are directly responsible for. Engineers can only do so much glue work before their calendar turns into Swiss cheese and they can no longer deliver on their commitments. Since managers’ calendars are already Swiss cheese, it’s typically less disruptive for them to take on a larger share of glue labor.

It isn’t up to managers to do all the glue work, but it is a manager’s job to make sure that everything that needs to get done, does gets done. It is a manager’s job to try to line up every engineer with work that is interesting and challenging, but not overwhelming, and to ensure that unpleasant labor gets equitably distributed. It’s also a manager’s job to make sure that if we are asking someone to do a job, they are equipped with the resources they need to succeed at that job. Including time to focus.

Management is a tool for accountability

When you’re an engineer, you are responsible for the software you develop, deploy, and maintain. When you’re a manager, you are responsible for your team and the organization as a whole.

Management is one way of holding people accountable for specific outcomes (building teams with the right skills, relationships, and processes to make good decisions and build value for the company), and equipping them with the resources (budget, tools, headcount) to achieve those outcomes. If you aren’t making building the organization someone’s number one job, it won’t be anyone’s number one job, which means it probably won’t get done very well. And whose responsibility will that be, Mr. CEO?

There’s a real upper limit to what you can reasonably expect tech leads, or engineers, or anyone whose actual job is shipping software to do in their “spare time”. If you’re trying to hold your tech leads responsible for building healthy engineering teams, tools, and processes, you are asking them to do two calendarily incompatible jobs with only one calendar. The likeliest scenario is that they will focus on the outcomes they feel comfortable owning (the technical ones), while you pile up organizational debt in the background.

In natural hierarchies, we look up for purpose and down for function. That, in a nutshell, is the more complicated argument for why we need engineering managers.

Choose Boring technology Culture

The simpler argument is this: most engineering orgs have engineering managers. That’s the default. Lots of people much smarter than you or me have spent lots of time thinking and tinkering with org structures over the years, and this is what we’ve got.

As Dan McKinley famously said, we should “choose boring technology“. Boring doesn’t mean bad, it means the capabilities and failure conditions are well understood. You only ever get a few innovation tokens, so you should spend those wisely on core differentiators that could make or break your business. The same goes for culture. Do you really want to spend one of your tokens on org structure? Why??

For better or for worse, the hierarchical org structure is well understood. There are plenty of people on the job market who are proficient at managing or working with managers, and you can hire them. You can get training, coaching, or read a lot of self-help books. There are various management philosophies you can coalesce around or use to rule people out. On the other hand, the manager-free experiments I’m aware of (e.g. holacracy at Medium and GitHub, or “Choose Your Own Work” at Linden Lab) have all been quietly abandoned or outgrown. Not, in my experience, because leaders went mad for power, but due to chaos, lack of focus, and poor execution.

When there is no explicit structure or hierarchy, the result is not freedom and egalitarianism, it’s “informal, unacknowledged, and unaccountable leadership”, as famously detailed in “The Tyranny of Structureless“. In reality, sadly, these teams tend to be chaotic, fragile, and frustrating. I know! I’m pissed too!

This argument doesn’t necessarily prove your CEO is wrong, but I should think his bar for proof is much higher than yours. “I don’t want any of my engineers to stop writing code” is not an argument. But I’m also feeling like I haven’t quite addressed the core question of productivity, so let’s pick that up again once more.

More lines of code != more productivity

To briefly recap: we were talking about an org with ~40 engineers, broken up into 10 small clusters of 3-4 engineers, each with a tech lead. Your CEO is arguing that you can’t afford to lose any velocity, which he thinks is what would happen if anyone stops writing code full time.

Maybe. But everything I have ever experienced leads me to believe that a fewer number of larger teams, each helmed by an experienced engineering manager, should way outperform this gaggle of tiny groups. It’s not even close. And they can do so in a way that’s more efficient, sustainable, and humane than this scrappy death march.

And systems thinking shows us why! With fewer groups, but larger ones, you have less overall management overhead, and much less of the slow and costly intra-group coordination. You unlock rich, dense knowledge transfer within groups, which gives you more shared coverage of the surface area. With 7-9 engineers per group you can build a real on call rotation, which means fewer heroics and less burnout. The coordination that you do need to do can be more strategic, less tactical, and much more forward-looking.

Would five big teams ship as many lines of code as 10 small teams, even if five engineers become managers and stop writing code? Probably, but who cares? Your customers give zero fucks how many lines of code you write. They care about whether you are building the right things and solving problems that matter to them. What matters is moving the business forward, not churning out code. Don’t forget, the act of churning out code creates costs and externalities in and of itself.

What defines your velocity is that you spend your time on the right things. Learning to make good decisions about what to build is something every organization has to work out for itself, and it is always an ongoing work in progress. Engineering managers don’t do all the work or make all the decisions, but they are absolutely fucking vital, in my experience, to ensuring that work happens and is done well. As I wrote in my last piece, engineering managers are the embodiment of the feedback loops that systems use to learn and improve.

Are managers ever unnecessary overhead?

Sure, absolutely. Management is about coordinating between teams and helping teams run more optimally, so anything that decreases your need for coordination also decreases your need for management. If you are a small company, or if you have really senior folks who are used to working together, you need a lot less coordination. The next most relevant factor is probably the rate of change; if you’re growing fast or have a lot of turnover, or if there’s a lot of time pressure or frequent shifts in strategy, your need for managers goes up. But there are plenty of smaller orgs out there that are doing just fine without a lot of formal management.

Look, I’m not a fan of the word “overhead”, because a) it’s kind of rude and b) people who call managers “overhead” are typically people who disrespect or do not value the craft of management.

But management is, in fact, overhead. So is a lot of other glue work! By which I mean the work is important, but does not itself move the business forward; we should do as much of it as absolutely necessary and no more. The nature of glue work is such that it too-easily expands to consume all available time and space (and then some). Constraints are good. Feeling a bit underresourced is good, and should be the norm. It is incredibly easy for management to get a bit bloated, and managers can be very loath to acknowledge this, because it’s not like they ever feel any less stressed or stretched.[*]

Management is also very much like operations work in that when it’s being done well, it’s invisible. Evaluating managers can be very hard, especially in the near term, and making decisions about when it’s time to create or pay down organizational debt is a whole nother ball of wax, and way outside the scope of this post.

But yes, managers can absolutely be unnecessary overhead.

However, if you have 40 engineers all reporting to one VP, and nobody else whose number one job is the outcomes related to people, teams and org, I feel pretty safe in saying this is not a risk for you at this time.

<3 charity

[*] In fact, the reverse can be true; bloated management can create MORE work for managers, and they may counterintuitively feel LESS stretched or stressed with a leaner org chart. Bureaucracies do tend to pick up a momentum all their own. Especially when management gets all wrapped up in promotions and egos. Which is yet another good reason to ensure that management is not a promotion or a form of domination.

Article URL: https://jesseduffield.com/Can%27t-Be-Fcked/

Comments URL: https://news.ycombinator.com/item?id=37859311

Points: 189

# Comments: 178