Engineering org


Our engineering organization is divided into mission based teams that contain the necessary cross-functional skillsets to achieve the desired mission. The leader of each team (at every layer) is responsible for ensuring appropriate cross-team collaboration happens when necessary.

Minimum viable team

A minimum viable team contains:

  • A product manager
  • An engineering manager
  • Appropriate product design support depending on the work of the team
  • Four engineers, with a minimum of two per skillset (examples: 2 backend + 2 frontend, 4 backend, 4 frontend)

New teams will not be created until/unless we have committed headcount in the plan to staff them to a minimum viable team within 3 months of forming the team, or to whatever is necessary to make the new team successful, whichever is larger.

We want each team to have sufficient engineering capacity to not only be able to deliver on their roadmap but so that teammates feel:

  • they can take PTO without worrying about the team’s commitments
  • teammates have ample time to experiment with new ideas or improvement that exist outside the team’s roadmap.

The number of teammates that allows teams to achieve these objectives should be considered their minimum team size.

Optimal team size

The optimal engineering team size is somewhere between minimum and maximum size, and depends on the team’s scope, the engineering manager’s capacity, and teammate capabilities. We trust engineering managers to make the right decision for their team.

Maximum viable team

We expect engineering managers to not manage more than 8 people directly.

If a team is approaching capacity and we need to continue to grow, the manager of the team should work with their manager to create a plan to grow and divide the team. This involves identifying a new engineering manager (either internally or hiring), which can take ~3 months, so it is important to plan ahead. In advance of identifying a new manager, the manager of the team at capacity should already start organizing the team’s work as if they were managing two separate teams. This eases the team into the transition before we actually have a new engineering manager onboard.

When teams grow and divide, we prefer to grow the org horizontally, not vertically. This means the new engineering manager would be a peer to the existing engineering manager, not report to the existing engineering manager, as long as the engineering manager’s manager has capacity. If the engineering manager’s manager doesn’t have the capacity, then we need to make a higher-level decision about how to adjust our org structure to support the growth we need.

Transferring teams

If you are already at Sourcegraph and see a current or future opportunity that you’re interested in, please tell your manager to figure out next steps. If you don’t feel comfortable talking to your current manager for any reason, please reach out to your manager’s manager, or someone in people ops. See also the process for switching teams.