Rules of thumb for org design.
While writing How to evolve an engineering org, there were a bunch of organizational design “rules of thumb” that are interesting to discuss but didn’t fit into the article’s structure. I’ve collected them here.
Works best after reading How to evolve an eng org.
Company needs before individual wants
Generally, you should structure to solve your company’s needs, and avoid fitting your structure towards individuals’ personal asks. If you fit heavily on individual asks, you’ll end up doing frequent reorganizations as folks’ preferences evolve and new folks are added into the organization. Balancing between different folks’ wants will create the appearance of politics, and you’ll rapidly accumulate organizational debt.
As your organization’s needs evolve, you’ll want to realign your organization to fit with them, which will run into friction of folks who the current organization was designed around. In the best case this creates tension, and in the worst case prevents useful organizational adjustments.
ƒ(people, process, structure)
A productive organization is a function of people, process and structure. You need all three. Adding more people doesn’t inherently make you faster, and isn’t the only way to get faster.
Remain skeptical of headcount as the primary driver of productivity.
Gelled teams are magic
Team that have worked together for a long time are incrediably productive. Teams that constantly shift membership never gel, which is yet another reason that long-running rapid hiring slows down teams.
Focus growth to allow some teams to gel, even as overall you’re hiring rapidly.
Balance internal and external managers
If you have no external managers, you’re going to reinvent every management best practice from scratch. That’s slow, painful and you’ll be stuck in a variety of local maxima far longer than necessary.
If you have no internal managers, you’re going to dillute your culture, and frame management as either a dominant or irrelevant position. It also suggests that folks are disinterested in your framing of management, which is a worrisome signal for your ability to hire strong external managers.
Set a target ratio between internal and external managers, roughly 50:50 seems to work well, and work to maintain that ratio.
Plant seeds of success early
Durably good teams require good composition: some folks earlier in their career, some later in their career, a reasonable ratio of managers to engineers, and so on. Likewise, there is a momentum to early inclusion efforts that builds steam towards either an encouraging culture or a brittle one.
This is true for codebase quality efforts as well. Introduce good practices, clean interfaces and effective ratchets early on. These will be cheap early on, and extraordinarily expensive to retrofit later.
A lot of organizations end up optimizing for work-about-work, as opposed to optimizing for work. This ends poorly.
For example, perhaps you have a giant infrastructure engineering team serving a very small product engineering team. All this amazing infrastructure is a multiplier on the productivity of the product engineers, but the absolute value being multiplied is just too small to make it worth it.
Leveraged work is quite seductive, but don’t over-invest.
- Building technical leverage
- Providing pierceable abstractions
- Product management in infrastructure engineering
Certainly this is just the beginning of interesting organizational design topics, but they are some of the ones I think are most interesting.