How we approach our org structure

Harvard psychologist J. Richard Hackman’s research on why larger teams lead to reduced ability to get stuff done yields the key to understanding why solving this problem matters. As you add people to a group, it’s not the number of people that creates the problem … It’s the communication links needed to have the right level of knowledge to do our best work. The formula is:

(the number of people(the number of people-1))/2

Janet Choi at Buffer writes about this in more detail here.

There is also the matter of Dunbar’s Number, which is a suggested cognitive limit to the number of people with whom you can maintain a stable relationship. Our Sourcegraph relationships are just one set of relationships in our lives. If the suggested limit is 150 people, then it starts to become clear why this problem only continues to feel bigger and bigger as a team grows. Basically, once a team grows beyond 50 people, feeling informed, knowing who to work with and how, getting help, so many things we need to do every day … start to feel really hard.

For a team, this is usually solved by building a leadership layer in and moving to teams within a team.

At Sourcegraph, we are all-remote, global, and asynchronous by default; we also desire that folks show up for each other with high agency. This foundation creates an opportunity to solve for the number of communication links required and create a high functioning, successful team with psychological ease that is far larger than the usual limits of 5–10 folks. Dunbar’s Number will still come into play, but formalizing a team within a team structure can come much later (more around 35–40 folks, instead of 10–15). This will help us avoid silos and continue building on the foundation of closeness that is very present at the team’s current 19 person size.

So, we reimagined our Customer Support organizational structure for our current team of 19 folks and up to 35–40 folks, throwing aside conventions, building off of being all-remote, global, asynchronous by default, and desiring high agency, and determined a solution where the following is true:

  • CS maintains an open, healthy team that continues gifting psychological ease to seek help without hesitation
  • CS leadership functions as a unit of coaches, building deep relationships with those who report directly to them and strong relationships with those who do not; always checking ego and accepting feedback with grace to center the wellbeing and success of each individual on the team
  • Application engineers have a primary coach (their manager, who they report to) and are also supported by the rest of leadership
  • Application engineers never have to wait for their particular manager to be online to get help when they are stuck; any leader online can help
  • Application engineers have opportunities to work with all of their peers and are not limited just to those who report to the same manager
  • Everyone gets to participate in team rituals during a “prime” hour in honor of their chosen schedule and not at the very start or every end of the day only just because “time zones are hard” for synchronous rituals
  • Everyone remains aligned and consistent where it matters, ensures effective and thorough asynchronous communication, and exercises thoughtful high agency and creativity as much as possible

This is what we came up with…

If you’ve played sports, watched sports, or just watched Ted Lasso, you have enough context to draw on to understand the overarching idea for this reimagining of our CS org structure is to model how we organize more after a sports team than a traditional, strict hierarchy-based corporate team. For example, in baseball, you have a head coach (the team manager), a bench coach, a pitching coach, a bullpen coach, a hitting coach, and base coaches. The pitching coach is the primary coach for the pitchers; the hitting coach is the primary coach for those who go to bat (technically this is all players in National League, but that is another RFC for MLB on why National League is more interesting than American League baseball 🙃). The idea is the same here … every application engineer reports to one manager and that manager is their primary coach (see “after” org chart in the background section). But like baseball, that manager is not the only leader an application engineer works with, talks with, collaborates with; and also like baseball, managers practice a first-team approach.

Coaches…

  • Modify approach based on the individual they are working with, talking with, collaborating with
  • Actively listen, seek and provide context, ask questions (instead of talk at/default to telling)
  • Empower an individual to make their own choice, take their own steps, make their own decisions

The goal is for these interactions to feel natural for all involved and this proposal outlines how that could be possible by accounting for:

  • 1:1s
  • Career roadmapping/support
  • Getting help
  • Team meetings
  • Team announcements/initiatives
  • Group projects
  • Social gatherings
  • Quarterly check-ins
  • Performance management
  • When to iterate on the org structure

1:1s

Every member of CS has a regular weekly 1:1 with the manager to whom they report. We consider this 1:1 a sacred space that each member of CS gets to use with their manager how they choose. Each manager can put their own spin on these to ensure that folks to whom they are primarily responsible get the most out of it.

Career roadmapping/support

Every member of CS works with their manager to start creating their personal career roadmap when they reach their 90 day milestone. The practice starts the same for everyone, answering a series of questions that touch on and go beyond typical career questions. Each manager pushes the folks to whom they are primarily responsible to think through their plans and helps them identify who else in the organization/beyond can help support them to get to where they want to go.

It is very likely that other managers on the team may be brought in to support someone’s career roadmap as a secondary coach with a speciality in some area relevant to that member of the team.

Getting help

If an application engineer needs help, they have the following avenues:

  • If it’s technical, they post in #customer-support-internal to get help from their fellow application engineers
  • If it’s about how to handle a particular situation, they should go to their manager. If their manager is not online, they can either create a post in #customer-support-internal and @ mention @cs-leadership for another manager online to help and either work in that thread or request that whomever is going to help DM them if they need to chat privately,

We want to have a global team where folks can work anywhere in the world. We never want that to mean someone has to wait to get the help that they need.

Team meetings

For both weekly planning/retros and ad-hoc team meetings, each manager will facilitate a session on Wednesday at and . The application engineers in attendance at each session will change monthly based on what works best for each application engineer that month. Each application engineer has one option that always aligns with their working hours, and a second option that either aligns or lets them flex slightly if they want to easily experience another facilitation style.

At the end of each month, everyone participates in a quick Slack vote on which times will work for them in the coming month. Based on this, which application engineers participate in what time is identified randomly and each manager adjusts the invite for which they are responsible to reflect the correct participants for that month.

This model will let folks continue to work with and bond with folks across the team and not be limited just to those who report to the same manager.

Each manager can put their own spin on the planning/retro they facilitate. Each week, the agenda will have some items that every manager will cover to ensure alignment across the entire team, and they will have space to put their spin on it to keep this synchronous time interesting and engaging.

If any all-team wide ad hoc meetings are also needed, this same model will be used, where the managers each facilitate a session and participants opt into which times work and are randomly identified for one of the sessions that works for them.

Aimee will attend as-needed and when needed, will attend all sessions.

Team announcements/initiatives

Whenever there is an announcement that will impact the entire team, the leadership team will default to asynchronous communication and any member of the leadership team may take responsibility for the communication in #customer-support-internal. Where the announcement benefits from synchronous communication, the leadership team will decide whether it’s something that is best shared in the weekly planning/retro or during 1:1s.

Whenever there is an initiative that requires the entire team, one member of the leadership team will take responsibility and determine how we will facilitate, involve everyone. This could look different with each initiative, but whichever member of the leadership team takes responsibility, they will ensure to facilitate the initiative with healthy change management practices.

The idea here is that any member of the leadership team may share/solicit important information to/from the entire team, not just a CSE’s direct manager.

Group projects

For our OKRs and other initiatives, various application engineers will need to collaborate together in various group formations. Folks can work with folks across the entire team and will never be limited just to the folks who report to the same manager.

Social gatherings

We will continue to have several optional ways for the team to engage socially:

  • Asynchronously in our #cs-social channel
  • Synchronously 1:1 via the random #weekly #customer-support-weekly pairing donut app pairing
  • Synchronously on Friday via two afternoon/end of day social sessions that are scheduled at and . Everyone is invited as optional and whoever shows up for the session gets to decide how they want to enjoy each other’s company.
  • Asynchronously and/or synchronously during quarterly virtual events (until we are able to move to consistent in-person)

Quarterly check-ins

Every quarter, Aimee will check-in with each member of the team to catch-up, see how things are going, gather perspectives, and validate the team is headed and/or operating the way we want.

Performance management

Everyone only has one manager and that manager is the individual responsible for any performance management that is necessary. At no point is this org structure meant to make it so that anyone feels like they have multiple managers. While any leader may offer positive feedback, only someone’s direct manager or a peer will offer constructive feedback unless the situation is so dire that another leader must do so (this would be very, very rare). There may be times when someone and their manager agree to involve another leader in soliciting feedback (for example, during the 360 review process) and that is entirely acceptable.

When to iterate on the org structure

When our team reaches 40 folks, we will iterate on the org structure proposed here to be sure it is appropriate for additional growth. At any point before then, we will also iterate as-needed, as a result of learning what we learn checking-in on whether things are on track via the following methods:

  • Quarterly engagement survey results
  • Any retros scheduled to specifically assess how the org structure is working or not
  • Validating that ouur #customer-support-internal Slack channel remains vibrant
  • Validating that our #cs-social Slack channel remains vibrant
  • Validating that application engineers continue to ask each other questions, seeking and giving each other help
  • Checking to see if over time, everyone has formed stronger/deeper relationships with each member of the team than they have now
  • Checking in to see if application engineers feel at ease regardless of what leaders they are working with, talking to