March 17, 2017.
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:
Now, let's drill into each of those a bit.
There are two best kinds of reoganizations:
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:
Alright, so you're still thinking you want a reorg.
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:
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.
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 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.
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
(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 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:
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.
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:
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.
Now it's time to make a go decision. A few questions to ask yourself before you decide to fully commit:
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).
The final and often times most awkward phase of a reorganization is its rollout. There are three key elements to a good rollout:
In general, the actual tactics of doing this are:
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.