An Elegant Puzzle: Systems of Engineering Management

by Will Larson

When considering how the Model, Document, Share approach works, it’s interesting to compare it with the top-down mandate.

Mandates assume: It’s better to adopt a good-enough approach quickly. Teams have the bandwidth to adopt a new approach. The organization has available resources to coordinate a rollout. You want to centralize decision-making on this topic. Consistency is important; all teams need to approach this problem in the same way. It’s important to make this change quickly.

Model, Document, Share assumes: It’s better to adopt a great approach slowly. Some teams don’t have the bandwidth to adopt a new approach. The organization may not have resources to coordinate a rollout. You want to decentralize decision-making on this topic. Teams have agency to adopt the ...

If you have the time, you can slowly flock toward great practice, without needing organizational authority.

There are many different approaches to try to manage inconsistency creep.

Many folks will feel a significant loss of freedom when you create these groups, as their zone of decision-making will be newly limited. Less obviously, many folks find the creation of centralized groups to be extremely empowering. The difference? One group is largely populated by individuals comfortable with self-authorization, and the latter typically have a higher threshold for self-authorization.

A positive freedom is the freedom to do something, for example the freedom to pick a programming language you prefer.

A negative freedom is the freedom from things happening to you, for example the freedom not to be obligated to support additional programming languages, even if others would greatly prefer them.

Particularly in cases where ownership is extremely diffuse, I believe that cautiously authoritative groups do increase net positive freedom for individuals without greatly reducing negative freedom.

How large should the group be? If it’s six or fewer individuals, it’s possible for them to gel into a true team, one whose members know each other well, work together closely, and shift a significant portion of their individual identities into the team. If the group has more than ten members, you’ll find it hard to even have a good discussion, and it’ll need to be structured into sub-groups to function well (rotation that spreads members over time, working groups of some members to focus on particular topics, and so on). The larger the group, the more responsibility becomes diffuse, and the more you’ll need to have specified roles within the group, for example a member responsible for coordinating members’ focus.

How much time will members spend working in this group? Will this be their top priority, or will they still primarily be working on other projects? Higher time commitment correlates with more actions and decisions. Consequently, my sense is that you want time commitment to be higher for areas where folks are directly impacted by the consequences of their decisions, and to be lower for scenarios with weaker feedback loops.

Before you release that email you’re writing to spin up a new centralized decision-making group, it’s worth talking about the four ways these groups consistently fail. They tend to be domineering, bottlenecked, status-oriented, or inert.

Bottlenecked groups tend to be very helpful, but are trying to do more then they’re actually able to do. These groups get worn down, and either burn out their members or create a structured backlog to avoid burning themselves out, which ends up seriously slowing down folks who need their authority.

Giving a presentation to senior leadership is a bit of a dark art: it takes a while to master, and most people who do it well can’t quite articulate how they do it. Worse yet, many people who are excellent rely on advantages that resist replication: charisma, quick wit, deep subject matter expertise, or years of experience.

Communication is company-specific. Every company has different communication styles and patterns. Successful presenters probably can’t tell you what they do to succeed, but if you watch them and take notes, you’ll identify some consistent patterns. Each time you watch individuals present to leadership, study their approach.

Start with the conclusion. Particularly in written communication, folks skim until they get bored and then stop reading. Accommodate this behavior by starting with what’s important, instead of building toward it gradually.

Frame why the topic matters. Typically, you’ll be presenting on an area that you’re intimately familiar with, and it’s probably very obvious to you why the work matters. This will be much less obvious to folks who don’t think about the area as...

Everyone loves a narrative. Another aspect of framing the topic is providing a narrative of where things are, how you got here, and where you’re going now. This should be a sentence or two along the lines of, “Last year, we had trouble closing several important customers due to concerns about our scalability. We identified our databases as our constraints to scaling, and since then our focus has been moving ...

Prepare for detours. Many forums will allow you to lead your presentation according to plan, but that is an unreliable prediction when presenting to senior leadership. Instead, you need to be prepared to lead the entire presentation yourself, while being equally read...

Answer directly. Senior leaders tend to be indirectly responsible for wide areas, and frequently pierce into areas to debug problems. Their experience “debug piercing” tunes their radar for evasive answers, and you don’t want to be a blip on that screen. Instead of hiding pr...

Deep in the data. You should be deep enough in your data that you can use it to answer unexpected questions. This means spending time exploring the data, and the most common way to d...

Derive actions from principles. One of your aims is to provide a mental model of how you view the topic, allowing folks to get familiar with how you make decisions. Showing you are “in the data” is part of this. The other aspect is defining the guiding principles you’re using to approach decisions.

Discuss the details. Some executives test presenters by diving into the details, trying to uncover an area the presenter is uncomfortable speaking on. You should be familiar with the details, e.g., project statuses, but I think that it’s usually best to reframe the discussion when you get too far into the details. Try to pop up to either the data or the principles, which tend to be more useful conversations.

Prepare a lot; practice a little. If you’re presenting to your entire company, practicing your presentation is time well spent. Leadership presentations tend to quickly detour, so practice isn’t quite as useful. Practice until you’re comfortable, but prefer to prepare instead getting deeper into the data, details, and principles. As a corollary, if you’re knowledgeable in the area you’re responsible for, and have spent time getting comfortable with the format, over time you’ll find that you won’t need to prepare much for these specifically. Rather, whether...

Make a clear ask. If you don’t go into a meeting with leadership with a clear goal, your meeting will either go nowhere or go poorly. Start the ...

My general approach to presenting to senior leaders is: Tie topic to business value. One or two sentences to answer the question “Why should anyone care?” Establish historical narrative. Two to four sentences to help folks understand how things are going, how we got here, and what the next planned step is. Explicit ask. What are you looking for from the audience? One or two sentences. Data-driven diagnosis. Along the lines of a strategy’s diagnosis phase,39 explain the current constraints and context, primarily through data. Try to provide enough raw data to allow people to follow your analysis. If you only provide analysis, then you’re asking folks to take you on trust, which can come across as evasive. This should be a few paragraphs, up to a page. Decision-making principles. Explain the principles that you’re applying against the diagnosis, articulating the mental model you are using to make decisions. What’s next and when it’ll be done. Apply your principles to the diagnosis to generate the next steps. It should be clear to folks reading along how your actions derive from your principles and the data. If it’s not, then either rework your principles or your actions! Return to explicit ask. The final step is to return to your explicit ask and ensure that you get the information or guidance you need.

it’s intimidating to consider that there’s little evidence most folks ever get a solid grasp of their time.

Every quarter, I spend a few hours categorizing my calendar from the past three months to figure out how I’ve invested my time. This is useful for me to reflect on the major projects I’ve done, and also to get a sense of my general allocation of time. I then use this analysis to shuffle my goal time allocation for the next quarter.

you have to prioritize long-term success, even if it’s personally unrewarding to do so in the short term. It’s not that I like this approach, it’s that nothing else works.

If you’re doing leveraged work,40 then each thing that you finish41 should create more bandwidth to do more future work. It’s also very rewarding to finish things. Together, these factors allow large volumes of quick things to build into crescendoing momentum.

When you’re quite underwater, a surprisingly underutilized technique is to stop doing things. If you drop things in an unstructured way, this goes very poorly, but done with structure this works every time. Identify some critical work that you won’t do, recategorize that newly unstaffed work as organizational risk,42 and then alert your team and management chain that you won’t be doing it. This last bit is essential: it’s fine to drop things, but it’s quite bad to silently drop them.

Instead, specify the number of hours you’re able to dedicate to the activity, perhaps two per week, and perform as many skip-levels as possible within that amount of time. This method keeps you in control of your time allocation, and it scales as your team grows.

Delegate working “in the system.” Wherever you’re working “in the system,”44 design a path that will enable someone else to take on that work.

Once you’ve built the system, at some point you have to learn to trust it. The most important case of this is handing off the responsibility to handle exceptions.

Handling exceptions can easily consume all of your energy, and either delegating them or designing them out of the system is essential to scaling your time.

By having a clear organizational design, you can hire folks into roles before their absence becomes crippling.

Creating blocks of time on your calendar is the perennial trick of time management: add three or four two-hour blocks scattered across your week to support more focused work. It’s not especially effective, but it does work to some extent and is quick to set up, which has made me a devoted user.

As you start using more of these approaches, you won’t immediately find yourself less busy, but you will gradually start to finish more work.

When I first started facilitating the group, we focused on content-rich presentations. Each slide was dense with important lessons and essential details. It didn’t work well. Folks weren’t engaged. Attendance dropped. Learning was not the order of the day.

it can be powerful to start by checking in with each other, having each person give a 20- or 30-second self-introduction. The format we’ve been using lately is your name, your team, and one sentence about what’s on your mind.

Management is an ethical profession, and our decisions matter, especially the hard ones.

environments that tolerate frequent exceptions are not only susceptible to bias but are also inefficient.

Every policy you write is a small strategy,1 built by identifying your goals and the constraints that bring actions into alignment with those goals.

I instead recommend writing norms, which provide nonbinding recommendations. Because they’re nonbinding, they don’t require escalations to address ambiguities or edge cases.

When you roll out a policy, it’s quite helpful to declare a future time when you’ll refresh it, which ensures that you’ll have the time to fully evaluate your new policy before attempting revision.

The next time you’re about to dive into fixing a complicated one-off situation, consider taking a step back and documenting the problem but not trying to solve it. Commit to refreshing the policy in a month, and batch all exceptions requests until then. Merge the escalations and your current policy into a new revision. This will save your time, build teams’ trust in the system, and move you from working the exceptions to working the policy.

This no is explaining your team’s constraints to folks outside the team, and it’s one of the most important activities you undertake as an engineering leader.

I find that two topics are frequent venues of disagreement. The first is velocity: Why is this taking so long when it should take a couple of hours? The other is prioritization: Why can’t you work on this other, more important, project?

you don’t provide this framework, people tend to start making suggestions everywhere across your process, which at best means many ideas won’t reduce load where it’s most helpful, and at worst may inadvertently increase load.

the best outcome of a discussion on velocity is to identify a reality-based approach that will support your core constraint. The second-best outcome is for folks to agree that you’re properly allocated against your constraints and to shift the conversation to prioritization. (Those are the only good outcomes.)