« home

Most Companies Organize Themselves in One of Two Ways


Functional and cross-functional teams- both of these organization styles have their benefits and drawbacks, but there is a better way. Lets explore some of the attributes of these organizations and see what we can take from each style. The goal is to create something more suited to a fast growing product and engineering organization.

Functional

In this kind of organization, teams form around the function performed by the members of that team. A typical product development company who organizes themselves this way might have a front end team, a back end team, an infrastructure team, a product management team, and a design team. This system works well for keeping the best practices of each function aligned, but it doesn’t work for keeping different functions aligned. Each functional group gets misaligned with the next and they fight each other to solve the same problems. This kind of organization favors waterfall style development cycles, and so generally has longer development cycles than cross-functional organizations. Functional product engineering organizations put functional excellence above iteration speed.

Cross-Functional

In this kind of organization, teams form around business goals. As an example, a ride-share company might have a driver team, a maps team, a payments team, a growth team, and a compliance team. Each of these teams would have members who perform the various functions required. The maps team might have front end engineers, designers, product managers, QA engineers, and data scientists. This system works well for iterating on business goals, but can leave a product feeling disjointed and stitched together. This kind of organization tends to favor code ownership and uppercase “A” Agile processes, so they generally suffer more from the bus factor. While each team can move quickly, the interplay between the teams can be problematic; the goals of each team start to compete with each other as the priority of the business shifts, leaving each team wondering how they’re contributing to the company’s current goal. Cross-functional product engineering organizations put iteration speed above functional excellence.

A Better Way

By combining the two systems above we can create a system with all the benefits and none of the drawbacks. There are two kinds of teams in this system: function teams, and project teams. An organization like this has functional groups (back-end engineering, design, mobile, QA, etc.), but those groups wouldn’t tackle the work independently. These teams guide the process, quality, and usability of their chosen function.

While the function teams define the environment in which the work gets done, the project teams actually do the work. Once projects are prioritized for the organization, team members from each functional team are chosen to take part in project teams. These teams are short lived and only exist for the duration of the project. Each project team contains just enough expertise from each functional team to complete the project without pulling in outside resources. This allows communication to flow without having too many cooks in the kitchen. Once the project completes, the team disbands and the members rotate onto new teams for new projects.

Organizing teams this way allows your organization to focus on what is important regardless of your functional team structure, allows your team members flexibility in the work that they do, and allows for getting many projects done in parallel.

Some Practical Guidelines

Scope your projects down to what can the team can complete in 2 - 12 weeks. Anything shorter than that is likely best done by a single engineer between projects. Attempt something longer than that and what you end up with is less likely to be what you need.

Don’t keep team members in the same part of the product. The benefit here is that you get to spread your team’s knowledge across the entire team instead of hoarding your knowledge in a select few experts. Lower your bus factor.

Don’t use the same set of people twice. You want your culture and your process to evolve as organically as possible. By rotating people through many different teams each person gets to bring the things they like from one team to the next. If something worked well on their last project, they’ll bring it to the next.

Pair new hires with someone in their function. Ramping up new employees can be challenging in traditional organizations. There is a lot of context to learn, culture to integrate with, and team practices to master. Put them in a project team with someone they can learn these things from.

Rotate people into the Tech Lead role. Give every team member a chance to show you their technical leadership and people management skills. Any fast growing team is going to need more leaders soon. This is how you can build your leadership bench.


I’ve seen this scale from an organization with 30 people in it to an organization with 500 people in it, and it’s the best system I’ve seen for staying agile and moving fast while maintaining quality. How might this system help your organization operate at scale?

@techwraith

Essays

  1. Atomic Product Development
  2. Leverage
  3. Most Companies Organize Themselves in One of Two Ways