Team structure in growing companies

Most companies will go through several iterations of their team structure as they expand. This is for reasons that are both good and ugly: as the company expands, the team structures that previously made sense no longer do, and they need to change; equally true is that some team structures just need to be tried out before it’s clear that the company is wasting money supporting them.

In the initial days, companies can get by with very little formal structure. This was the case at the startup I founded, a small company that only grew to six employees (though all employees, after the first couple of years, were being paid out of revenue — the company was “cash flow positive”). The company developed an online multiplayer educational game, and the job functions were “programmer”, “artist”, “game designer”, and “content creator”. Everyone communicated with everyone else every day; a daily standup meeting was all it took for company-wide updates, and a weekly sprint planning meeting was sufficient to set company direction. The team moved quickly and executed well.

Another company I worked at was a multinational game developer with thousands of employees. The team structure there was to break out the team for each game into an almost entirely self-contained unit. Each unit could be dozens to hundreds of people, and it was almost completely self-sufficient. Graphics programmers would develop the game’s rendering engine from the ground up; artists would create entirely new models, animations and textures for each version of the game; and the script engineers would program game behavior using a custom scripting language and engine. There wasn’t much in the way of cross-team sharing. There was a central technology group whose charter, nominally, was to develop common utilities that could be used across multiple games, but in practice this rarely happened.

This team structure, though it obviously resulted in redundancy, may have actually been fairly efficient. Games have many specialized requirements depending on the platform, genre, and other characteristics, and trying to develop “one size fits all” technology would have been hard to scale across the company’s breadth of products. Having individual teams develop their own technology allowed them to move quickly, and allowed the company to bring many games to market in time for the important holiday season.

There was a third model that I saw in action at another company I worked for. The company was a midsize consumer Internet company with two primary lines of business; one an established business that had matured over almost a decade, and the other a fast-growing but emerging business in an adjacent space. There was tension between using resources that had originally been allocated for the mature business for their intended purpose, and using them to quickly grow the emerging business.

The team structure at this company was to have separate teams for the user-facing parts of the two businesses, but to share a number of other teams that did things common to the two businesses — for example, develop data processing pipelines that both businesses could use.

When deciding which model works best for your company at its current stage of development, it’s useful to keep the following concerns in mind:

  • Cross-team dependencies: No matter which way you slice it, there will be dependencies across teams: A cannot get her work done till B, in another team, finishes his feature. Cross-team dependencies usually cannot be eliminated, but think about how to reduce them, as well as mechanisms for resolving dependencies when they do arise.
  • Sharing (human) resources: In some cases, having shared pools of people (engineers, marketers, product managers) who work across teams allows best practices to quickly be applied across the company; on the other hand, vertically integrated teams can usually move faster at the cost of higher redundancy. Where you draw the line depends on, among other things, your industry’s velocity; fast moving industry segments penalize slowness, and the benefit of uniform application of a best practice across the company may be outweighed by the speed cost it imposes.
  • Resource contention: Sharing resources between teams who have different revenue and other goals means that there will inevitably be contention for shared people or technology. Tie-breakers are essential — either people whose personal KPIs include metrics from each impacted business, or processes that can be used to objectively determine who gets access to the shared resource first. “First come first served” rarely works in a scalable way.
  • Sharing code and infrastructure: Does sharing extend to code, release and deployment infrastructure, etc? It’s entirely possible for multiple teams developing products under a single domain to operate on different codebases and deploy to different production servers, even if other parts of their technology are shared. In some ways this is reminiscent of the monolithic versus microservices architecture debate, and the solutions can be similar; one solution might be to have shared teams develop microservices that are called from different user-facing products by product teams. But the line between “user-facing code” and “microservices code” can be blurry, and may need to be determined on a case by case basis (in addition to being adjusted periodically — consider the product-specific code that can be generalized and used by other product teams, and which therefore needs to be abstracted into a microservice).

Team structure is a fascinating topic, and it’s worth keeping in mind Conway’s Law: the structure of your company’s product will likely reflect your internal organizational structure. Make sure that structure is something you’ve thought carefully about.