An Elegant Puzzle: Systems of Engineering Management

by Will Larson

You’ll likely want one vision for every complete distinct area, but no more. If areas overlap, you get the alignment value from having one unified vision; having two clearly articulated visions in one place is worse than having zero.

There is a moment in every company’s growth when top-level planning shifts from discussing specific projects to talking about goals. This happens recursively across each scope of leadership, as areas of accountability become too broad or complex for their leaders to consistently understand every project’s details.

You’ll know a goal is just a number when you read it and aren’t sure if it’s ambitious or whether it matters.

Good goals are a composition of four specific kinds of numbers: A target states where you want to reach. A baseline identifies where you are today. A trend describes the current velocity. A time frame sets bounds for the change.

The two tests of an effective goal are whether someone who doesn’t know much about an area can get a feel for a goal’s degree of difficulty, and whether afterward they can evaluate if it was successfully achieved.

There are two particularly interesting kinds of goals: investments and baselines. Investments describe a future state that you want to reach, and baselines describe aspects of the present that you want to preserve.

The best way to avoid such unintended outcomes is to pair your investment goals with baseline metrics, sometimes referred to as countervailing metrics.

The most common way to use goals is during a planning process. By agreeing on the mix of investment and baseline goals for each team, you’re able to set clear expectations for a team while still giving them full ownership of how they’ll satisfy the constraints.

I’ve found metrics to be an extremely effective way to lead change with little or no organizational authority, and I wanted to write up how I’ve seen that work.

Diving deep helps you build a mental model, and it also kicks off a relationship between you and the teams who you’ll want to partner with most closely.

It’s easy to simply pass the cost metric on to that Cloud team, but that’s just abdicating responsibility to them. What’s more useful is to help them build a system of second-degree attribution, allowing you to build data around the teams using the platform. This second degree of attribution is going to allow you to target the folks who can make an impact in the next step.

Benchmarking is particularly powerful because it automatically adapts to changes in behavior.

What I’ve found effective is to send push notifications, typically email, to teams whose metric has changed recently, both in terms of absolute change and in terms of their benchmarked performance against their cohort.

this does require some organizational authority, but I’ve found that folks universally want to be responsible. As long as you can find time to sit down with the key teams and explain why the goal is important, it typically doesn’t require much organizational authority.

The fact that something stops working at significantly increased scale is a sign that it was designed appropriately to the previous constraints rather than being over-designed.

Migrations matter because they are usually the only available avenue to make meaningful progress on technical debt.

Googlers have a phrase, “running to stand still,” to describe a team whose entire capacity is consumed in upgrading dependencies and patterns, such that the group can’t make forward progress on the product/system they own.

there are two managerial skills that have a disproportionate impact on your organization’s success: making technical migrations cheap, and running clean reorganizations.

There is only one worst kind of reorg: the one you do because you’re avoiding a people management issue.

Are you reorganizing to work around a broken relationship? Management is a profession where karma always comes due, and you’ll be better off addressing the underlying issue than continuing to work around it.

Organizational change is so disruptive to so many people that I’ve increasingly come to believe you should drive organizational design from the boxes and not from the key individuals.

If engineering managers are expected to do hands-on technical work, then their teams should likely be three to five engineers

Otherwise, targeting five to eight engineers, depending on experience level, is pretty typical.

most poor working relationships are the by-product of information gaps, and nothing fills those faster than proximity.

From there, you have four sources of candidates to staff them:

That is probably an ordered list of how you should try to fill the key roles. This is true both because you want people who already know your culture and because reorganizations that depend on yet-to-be-hired individuals are much harder to pull off successfully.

Accidentally missing someone is the cardinal sin of reorganization.

A few questions to ask yourself before you decide to fully commit:

Organizational change is rather resistant to rollback, so you have to be collectively committed to moving forward with it, even if it runs into challenges along the way

There are three key elements to a good rollout: Explanation of reasoning driving the reorganization. Documentation of how each person and team will be impacted. Availability and empathy to help bleed off frustration from impacted individuals.

If necessary, hold an organization all-hands, but probably try not to. People don’t process well in large groups, and the best discussions take place in small rooms.

an organization is both (1) a collection of people and (2) a manifestation of an idea separate from the individuals comprising it. You can’t reason about organizations purely from either direction.

There is no universal set of controls—depending on the size of team and your relationships with its leaders, you’ll want to mix and match—but the controls structure itself is universally applicable.

For whatever controls you pick, the second step is to agree on the degree of alignment for each one.

Combine your controls and the degree of alignment for each, and you’ve established the interface between you and the folks you support. This reduces the ambiguity of how you work together and allows everyone to focus. It’s useful for agreeing on performance goals, and is also very useful for exposing alignment gaps between you and individuals you work with

most folks are always at the furthest point in their career, each change a step into the unknown, with limited visibility into the upcoming opportunities that their company can provide.

there is much more opportunity on career ladders than off of them, and by including those opportunities you’ll make and feel more progress.

A different approach would be to instead work on identifying the gaps that would keep you from being a strong head of engineering, and then start using your current role to help fill those gaps.

There’s no need to convince yourself that your current role is holding you back—everything you need is here.

An important part of setting your goals is developing areas you’re less experienced in to maximize your global success, but it’s equally important to succeed locally within your current environment by prioritizing doing what you do well.

take an hour and write up as many goals as you can for what you’d like to accomplish in the next one to five years. Then prioritize the list, pick a few that you’d like to focus on for the next three to six months, and share it with your manager at your next one-on-one.

Managers tend to have a strong sense of the business’s needs, and that gives them the superpower of finding the intersection of your interests and the business’s priorities. That translation is a creative pursuit, so don’t leave this entirely to your manager: participate as well!

Chasing the next promotion is at best a marker on a mass-produced treasure map, with every shovel and metal detector re-covering the same patch. Don’t go there. Go somewhere that’s disproportionately valuable to you because of who you are and what you want.

Answer the question you want to be asked. If someone asks a very difficult or challenging question, reframe it into one that you’re comfortable answering. Don’t accept a question’s implicit framing, but instead take the opportunity to frame it yourself.

Stay positive. Negative stories can be very compelling. They are quite risky, too! As an interviewee, find a positive framing and stick to it. This is especially true when it comes to competitors and controversy.

Speak in threes. Narrow your message down to three concise points, make them your refrain, and continue to refer back to your three speaking points.

One of the trickiest, and most common, leadership scenarios is leading without authority, and I’ve written about one of the styles that I’ve found surprisingly effective in those conditions. I call it Model, Document, Share.

After you’ve discovered an effective approach, document the problem you set out to solve, the learning process you went through, and the details of how another team would adopt the practice for themselves. Be as detailed as possible: make a canonical document, and even get a few folks on other teams to check that it’s readable from their perspective.

The final step is to share your documented approach, along with your experience doing the rollout, in a short email. Don’t ask everyone to adopt the practice, don’t lobby for change, just present the approach and your experience following it.

in my experience, this has often led to more adoption than top-down mandates have.