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.
Certainly this is just the beginning of interesting organizational design topics,
but they are some of the ones I think are most interesting.