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:
Validate organizational change is the right tool.
Project headcount a year out.
Set target ratio of management to individual contributors.
Identify logical teams and groups of teams.
Plan staffing for the teams and groups.
Commit to moving forward.
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 reoganizations:
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:
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.
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.
Does the problem already exists?
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
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 it’s
approximate total size. I recommend reasoning through this number from
three or four different directions:
an optimistic number based that’s barely possible,
a number based on the “natural size” of your organization,
if every team and role was fully staffed,
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 definintion
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
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 manager of
managers (Math.log(35, 7)).
For 74 engineers and six engineers per manager, that’s
twelve managers and 2.4 second-degree managers
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 later 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:
Can you write a crisp mission statement for each team?
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?
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.
Can you define clear interfaces for each teams?
Can you list the areas of ownership for each team?
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).
Are there compelling candidate pitches for each of those
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
From there, you have four sources of candidates to staff them:
Team members who are ready to fill the roles now.
Team members who can grow into the roles in the timeframe.
Internal transfers from within your company.
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:
Are the changes meaningful net positive?
Will the new structure last at least six months?
What problems did you discover during design?
What will trigger the reorg after this one?
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:
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.
In general, the actual tactics of doing this are:
Discuss with heavily impacted individuals in private first.
Ensure managers and other key individuals are prepared to
explain the reasoning behind the changes.
Send an email out documenting the changes.
Be available for discussion.
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 room.
Double down on doing skip-level 1:1s.
And with that, you’re done! You’ve worked through a 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.