How to build and scale a Staff+ engineering community

Staff and principal engineering roles may feel in-vogue and prestigious, but in practice, they’re often lonely and ill-defined.

The public visibility of these roles has overtaken our internal processes for cultivating the individuals who inhabit them.

At Stripe, I’ve spent the last couple of years working on a grassroots effort to build our own Staff+ engineering communities, as a way to make these roles more fulfilling and help new Staff+ hires land successfully.

This has involved a thoughtful approach to getting buy-in for why these communities should exist at all, a pragmatic approach to getting them off the ground, and an eye toward ensuring they can continue to scale as Stripe grows around them.

The value of a Staff+ community

Before coming to Stripe, I spent eight years at Yelp. When I left, my company history, technical expertise, and social network all disappeared in an instant, leaving me unmoored as I started a staff engineer role at a new company.

I suffered many of the challenges Amy Unger describes in her talk, ‘Starting a new job as Staff+’, including understanding the new organization, rebuilding a network, and clarifying my immediate goals. I wanted to find a community of like-minded engineers to learn from (and, let’s be honest, occasionally vent to).

At Stripe, I discovered that the Staff+ engineering community was small, informal, and not yet doing staff-specific onboarding for new hires.

So I started with the most basic step: bootstrapping a community focused on encouraging and supporting growth in Staff+ roles and setting new engineers up to succeed.

Getting off the ground

Staff+ roles are ambiguous, and new hires inevitably struggle to decode the precise combination of focus, skills, and framing they’ll need to succeed. For this reason, Michael Beauregard, another staff engineer, and I started an effort to build Stripe’s staff engineering community by onboarding new hires to staff expectations and best practices.

Our goal was to ensure every new Staff+ engineering hire was matched with a current staff engineer at the company for 1:1 onboarding specific to their role. Accomplishing this alongside my normal engineering responsibilities was challenging, so I optimized for simplicity and flexibility. My approach focused on:

1. Noticing every new Staff+ hire
2. Matching them against a backlog of volunteer staff buddies
3. Keeping structure loose while focusing on immediate community exposure and 1:1 time

With the help of HR, I set up a report against our employee directory so that I received a list of all new staff hires each week. Over time, I learned to ensure this included their job family, the time zone they work from, and their preferred name – all of which helped create high-quality matches with staff buddies.

I also built out a backlog of available tenured Stripe staff engineers willing to be onboarding buddies. I sourced the initial list from a wide survey, and to this day maintain it cheaply via a structured spreadsheet. For each new hire, I’d grab a buddy from our backlog, re-confirm their availability, and send an intro email by the end of their first week.

Finally, we ended the matching period (90 days) with an outro email that included an exit survey. This allowed us to vet the program’s basic value (‘Would you recommend a new staff hire take part in this program?’) and solicit feedback on how we could improve it.

Making it self-sustaining

The perfect process isn’t worth much if it doesn’t self-sustain. In the early days, I worried a lot about whether this onboarding program would survive its first year.

In the first months, we barely managed to find enough volunteers. The choice to make the onboarding period 90 days meant each new staff hire locked up a buddy for a whole quarter. And that first year was a time of rapid hiring at Stripe, which meant we needed to find an increasing number of buddies to keep up. Some months we almost ran out, which would have made matching impossible (or overloaded existing volunteers).

The solution to scaling ended up having three parts:

1. First, we built a backlog of volunteer buddies by asking every Staff+ engineer exiting the program if they’d be willing to be a buddy for future hires. This was cheap for us, had a high acceptance rate, and helped ensure we could scale along with Stripe’s hiring rate. Having some slack in the backlog also meant that high-volume start dates did not require lots of ad hoc sourcing of extra buddies.

   Second, we scaled the program operation itself. After two years of running the program with me, Michael Beauregard rotated out and we introduced two replacement volunteers. This improved redundancy for the program itself. It also pushed us to codify and document the logistics we’d quietly accumulated behind the scenes.

2. Feedback from exit surveys also led to fundamental improvements to the program: we introduced a cohort approach in which buddies would meet with groups of five or so new hires. This reduced the risk of poor buddy alignment (e.g. product vs infra mismatch) and built additional social ties among each starting class. 
3. Finally, we partnered with program managers who excelled at organizing and tracking long-term logistics. This turned out to be a great way to make the core operations of the program more self-sustaining.

The unglamorous work of building a community

It has been a long-term effort to shape the program and keep it operational over the last two and a half years. With the help of other Staff+ engineers, I’ve started offshoot programs to extend the Staff+ relationships. This includes small groups that run every six months and occasional roundtables on specific skills like communication in a Staff+ role. It’s hard work to sustain this community-building effort, but I deeply believe that it provides returns, both to the day-to-day happiness of Staff+ engineers and the quality and strength of the organizational network between them.