Hacker News new | ask | show | jobs
by dln_eintr 1822 days ago
Most hierarchies are shallow in practice. Keep it simple.
2 comments

tl;dr: I agree and healthy human organizations should never scale beyond ~5 degrees of hierarchy, which is totally manageable via basic recursive JOINs in a RDBMS without fancy stored procedures or graph theory.

I like to use Dunbar's Number (100-250) to approximate the levels of heirarchy in human organizations. The idea is that these organizations are most efficient when organizational layers don't exceed ~150 elements, due to the implementation details of the human brain.

Basically, you can do log_{150}(N) to get a very rough idea of how complex the organization of N people should be. This works for small startups and entire countries. Of course, startups should probably get comfortable with the idea of teams well before hitting >100 employees. Teams can then scale into departments (with new subteams), and once there are many departments, add regional layer, strategic/executive layer, and so on.

One interesting fact is that the USA population has roughly increased by a multiple of Dunbar's number since its organizational structure was codified in its Constitution. Perhaps time for another look?

I would argue that Dunbar's Number is the wrong number to use for this. At least not by just naively dropping it in.

Remember, it represents the total number of stable social relationships a person can maintain. If you're looking to allow your employees to have personal lives, you'll want to leave ample room for their family and friends.

Maybe an important question to ask is, how much of your employees' social-emotional carrying capacity is it appropriate to consume? If 10%, then 15-25 is your number. If 20%, then 30-50 is your number.

I would argue that there's a reason for the general size of military formations: a change of size of about half an order of magnitude per level. Much more than that for sub ordinate organizations masks it difficult to know what those orgs are actually doing. So your product team might be like 8 people. Next level up us 3-5 product teams. The 3-5 of those. And so forth. It actually scales with remarkably few levels of management. It also allows space for free form connections between people on other teams.
It's definitely a big ballpark, but I think Dunbar's Number is a good place to start. If you have managers spending 10% or less of their lives on management, I don't think the organization will be very healthy. Management should be a high commitment, high compensation role.

It's also definitely a upper limit rather than lower limit. Big bureaucracies with many layers of management and small teams can work well, but no one can really individually manage 1000 subordinates.

> One interesting fact is that the USA population has roughly increased by a multiple of Dunbar's number since its organizational structure was codified in its Constitution. Perhaps time for another look?

I have had that exact same idle thought.

In 1813, each of the 182 US Representatives represented on average ~40,000 Americans. Today, each of our 435 Reps stands for about ~760,000 people. That's over an order of magnitude growth. To keep the same rate of representation, we'd need to have over 8,000 Representatives, which is clearly too large a body to get anything done.

So we're probably well beyond the point where we could benefit from a large House of Subrepresentatives and then a smaller House of Superrepresentatives that aggregate them.

Well isn’t that why we have limited federal government and defer most decisions to the states?
Who should then defer to county/parish, who then defer to city, who then defer to neighborhood
Right, that scales better than 8000 representatives in the house.
This. Throughout my years it was very common to see juniors trying to model static website dropdown menus as recursive database tables.

In practice if a menu has more than 3 levels the user experience will suffer. I keep them at 2 submenus max, possibly 1 if I can get away with it.

Not to mention most menus are not dynamic, meaning they can be just a JSON file or simple HTML.

This is wise, but in the healthcare field, there are some pretty huge trees of things that you need to deal with sometimes. I've been involved with building out a structure a lot like MeSH[0] and some disease trees similar to ICD. Some of my implementations I would definitely do differently now because both the tools and my experience have improved. MeSH's "addresses" even match the ltree syntax, so it would probably make a lot of sense to use that.

[0] https://www.nlm.nih.gov/mesh/intro_trees.html

I feel your pain. I consulted in a hospital management software and they had trees spanning 6+ levels deep and it had to be dynamic too.