Rules of thumb for org design.

Published on March 17, 2019. management (204)

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.

Sizing engineering teams

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.

Consider the team you have for senior positions

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.

Leveraged work

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.

Certainly this is just the beginning of interesting organizational design topics, but they are some of the ones I think are most interesting.