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.
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.
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.
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.
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.
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.