How to divide your organization into teams

Some thoughts about how to build your company team division correctly.

People tend to look for an ideal recipe to organize a company (e.g. the spotify “squads” model — yes or no? product led or engineering led? etc’).

Better than focusing on a solution, it is better to focus on problems at hand. This means focusing on bottlenecks preventing your company from doing what it’s supposed to do today.

If you don’t yet have a problem in mind, I wouldn’t worry about the orgchart. That would be premature. Wait and let the infinite complexity of reality teach you.

When a recurring problem has presented itself, you really want to get intimate with it. Talk with people and get some insight about how the problem looks like for different people and from different angles. Don’t get into the solution-discourse just yet. A good tool for this is debriefing.

Worry not, once you have identified a problematic recurring pattern, you’ve done most of the work.

We’ll take a look at some classic problems and see what kind of principles they imply.

I’m not sure if people are well supervised

Typical quotes:

• Some people work really hard while others don’t
• I see people socializing all the time but not working
• I can’t supervise those working remotely well enough
• I feel like there’s too much loitering

The problem here is not so much about the object (“the staff”), but about the subject of this thought, the “I” in these quotes. If you sympathize with these quotes, you should transform both your discourse and your inner monologue from revolving around supervision to revolving around purpose. Once purpose is defined, measuring efficiency is no longer required, because you can measure the goal itself. When it is not defined, it’s highly unclear what efficiency even means. Probably something like “this person is the last one to exit the office and first one to answer on slack”. You don’t want that to be the point.

How it relates to orgcharts: A group of people should ideally have one goal at a time, and they should know what it is, how it is measured and have agreed that it makes sense (think “enthusiastic consent” style from sex-ed).

A famouse anti-pattern here is giving a metric to a team that cannot succeed in maximizing it because it depends on something beyond the team’s control. If no formal consumer-provider relationship have been established between teh team and its dependencies, then it will not make sense to expect a good result.

We have defined goals, but the even with a lot of resources the team isn’t moving the needle

Typical quotes:

• As we allocate more resources, we’re not getting the expected gains
• There isn’t enough focus
• People are doing duplicated work
• There are a lot of context switches
• Onboarding isn’t as easy as it should be
• One needs to know too much stuff to get something done
• Onboarding is hard because there’s so much to learn
• Experienced members of the team are required for anything to be done end to end

Assuming that what we want to get done is doable, and does not present a research risk, the fix here does sound organizational.

Specialization is a fundamental principle of economy in the macro sense and in the micro sense. In small teams people tend to do a lot of stuff, but when organizations grow, there’s just too much knowledge and skills needed than what can fit in one person’s mind and specialization is required.

Specialization is done by identifying high level problems and subordinate problems, and finding good interfaces between teams that work on them. This should be familiar to programmers as they often do code refactoring for the same reason. The way this is done is by taking a high level goal, and think if there are relatively independent subunits that can be worked in a context free manner. For example, perhaps your CI/CD scripts are very similar across different products and be cleanly factored out or provided as a service by an external team.

If it’s hard to identify such sub-units to facilitate deconstruction, it could be a sign that the product or system itself needs to be refactored. Such refactoring would create distinct parts with relatively small APIs which can be a guideline for the team structure in turn. This naturally would yield sub-metrics or goal definitions for the new teams, which support the overall metric for the “client” team. By repeating this process you would end up with layered teams, each layer supporting the other one.

Note that many times there is more than one consumer team to a provider team so don’t be tempted to necessarily subordinate the service providers to the service consumers. In other words organizations behave more like directed acyclic graphs rather than trees.

Ideally the teams should be thought of as mini companies that have an economical incentive to provide good services to multiple clients. More about this in Doing Less.

The quality of work being done is subpar

Typical quotes:

• People lack mentorship and so their skill remains mediocre.
• No one in the team understands a certain subject really well.
• My manager cannot evaluate the quality of my output.

Here I will be rather opinionated — I consider the best model to optimize on quality is the apprenticeship model. Think Jedi master and padawan. Your manager knows how to do your job really well, and so can make your better at it, which makes it natural to look up to them.

This is drastically different from another rather common model which separates technical proficiency from people management. I find that people management is drastically overrated. Adults usually can figure stuff out for themselves given ownership and motivation, and these are structure related rather than based on the manager proficiency.

The point of the apprenticeship model is that the best decision maker is in charge, otherwise there would not be respect to the chain of command.

When people hire a “people manager” they make it so the source of skill is not the decision maker. A skillful manager would know when to insist, when to teach and when to let imperfection slide. A strictly “people manager” would not.

Note that this doesn’t mean the most skilled should be the manager. Mentorship also requires communication skills and empathy, context and responsibilty. Luckily I’ve met many people who have all these qualities, and I’d even say they are correlated.

So if quality of outcome is subpar, see if your managers are the best decision makers, and have the skills to effectively guide work done by their reports. Don’t be misled by impressive resumes or fancy titles.

We have a setup that makes sense, but we keep arguing about priorities

Typical quotes:

• We have endless prioritization meetings with many participants.
• Often the same resource is needed for two teams and it’s challenging to decide which is more important.

I’d argue that more often than not, this is the specialization problem in disguise. Because if the cross team interface is limited, it’s not a common scenario where there are two completely unrelated requests about it. So if this happens take a moment to reconsider the interface — is it minimal enough? can you refactor again rather vs just deciding that something is more important than the other?

If you are certain the team purpose is contained enough and still there is so much to do, this sounds like a great place to add people to. Contained teams with very specific goals would benefit greatly from added personnel, and they have the appealing property that they have an end in sight, meaning you can actually finish the component once and for all. This lowers the risk of bloated teams with “disguised unemployment”.

We aren’t meeting expectations well.

Typical quotes:

• Task descriptions are lacking
• Tasks keep changing mid work
• Deadlines aren’t met although “agreed upon”
• We have a lot of meetings with a lot of people and no clear decision maker.

This is a symptom of a separation based on “the caste system” of the tech world — a department for product managers, a department for engineers and never the twain shall meet other than within Jira.

An external decision maker for a goal oriented team is a terrible idea. The whole point of defining a goal is to release the team to find the best way on its own. The whole point of a division to teams is to minimize dependencies. But if the team cannot move without an external stakeholder say-so, ownership will disappear.

Another critical aspect is that goals should have a single mutually agreed owner. Never two. Especially not two that report to different ladders.

If something is important, then a single person should be in charge of it.

In summary

1. Don’t preoccupy yourself with orgcharts before there’s concrete reason to
2. Talk about problems, invest your energy in characterizing them before you discuss solutions. never discuss solutions without a well defined problem in context as you will end up arguing in a non constructive manner.
3. Independency can be achieved by keeping the interfaces between the teams small and making their dependencies explicit. You should end up with a directed acyclic graph.
4. Ownership is provided by providing each team with a small (1?) measurable goal, rather than tasks.
5. Consequently observe each team’s metric and their relations to other teams, that is who is the team providing a service to and what teams does it rely on.
6. It’s really not about “departments” or roles. I try not to think in terms of profession or role simply because if you have a marketing department, then you’ll hire marketing people, but do you really need 3 marketing people siloed in their own room?
7. Make the best decision makers team leads.