Running an engineering reorg

At quickly growing companies, I believe there are two managerial skills that have a disproportionate impact on your organization’s success: making technical migrations cheap, and running clean reorganizations. Do both well, and you can skip that lovely running to stand still sensation, and invest your attention more fruitfully.

Of the two, managing organizational change is more general so let’s work through a lightly structured framework for (re)designing an engineering organization.

Caveat: this is more of a thinking tool than a recipe!

My approach for planning organization change:

1. Validate organizational change is the right tool.
2. Project headcount a year out.
3. Set target ratio of management to individual contributors.
4. Identify logical teams and groups of teams.
5. Plan staffing for the teams and groups.
6. Commit to moving forward.
7. Rollout the change.

Now, let’s drill into each of those a bit.

Is a reorg the right tool?

There are two best kinds of reorganizations:

• the one that solves a structural problem, and
• the one that you don’t do.

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

My checklist for ensuring that a reorganization is appropriate is:

1. Is the problem structural? The opportunities of organization change are to increase communication, reduce decision friction, and focus attention; if you’re looking for a different change, consider a bit if there’s a more direct approach.
2. Are you reorganizing to work around a broken relationship? Management is a profession where karma always comes due, and you’ll be better addressing the underlying issue than continuing to work around it.
3. Does the problem already exist? It’s better to wait until a problem actively exists before solving it, because it’s remarkably hard to predict future problems. Even if you’re right that the problem will occur, you may end up hitting a different problem first.
4. Are the conditions temporary? Are you in a major crunch period or otherwise doing something you don’t anticipate doing again? If so, then it may be easier to patch through and rethink on the other side, and avoid optimizing for a transient failure mode.

Alright, so you’re still thinking you want a reorg.

Project headcount a year out.

The first step of designing the organization is determining its approximate total size. I recommend reasoning through this number from three or four different directions:

1. an optimistic number that’s barely possible,
2. a number based on the “natural size” of your organization, if every team and role was fully staffed,
3. a realistic number based on historical hiring rates.

Then merge those into a single number.

Unless you’ve changed something meaningful in your process, it’s likely the historical trend will hold accurate, and you should weight it the most heavily (and my sense is that the list of easy changes that significantly change hiring outcomes is short).

One of the goals of using the year out headcount number is to avoid optimizing too heavily for your exact current situation and the current individuals you’re working with. 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.

Manager to engineer ratio.

Once you have your headcount projection, next you need to identify how many individuals you want each manager to support. This number particularly depends on your company’s working definition of an engineering manager’s role.

If engineering managers are expected to be doing hands on technical work, then their teams should likely be three to five engineers (unless the team has been working together well for a long time, in which case things get very specific and hard to generalize about).

Otherwise, targeting five to eight, depending on experience level, is pretty typical. If you’re targeting higher than eight engineers per manager, then it’s worth reflecting on why you believe your managers can support a significantly higher load than industry average: are they exceptionally experienced? are your expectations lower than typical?

In any case, pick your target, probably in the six to eight range.

Defining teams and groups.

Now that you have your target organization size and target ratio of managers to engineers, it’s time to figure out the general shape of your organization!

For 35 engineers and seven engineers per manager, you’re looking at five managers (35 divided by seven) and 1.8 managers of managers (Math.log(35, 7)).

For 74 engineers and six engineers per manager, that’s twelve managers and 2.4 second-degree managers (Math.log(74, 6)).

In a growing company, you should generally round up the number of managers, as this is a calculation “at rest”, and your organization will be a living, evolving thing.

Once you have the numbers, then these are useful to ground you in the general number of teams and groups of teams you should have.

In the first case with 35 engineers, you’re going to want between one and three groups, containing a total of five or six teams. In the latter with 74, you’ll want two to four groups comprised of twelve to fifteen teams.

Once you’ve grounded yourself, here are some additional considerations:

1. Can you write a crisp mission statement for each team?
2. Would you personally be excited to be a member of each of the teams, as well as to be the manager for each of those teams?
3. Put teams which work together (especially poorly) as close together as possible. This minimizes the distance for escalations during disagreements, allowing arbiters to have sufficient context, but also most poor working relationships are the byproduct of information gaps, and nothing fills them faster than proximity.
4. Can you define clear interfaces for each team?
5. Can you list the areas of ownership for each team?
6. Have you created a gapless map of ownership, such that everything is clearly owned by one team? Try to avoid implicitly creating holes of ownership. If you need to create explicit holes of ownership, that’s a better solution (essentially, defining unstaffed teams).
7. Are there compelling candidate pitches for each of those teams?
8. As always, are you over-optimizing on individuals versus a sensible structure?

This is the least formulaic aspect of organizational design, and if possible it’s a good time to lean on your network and similar organizations for ideas.

Staffing the teams and groups.

With your organization design and headcount planning, you can roughly determine when you’ll need to fill each of the technical and management leadership positions.

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

1. Team members who are ready to fill the roles now.
2. Team members who can grow into the roles in the timeframe.
3. Internal transfers from within your company.
4. External hires who already have the skills.

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 also because reorganizations that depend on yet-to-be-hired individuals are much harder to pull off successfully.

Specifically, I’d recommend having a spreadsheet with every single person’s name on it, their current team and their future team. Accidentally missing someone is the cardinal sin of reorganization.

Commit to moving forward.

Now it’s time to make a go decision. A few questions to ask yourself before you decide to fully commit:

1. Are the changes a meaningful net positive?
2. Will the new structure last at least six months?
3. What problems did you discover during design?
4. What will trigger the reorg after this one?
5. Who is going to be impacted most?

After you’ve answered those, make sure to not only get your own buy-in, but also from your peers and leadership. 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 (which, if history holds, it almost certainly will).

Rollout the change.

The final and often times most awkward phase of a reorganization is its rollout. There are three key elements to a good rollout:

1. Explanation of reasoning driving the reorganization.
2. Documentation of how each person and team will be impacted.
3. Availability and empathy to help bleed off frustration from impacted individuals.

In general, the actual tactics of doing this are:

1. Discuss with heavily impacted individuals in private first.
2. Ensure managers and other key individuals are prepared to explain the reasoning behind the changes.
3. Send an email out documenting the changes.
4. Be available for discussion.
5. 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.
6. Double down on doing skip-level 1:1s.

And with that, you’re done! You’ve worked through an engineering reorganization. Hopefully you won’t need to do that again for a while.

As a closing thought, organizations are both (1) collections of people, and (2) a manifestation of an idea separate from the individuals comprising it. You can’t reason about them purely from either direction. There are many, exceedingly valid, different ways to think about any given reorganization, and you should use these ideas as one model for thinking through changes, not a definitive roadmap.