An Elegant Puzzle: Systems of Engineering Management

by Will Larson

The recent focus on programming interviews7 is a great example. Most hiring managers, myself certainly included, are aware that they’re conducting mediocre interviews, but over time it’s easy to lose that perspective. You can’t fix everything at once, so you’ll often be doing something mediocre at any given point in time, but remember to come back and improve it when you can (e.g., pay down your management debt).

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.

The message I’d end with is a simple one: be thoughtful about carrying your values with you from one context into another. Leadership is matching appropriate action to your current context, and it’s pretty uncommon that any two situations will flourish from the same behaviors. If you’re working in the growth plates—or outside of them—for the first time, treat it like a brand-new role. It is!

As a new manager, I found it useful to start each performance review season by rereading! Which also means it’s an excellent time to reread Camille Fournier’s “How Do Individual Contributors Get Stuck?”

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 they don’t know, or they are always working on people issues).

Make a clear decision on each of those pivots, write up a document explaining those decisions, and then see if you can get anyone to read it. They’ll disagree with a lot of what you’ve written, or else they’ll be confused by it. Keep testing, and refine the confusion down to the smallest group of controversial problems possible.

For every problem that comes your way—an email asking for a decision, a production problem, a dispute around on-call, a request to transfer from one team to another—you must pick one of three options: Close out. Close it out in a way such that this specific ask is entirely resolved. This means making a decision and communicating it to all involved participants. This strategy is a success if this particular task never comes back to you; and your goal is to finish this particular task as quickly and as permanently as possible. Solve. Design a solution such that you won’t need to spend time on this particular kind of ask again in the next six months. This is often designing norms or process, but depending on the kind of issue, this might be coaching an individual. With this option, your goal is to finish off an entire category of tasks. Delegate. Ideally, this is to redirect the ask to someone who is responsible for that kind of work, but sometimes it is a one-off. If you can’t close out a task or solve it, your only other option is to delegate it to someone who either has the specialized skills to close/solve it, or who can work in the system.

The basis: an inclusive organization is one in which individuals have access to opportunity and membership.

Rubrics everywhere. Every important people decision should have a rubric around how folks are evaluated. This is true for promotions, performance designations, hiring, transitions into management, and pretty much everything else! Selecting project leaders.1 Having a structured approach to selecting project leads allows you to learn from previous selections, and to ensure that you’re not concentrating opportunity on a small set of individuals. Explicit budgets. Many companies take a “spend it like your own money” approach to budgets, which often leads to large inconsistencies across individuals. Instead of saying that you’ll pay for teams to attend a reasonable number of conferences per year, specify a fixed number. Instead of maintaining a general ongoing education budget, make it explicit. Nudge involvement. Many people are uncomfortable applying to opportunities, using education budgets, asking for mentorship, etc. It’s very effective to reach out to those folks directly and recommend they apply. Even more powerful is showing them where they fall on a distribution: it’s one thing to know that you’ve never used your education budget, and something else entirely to know that you’re the only person who isn’t using it. Education programs. Create ongoing training and learning programs that are available for everyone, or, for example, for all managers.

Retention is the most important measure of availability of opportunity, although it’s also a very lagging indicator. This should be the first thing you’re paying attention to, but you must recognize that it’s slow to show change. Usage rate is how often folks get picked in project selection.2 The number of distinct team members picked to lead critical projects is a particularly interesting measure. Level distribution is useful, in particular comparing cohorts of folks with different backgrounds. People want role models for themselves in senior roles at the company where they work, which is why looking at the representation of underrepresented minorities and women is only a start. You also want to look in each role and level of seniority. Time at level is how long team members wait between promotions. How does this compare across cohorts? Something to watch for is that this number is also greatly influenced by initial level at hiring. For example, time at level might look equivalent because some cohorts are being under-leveled at time of hire. Getting access to some of this data will require partnering with your human resources team, but I’ve found that friendly persistence, along with sharing your thinking behind the asks, works well to get coworkers working with you.

Recurring weekly events allow coworkers to interact socially. These are held during working hours, are open to folks from many different teams to attend, and are optional. One of my personal favorites is hosting a paper-reading group.3 Employee Resource Groups (ERGs) create opportunities for folks with similar backgrounds to build community. Team offsites once a quarter or so are a good chance to pause, reflect, and work together differently. Spending a day together learning and discussing is surprisingly effective at making individuals feel like a team. This is particularly true for groups of managers, whose daily cadence is typically more in tune with their teams than with their peers. Coffee chats, perhaps randomly assigned by Donut,4 get folks from different teams interacting when they don’t need something from each other. Team lunches give folks time to relax a bit and interact socially. Held once a week or so, they can become a pleasant ritual. These can be a bit risky, at least for folks (like early hires) who feel uncomfortable in their team. Navigating the social mores of an entire team can be much more difficult than in a one-on-one.

Retention is once again the golden measure, and once again a long-trailing indicator. Referral rate by cohort provides insight into which individuals feel comfortable asking their friends and previous coworkers to join the company. Attendance rates for recurring events and team lunches provide some insight into whether folks feel comfortable with those groups. The quantity and completion rate of coffee chats are automatically measured with Donut.

Wielding this distinction, “freedom” is neither inherently good nor inherently just, and descends into the murky gray that already embroils everything else in our lives. Each positive freedom we enforce strips away a negative freedom, and each negative freedom we guarantee eliminates a corresponding positive freedom. This sad state of affairs is often referred to as the Paradox of Positive Liberty.

A few closing tangents. First, Tom DeMarco’s Slack13 has an excellent suggestion for a good starting state between positive and negative freedoms for engineering teams: generally follow the standard operating procedure (i.e., keep doing what you’re already doing, the way you’re doing it), but always change exactly one thing for each new project. Perhaps use a new database, a new web server, a different templating language, a static JavaScript front-end, whatever—but always change exactly one thing.

They’re truly unmaintainable beings, as their presence limits the effectiveness of those around them in exchange for a short-term burst of productivity fueled by long hours and minimized communication costs (minimized because most other people aren’t able to do much).

Projects fail slowly—and fixing them takes time, too. Working at a frenetic pace for a couple of weeks or a month may feel like a major outpouring of effort and energy, but it’s near impossible to quickly counteract a deficit created over months of poor implementation or management choices.

5.6.4 Resetting broken systems Your options for addressing a broken system depend on whether you’re in a position to set policy. If you set the original direction and have the leverage to change directions, then resetting is as simple as standing up and taking the bullet for the fiasco you’re embroiled in. Taking the blame is painful, and it only plays well with the crowds a couple of times.

Projects fail all the time, people screw up all the time. Usually it’s by failing to acknowledge missteps that we exacerbate them. If we acknowledge errors quickly, and cut our losses on bad decisions before burning ourselves out, then we can learn from our mistakes and improve. Kill your heroes and stop doing it harder. Don’t trap yourself in your mistakes, learn from them and move forward.

don’t treat growth as a foregone conclusion. Growth only comes from change, and that is something you can influence.

Reflecting on the interviews I’ve run over the past few years and those I got to experience recently, I believe that, while interviewing well is far from easy, it is fairly simple. Be kind to the candidate. Ensure that all interviewers agree on the role’s requirements. Understand the signal your interview is checking for (and how to search that signal out). Come to your interview prepared to interview. Deliberately express interest in candidates. Create feedback loops for interviewers and the loop’s designer. Instrument and optimize as you would any conversion funnel. You don’t have to do all of these to be effective! Start from being nice and slowly work your way through to the analytics.

My experience is that you can’t conduct a kind, candidate-centric interview process if your interviewers are tightly time-constrained. Conversely, if an interviewer is unkind to a candidate (and these unkindnesses are typically of the “with a whisper not a bang” variety), I believe it is very often a structural problem with your interviewing process, and not something you can reliably dismiss as an issue with that specific interviewer.

can be easy to get lost spending your cycles on instrumenting your process instead of improving it.

Wise words for lots of processes

benefits of working at a large company early in your career, beyond name recognition, is kickstarting your personal network.)