How to scale #TechTeams, with Stan Polu (Stripe)

This article includes key takeaways from Stan Polu’s talk on how to scale tech teams. Check out the full video on Youtube or get the latest from our Scale series.

3 key mindsets

Mindset #1: Early flocks

Early teams can scale without a set engineering organization. Stripe scaled up to 100 engineers without one. Stan compares the way these team work to a flock on account of their ability to stay synchronized thanks to three properties: local separation, range attraction, and alignment. For the team at Stripe, trust between engineers meant that any member of the team could take a problem and work on it with minimal supervision, providing the local separation. The team also had team-wide communication channels — in the form of open email lists — to build and access a rudimentary knowledge base, supplying range attraction. Finally, the team also benefited from a clear mission and was able to stay aligned through it.

Note: As with a flock, when one of these parameters breaks, the entire org collapses. Which is what happened to Stripe when the open communication channels were no longer enough to keep long range attraction between the 100+ engineers on the team, initiating phase 2 of scaling their tech team:

Mindset #2: Scaling through continuous reorganization

In order to scale an engineering organization from dozens to thousands of engineers, the team at Stripe was constantly shifting. A process that is necessary, each consecutive attempt serving its purpose at a given point in the scaling phase, but that should also be closely monitored to avoid negatively impacting the team’s overall productivity and ability to deliver on a growing amount of projects. Stan’s take on it: if you’re not iterating frequently in the early stages of your engineering org, there’s probably a pocket of growth that you haven’t tapped into to there. Iterate too frequently on it and you’ll end up creating friction and slowing down growth.

Mindset #3: Creating leverage

Stan insists on the importance of creating an environment in which engineers have a lot of leverage. In this type of setting, engineers can take ownership of a project and deliver impact to the company through their own initiative. For Stan, one such project he led at Stripe consisted in opening new and alternative payment methods to improve product-market fit — notably in Europe. Bottom line: make the organization trust engineers who want to take risks, the payoff will be worth it.

5 key best practices

Best practice #1: Keep the bar high

The first hires always involve some measure of luck. As the team grows, however, it becomes important to streamline the hiring process. For instance, at Stripe, this meant relieving tenured engineers from the early stages of the interview process. Growing teams also means keeping track of headcount objectives takes on greater urgency. Being able to meet these targets at Stripe was essential to keeping the team on track to delivering in line with the roadmap. However, both forces create pressure to lower the bar for hiring standards. Being aware of this is important to create mechanisms to counter it. For instance, the Stripe team give each person involved in the hiring process a right of veto over a candidate.

Best practice #2: Onboarding at scale

A buddy system is tremendously valuable for new hires to feel welcome in the team. Tech stack, best practices, and culture are all transmitted more effectively through a buddy system. The downside is that the “buddy” ends up repeating the same information, which creates an opportunity to build a more scaleable onboarding. At Stripe, new hires are welcomed by cohorts which are attributed to a single mentor overseeing their progress over a 4 week development cycle.

Note: The cohort system creates a consistent onboarding experience, an efficient ramp up on the tech stack, as well as a great framework to receive elements of Stripe’s engineering culture through tenured engineers. However, it is also highly demanding for the mentor. Stan suggests combining both approaches to achieve the best results.

Best practice #3: Moving the needle

Stan uses a simple framework to better understand developer productivity within a growing team. He represents it by two curves: the first is concave and illustrates the declining output with each new member added to the team. The second is convex and describes the increasing workload required to maintain a functional product as the team scales. Crucially, the area between the two highlights an org’s ability to foster innovation:

Understanding the forces at play on each of these curves allows engineers to craft an organization that is able to maximize the overall productivity of the engineering team. For instance, for the concave curve, politics, lack of context, and systems complexity all tend to bring down the overall output of the team. Conversely, tooling and creating a safe environment for deployment can positively impact the curve. For the concave curve, decoupling and systems architecture can maintain low requirements for the team to deliver whereas complex feature requests, rapid growth, and technical debt all contribute to increasing that baseline.

Note: For Stan, the main objective of an engineering organization is containing the forces that negatively impact individual productivity and baseline requirements to run the product, and encouraging those that can improve output per capita and lower the threshold for keeping the lights on. Once both curves intersect, companies enter what Stan refers to as the “innovation coffin corner” after which stage companies have to acquire innovation or place members of the team outside of their org in order to keep innovating.

Best practice #4: Using tech debt

Stan likens technical debt to financial debt: it’s a tool. And just like financial debt, it can be double edged: on the plus side, it helps to rapidly unlock new pockets of growth. On the negatives, it also needs to be paid back later. His advice: when it comes to debt of any kind (technical or otherwise), if you’re using it too little you’re probably missing out on some opportunities to move your business forward. Conversely, use it too much and your progression will grind down to a halt.

Best practice #5: Decoupling the team

One of the main levers to decrease the baseline to keep the lights on is what Stan refers to as “decoupling”, literally making the individual parts of the team work autonomously from one another. This can be done by keeping distinct microservices which the team can work on without impacting others (avoiding so-called “spaghetti code”). It can also be done by relying on remote teams. As Stan explains, the requirements for remote work are for everyone on the team to maintain well-structured communication and documentation, resulting in greater efficiency for the organization as a whole. To facilitate the transition towards more remote processes, Stripe is moving from one historic tech hub in SF — which will remain at the current headcount — to multiple tech hubs across the world (and spanning different time zones) — which will progressively be brought up to similar headcount.

Note: Stan is a strong advocate of remote teams. He also insists that this can only work in certain types of org which are able to keep strong ties with their remote members.

Subscribe to be notified of the latest Scale talks.

About Stan Polu:

Stanislas Polu is a Software Engineer at Stripe. Joining the company in 2015, Stan saw the team shape its culture and processes to scale from 80 engineers based in the SF HQ to hundreds worldwide. Stan shares his experience on how Stripe built a world-class tech team, and shares his insights on how others can follow in their tracks. Follow Stan on Twitter.