How Twitter grew a single team into a thriving distributed community

At the end of 2020, web development at Twitter was done by a small group of engineers on a single team. But we had big aspirations for the future.

We wanted to introduce features like Spaces, Communities, Topics, and more in the year ahead. There was a new design on the way, and we had lots of web-specific projects like type safety, improved scroller performance, and GraphQL adoption in the works.

To accomplish it all, we knew we needed to scale and restructure the way we were organized. We had to face the new reality of having dozens of cross-functional product teams all working on the website, each with just a few web developers. Because there would be no single management chain for all the web developers, we realized we’d have to help bind the otherwise isolated developers together into a ‘community’ outside of reporting lines.

However, rapidly switching from a single team into a community of teams comes with a host of challenges, from quick culture shifts and structural strain to additional mentorship and onboarding pressures. Even though expanding would be hard, it was important to us that we’d maintain the tight-knit and collaborative environment we’d already built and seen success with.

Fast forward a year, and we’ve learned a ton about managing the growing pains of a rapidly scaling community. Now we’re sharing our approach – from running retrospectives and implementing the new team structures to building community among engineers from different teams – and offering our advice to other teams on a similar journey.

1. Preparing for change

To start, we conducted retrospectives with our existing team and asked everyone to write down the things they most valued about the web development community. This allowed us to codify and preserve what mattered to our engineers. They talked about enjoying the close community feel, collaborative work, timezone-aware communication, and our ‘learn it, improve it, teach it’ (LIT) mantra. We wrote all these values down into a community working agreement.

This agreement became the charter of our new community. It also included processes for how we were going to share these values with our new hires and engineering managers, and a Request for Comments (RFC) process for updating our community norms as we evolved.

2. Creating vertical teams

Next, we introduced the new vertical team structure. Where previously we’d been one single team with a common manager, we were now transitioning to multiple vertical teams with a few web developers and several folks from other disciplines in each.

Think of a specific project you want to get done, say building Direct Messages, and picture all the potential people you’d need to pull that off. Now give them a common manager, and you’ve got a vertical, full-stack project team.

We chose this vertical structure because it provides the most accountability, clarity around staffing, and encourages communication and deep product thought more than horizontal teams (where everyone with the same function reports to one manager). The vertical model has provided several benefits:

• Each function, like product, design, and engineering, stays in lockstep with each other with less communication and effort required.
• Each individual on the team functions as part of the product development lifecycle – from ideation, to prototyping, to production.
• Teams have more predictable staffing across each function and project. Usually, the team will get to an equilibrium headcount where each function moves at the right speed relative to the others; you have just enough backend engineers and designers to support the pace of your client engineers and vice versa.

However, it has also created a few challenges:

• A lack of technical peers leads to under-mentorship or lack of agency and, potentially, attrition.
• Code siloing creates a disjointed experience on the site or conflicts in shifting people around to different areas of the codebase, which lowers developer friendliness.
• Community size impacts decision-making because larger communities are more intimidating, and it’s harder to get consensus among contributors.

3. Creating micro-communities or pods

To tackle the above issues, we created micro-communities called pods. These are groups of five to ten web engineers from different teams and levels who come together to form a small technical community.

Mixing people across teams allows for cross-pollination and gives engineers access to a relatable group of peers. Pods provide opportunities for code sharing and reviewing across projects, spreading technical knowledge beyond team boundaries while providing more diverse opinions across the codebase. Pod Tech Leads (PTLs) help disseminate and reinforce information or best practices effectively alongside community presentations, and can enable valuable mentor-mentee relationships.

Pods provide engineers with a few people they can ask questions to or have a watercooler chat with in a highly-distributed world. The groups are small enough that everyone can be heard in a meeting, and they serve as a welcoming set of people folks can meet and get support from when they first join. Pods are people’s connection to the community at large, and helping people feel safe and represented within that community is the priority.

4. Creating dedicated platform teams

In addition to our vertical project teams, we also created dedicated platform teams – engineers whose entire mission is to support the platform itself (rather than the individual features being built on the platform). These teams create the foundation and frameworks that hold everything together and focus on making the platform enjoyable for other developers to code on.

Platform teams can sometimes be perceived as gatekeepers or people who constrain feature development too much. But this feature-platform conversation is a healthy tension to have. It’s important to have people who look across features, identify cross-cutting needs, and drive coordinated efforts to advance the platform and ensure it moves at the right speed.

For example, platform teams might help:

• Drive adoption of new technology to solve emerging problems and keep the platform current.
• Coordinate migration plans for new patterns, ensure they move at a manageable pace, and provide a process for proposing large codebase changes.
• Implement automated guardrails to minimize manual, rote work.

The platform teams don’t necessarily need to do all the work above themselves – they often ask for assistance from the larger community – but their existence ensures we have dedicated people leading the efforts and getting them across the finish line.

5. Identifying a clear escalation path for developers

In a vertical team world, there’s no single director or manager who represents all developers, and it’s easy to end up with no way to resolve conflicts of opinion in the codebase. This is why it’s important to have a singular escalation path or facilitators for discussions around patterns and architecture. This could be a platform team, group tech leads, Staff+ engineers, or any other folks you trust with the task.

At Twitter, we went with a pair of group tech leads but whichever path you choose, make it clear that these people are responsible for both the health of the codebase and the health of the community. It’s important to have clearly identifiable avenues for concerns to be raised and processes for grassroots efforts to be proposed, as well as having people who can set the strategy for the platform itself.

6. Focusing on teams, not groups

Teams work together to emphasize each other’s strengths, work toward a common goal, and grow. Groups utilize individual strengths to get work done, and members focus on their own goals independently.

We wanted our community to be a team, not a group. It’s easy to hear leadership say, ‘Speed up development, remove all barriers and overhead, no blockers,’ and think that means you can’t have a community. But in actuality, the absence of community introduces organizational debt. People won’t be able to move around easily, you’ll encounter ‘us vs. them’ in planning and execution, and slowly the teams and their code will become walled gardens.

This is where some good old-fashioned team building (not group building) comes into play. It takes effort and intentionality to build relationships. Here are some ways we’ve encouraged people to get to know and build trust with each other:

• Most pods meet for an hour each week to discuss in-flight work, play games, or socialize.
• Each week, there are community all-hands or tech talks. A different pod is responsible for hosting and sharing a bit about themselves, as well as providing a deep dive into what they’re working on. 
• Culturally, we’ve been pushing pairing and exploration of all areas of code through booth or jam time: go pair, go learn!

The web community is large enough now that there are multiple employee resource groups and affinity groups, which are smaller, community-specific versions of company-wide groups. We have Web GeMs (Web Gender Minorities) meetups, book clubs, along with a few active Dungeons & Dragons campaigns, and local city meetups.

7. Supercharging engineering through human connections

Making human connections is how real work gets done and how all that ‘unblocking’ happens, especially in bigger companies. When you need an on-call swap, a particularly complex piece of code reviewed, or some help debugging that one pesky test, it’s much easier to ask someone you’ve just played a game of Codenames with for help, than what might otherwise be a random person from another team with an intimidating title.

If you work on the same codebase, you’ll eventually have to interact. And it’s much easier doing so with someone you’ve already met in a relaxed setting than when everything is on fire. Cultivating the human side of our codebase has been key for supporting our tight-knit culture as we’ve grown and making the web community an enjoyable place to work.

Reflections

As we’re writing and sharing these thoughts, the web community at Twitter remains a work in progress and continues to grow. The most important thing is that we are adaptable, both to the needs of the company and to the needs of those in our community. There are still bits we haven’t figured out, but we’re confident that we’re in a place where we have the means to figure them out.

Twitter is still hiring and expanding its client teams, and we meet with every new manager and contributor in the community. One of the first things they always say is, ‘I’ve heard good things about the web community.’ Hearing that compared to what we heard a few years ago is hugely gratifying. It means people are happy at work and that makes us happy to come to work. And in the end, that’s what it’s all about.