An Elegant Puzzle: Systems of Engineering Management

by Will Larson

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 appropriate practices for themselves. It’s okay to approach change gradually.

Although I’ve seen this approach work remarkably well, I’ve also seen it go nowhere. It’s a particular tool for certain circumstances, and it does fail. It may be an inexpensive failure—folks simply don’t adopt—as you haven’t spent much authority on it, but nonetheless you still haven’t accomplished your goal. It’s particularly important not to try to use this as a strategy to circumvent organizational authority. Operating in direct conflict with authority usually doesn’t end very well.

There are many different approaches to try to manage inconsistency creep. Some of the solutions I’ve seen are formalized sprints, training, shadowing, documentation, code linters,34 process automation (particularly deploys), and incident reviews. However, when the problem becomes truly acute, folks eventually reach for the same tool: adding a centralized, accountable group. The two most common flavors of this I’ve seen are “product reviews” to standardize product decisions and the “architecture group” to encourage consistent technical design.

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.

Start by explaining why your work matters to the company.

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.

Instead of hiding problems, use them as an opportunity to explain your plans to address them.

Deep in the data. You should be deep enough in your data that you can use it to answer unexpected questions.

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.

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.

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 meeting by explicitly framing your goal!

Quarterly time retrospective. 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.

Ultimately, 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.

Calendar blocking. 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.

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.

I’ve always preferred learning in private. Got something difficult? Sure, leave me alone for a few hours and I can probably figure it out. If you want me to figure it out with you watching, I’m not even sure how to start. This is partly introversion, but altogether I’m pretty uncomfortable making mistakes in public.

Be a facilitator, not a lecturer. Folks want to learn from each other more than they want to learn from a single presenter. Step back and facilitate.

Brief presentations, long discussions.

Small breakout groups. Giving folks time to discuss in small groups allows them to learn a bit about the topic in a small, safe place. It also gives everyone an opportunity to be part of the discussion, which is a lot more engaging than listening to others for an hour.

Bring learnings to the full group. After discussions, give each group an opportunity to bring their discussion back to the larger group, to allow the groups to cross-pollinate their learnings.

Choose topics that people already...

being introduced to a new topic in public, and for those individuals, providing a list of optional pre-reads can help them prepare for the discussion.

The thing I enjoy most about this format is that it gives folks what they really want, spending time learning from each other, and is remarkably quick for the facilitator to prepare. I’m far from a seasoned facilitator, and I’ve also found this format to be a rewarding and safe opportunity for me to grow as a facilitator. If your company doesn’t have any learning communities, give it a try. I’ve found this one of the easiest, most rewarding things I’ve had the opportunity to work on.

You unravel most puzzles knowing they’re solvable. You play most games guided by a rule book. For engineering managers, challenges emerge unexpected from a hundred small decisions, with few rules and no promises. Many of these challenges are difficult in the worst sense.

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

Since then, I’ve come to believe that environments that tolerate frequent exceptions are not only susceptible to bias but are also inefficient. Keeping an organization aligned is challenging in the best of times, and exceptions undermine one of the most powerful mechanisms for alignment: consistency.

Conversely, organizations survive by adapting to the dynamic circumstances they live in. An organization stubbornly insisting on its established routines is a company pacing a path whose grooves lead to failure.

How do you reconcile consistency...

Eventually, a unified approach emerged, which I call “Work the policy, not the exceptions.”

If you find yourself writing constraints that don’t actually constrain choice, it’s useful to check if you’re dancing around an unstated goal that’s limiting your options.

Granting exceptions undermines people’s sense of fairness, and sets a precedent that undermines future policy.

Organizations spending significant time on exceptions are experiencing exception debt. The escape is to stop working the exceptions, and instead work the policy.

Once you’ve collected enough escalations, revisit the constraints that you developed in the original policy, merge in the challenges discovered in applying the policy, and either reaffirm the existing constraints or generate a new series of constraints that handle the escalations more effectively.

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.

Articulating your constraints depends on the particulars of the issue at hand, but 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?

When folks want you to commit to more work than you believe you can deliver, your goal is to provide a compelling explanation of how your team finishes work. Finishes is particularly important, as opposed to does, because partial work has no value, and your team’s defining constraints are often in the finishing stages. The most effective approach that I’ve found for explaining your team’s delivery process is to build a kanban board2 describing the steps that work goes through, and documenting who performs which steps.

Using this board, you’ll be able to explain what the current constraints are for execution, and help your team narrow suggestions for improvement down to areas that will actually help.

If you’ve poured time into explaining both your velocity and priorities but your perspective still isn’t resonating, then it’s fairly likely that you have a relationship problem to address. In that case, the next step isn’t investing more energy in explaining your constraints, but instead working on how you partner with your individual stakeholders.

When I started managing, my leadership philosophy was simple: The Golden Rule6 makes a lot of sense. Give everyone an explicit area of ownership that they are responsible for. Reward and status should derive from finishing high-quality work. Lead from the front, and never ask anyone to do something you wouldn’t.

4.3.1 An ethical profession I believe that management, at its core, is an ethical profession. To see ourselves, we don’t look at the mirror, but rather at how we treat a member of the team who is not succeeding. Not at the mirror, but at our compensation philosophy. Not at the mirror, but at how we pitch the roles to candidates. Whom we promote. How we assign raises. Provide growth opportunities. PTO requests. Working hours.

This doesn’t always mean being your team’s best friend. Sometimes it means asking them to make personal sacrifices, letting go of a popular member of the team, or canceling a project the team is excited about. It’s remembering that you leave a broad wake, and that your actions have a profound impact on those around you.

A few years back, one of the leaders I worked with told me, “With the right people, any process works, and with the wrong people, no process works.” I’ve found this to be pretty accurate.

If you have a poor relationship with your manager or a member of your team, spend even more time with them. Meet with them every day, or have dinner with them. If two engineers are struggling to work together, before you separate them onto different teams get them to spend more time together trying to understand each other’s perspective. (There are some obvious exceptions here, but if two people truly cannot work together, is there something else there that you’ve been avoiding dealing with?)

As a leader, you can’t run from problems; engage ’em head-on.

It’s common for well-meaning individuals from outside the growth plates to jump in to help by supplying more ideas, but that’s counterproductive. What folks in the growth plates need is help reducing and executing the existing backlog of ideas, not adding more ideas that must be evaluated. Teams in these scenarios are missing the concrete resources necessary to execute, and supplying those resources is the only way to help. Giving more ideas feels helpful, but isn’t.

Only see the problems. It can be easy to only see what’s going wrong, and forget to celebrate the good stuff. Down this path lie frustration and madness.

Things your manager should know about you: What problems you’re trying solve. How you’re trying to solve each of them. That you’re making progress. (Specifically, that you’re not stuck.) What you prefer to work on. (So that they can staff you properly.) How busy you are. (So that they know if you can take on an opportunity that comes up.) What your professional goals and growth areas are. Where you are between bored and challenged. How you believe you’re being measured. (A rubric, company values, some KPIs, etc.)

Maintain a document with this information, which you keep updated and share with your manager. For some managers, this will be enough! Mission accomplished. Sprinkle this information into your one-on-ones, focusing on information gaps (you’re not seeing support around a growth area, you’re too busy, or not busy enough, and so on). Success is filling in information gaps, not reciting a mantra. At some regular point, maybe quarterly, write up a self-reflection that covers each of those aspects. (I’ve been experimenting with a “career narrative” format that is essentially a stack of quarterly self-reflections.) Share that with your manager, and maybe with your peers too! A

knowing some things about your manager and their needs. Here are some good things to know: What are their current priorities? Particularly, what are their problems and key initiatives. When I get asked this question, I often can’t answer it directly, because what I’m focused on is people-related, but it’s a warning sign if your manager never answers it (either because because they don’t know, or they are always working on people issues). How stressed are they? How busy are they? Do they feel like they have time to grow in their role or are they grinding? Is there anything you can do to help? This is particularly valuable for managers who don’t have strong delegation instincts. What is their management’s priority for them? What are they trying to improve on themselves, and what are their goals? This is particularly valuable to know if they appear stuck,12 because you may be able to help unstick them. (You could be especially helpful by redefining impact in terms of work that your team can accomplish versus growing team size, which is a frequent source of stickiness!)