Stripe's Will Larson on Designing a Performance Management System from Scratch

"In Engineering, we tend to hold this idea that these people systems —career ladders, performance reviews, calibration — are these evil things that aren't very valuable. They're thought of as bureaucracy. But it's a shame. These are really powerful systems, and I'm actually excited to personally spend a lot of time with them."

Will Larson, who was previously an engineering leader at Digg and then Uber, now leads Foundation Engineering at Stripe. His organization partners with Infrastructure, Data, and Developer Productivity teams to build the tools that support every Stripe engineer and keep Stripe reliable and performant.

You can go about building a performance management system in uncountable ways, but Larson points out that most of them are comprised of three core elements: career ladders, performance designations, and performance cycles. These combined systems focus your team's efforts on the activities and metrics that ultimately help the organization succeed, by providing direct feedback to engineers on how valuable their work is (and by measuring it against expectations).

We spoke with Larson about how (and why) to shape these foundational elements of a performance management system in a way that actually serves your team and your organization.

"The purpose of these combined systems is to focus the company's efforts towards activities that help the company succeed. The output of these efforts is to provide explicit feedback to employees on how the company is valuing their work."

The First Element: Career Ladders

Career ladders detail the anticipated evolution of team members' behaviors and responsibilities in their distinct roles. For instance, an engineer might grow from a Junior Engineer to Senior Engineer and Staff Engineer, with progressive responsibilities and complexity at each level.

"At each level, people want to know what the expectations are," Larson says. "What are the behaviors that you want to see? My experiences have led me to believe that at their best, career ladders are powerful tools for shaping culture."

The most effective ladders, he says, are self-contained and concise. They also allow individuals to self-assess their work accurately. And when even a strong sketch of a career ladder is in place before filling a role, the ladder can also aid both potential hires and their new managers in understanding a position's expectations.

"There are plenty of organizations who don't have the fundamentals of career development written yet," Larson says. "I think it's easy for companies to be intimidated by the work involved in creating career ladders, with clearly defined roles and expectations at each level. But in reality, career ladders don't need to be remarkable to be effective. Consider the first version of a career ladder to be an MVP. " Just being able to see the types of work this person will do, and what their priorities are, is certainly helpful.

Each person you hire from then on, is an opportunity to gather feedback and further develop the ladders. "Don't worry about writing something wonderful right off the bat," he suggests. "Just worry about writing something you can iterate on." In fact, he even recommends creating a lightweight ladder before hiring the first person to fill a given role.

"At their best, career ladders are powerful tools for shaping culture."

But whenever you're implementing career ladders, you can start small-most companies, he observes, with about three levels and add on over time, perhaps a level every two years. So you don't have to write a robust ladder today-and you can allow the role's functions to determine the appropriate structure of your ladders. While you want frameworks that are global and shared across the organization, you'll also notice that each role's ladder (particularly the specialized ones with fewer people on them) takes on its own characteristics.

"What I've seen work best is to be tolerant of career ladder proliferation," Larson says. His rule of thumb is that most any ladder with more than ten people should probably be fleshed out more fully, but smaller functions can survive with a rougher outline. "There's an expectation that you'll really start discovering what you want from the smaller functions," he adds.

What matters more than a ladder's complexity is its clarity. You want to avoid fuzziness between levels; each level on the ladder ought to be well-defined so that your engineers understand exactly what duties are expected of them. "Crisp, level boundaries reduce ambiguity when considering whether to promote an individual across levels," he says. Also, he suggests avoiding descriptions that require deep knowledge of precedent to apply correctly. The ladder should be easily understood by someone interacting with your organization for the first time.

"If you're going to invest in doing one component of performance management well," Larson says, "make it the ladders. Everything else builds on this foundation."

Step Two: Performance Designations

Once you have your career ladders written and in place, you can begin using them to set expectations around performance and evaluate how your team is doing against those expectations. The descriptions of each level should aid everyone in self-reflection and in your career coaching 1:1s, but Larson recommends also integrating formal feedback into your performance management system using performance designations.

In short, performance designations evaluate engineers' performance in the context of their level on the career ladder.

Because these designations are explicit statements about an individual's work, they help mitigate miscommunication between you, the organization, and the engineers. And when the direction engineers receive doesn't jive with their ladder level, the performance designation provides an opportunity for debugging.

"More important than the scale used for rating, is how the ratings are calculated," Larson says. In other words, don't get hung up on whether you're giving your engineers a perfect 10 or an acceptable 7. Instead, bring in input from several avenues.

Larson observes that the typical setup for performance designations consists of:

• Self-review, where the engineers compare and contrast their work against their ladder and level,
• Peer reviews, which recognize leadership contributions that might get missed, as well, as identifying problems you're missing out on,
• Upward review, to include the perspectives of any people they directly manage, and
• Manager review, which will also synthesize the other three types.

Presenting performance designations will also aid you, as a leader, in setting clear goals and providing direction because you'll be interacting regularly with what is happening (and what needs to happen differently).

"Define the problem you are solving and retrain yourself to evaluate what your team is giving to folks."

"I think something that tends to work is having a team mission grounded in the company's goals but also in what your internal or external users want from your team," Larson says. "As opposed to defining 'Here's what I want to be doing,' describe "Here's what our users want from us.' Define the problem you are solving and retrain yourself to evaluate what your team is giving to folks."

Consistent performance designations ensure that the team is staying on track both for their careers and for the organization's goals, and they also help you define some of the trickier yet essential parts of managing: who needs to stay, and who is ready for a promotion.

"I think people care about promotions for basically two different reasons," Larson says. "The first is that companies typically tie compensations to levels. The other reason we care is status and recognition. Titles are one of the most useful ways for people to understand where they fit in an organization, and where they can grow — and for a lot of folks, promotions are a way of showing recognition and appreciation of someone's work."

With a rubric in place that establishes clarity around what "success" or "good work" looks like in a given role, it's much easier to realize when an engineer is punching above their weight class. You might then recognize their progress by praising their work publicly, by encouraging the engineer to take on even more challenging problems — or by giving them a promotion. Whatever the situation calls for, having this rubric in place will serve as a mechanism for offering grounded feedback and making evidence-based decisions.

"Understanding your people is really important," Larson says. "They all have different preferences for receiving recognition. For some folks, swag is a wonderful form of recognition. Others don't get any kind of reward from that, but will find it highly motivating to receive a thoughtful response, or even something as simple as saying 'I really liked how you did this specific thing'."

But recognition shouldn't just come from you. Receiving praise from peers can be extremely motivating because those are the people who often understand the work best. And direct, specific feedback from senior leaders is so scarce that it tends to be far more meaningful than they realize, Larson says.

Whatever the form of recognition, it has a common purpose and effect: "People can understand very directly how their work contributes to the company," Larson says.

Putting It Into Practice With Performance Cycles

Performance designations have the most value to you and your organization when you can develop a regular cadence with them. You need a process to ensure that performance designations happen consistently and fairly. The frequency of your designations is your performance cycle.

The timeframe doesn't matter as much as its regularity, so you can decide what works best for you and your team. "Most companies do either annual or semi-annual performance cycles, although it's not unheard of to do them quarterly," Larson says.

He acknowledges that the overhead of running a performance cycle tends to be fairly heavy — after all, on top of your team's regular work, you're now asking them to conduct thought-out reviews. And on top of managing your team's output, you're now conducting substantial reviews yourself.

However, the flip side to that is that feedback from each performance cycle tends to be immensely beneficial, and its results factor into things that your team cares about-from performance to compensation. So there's benefit to conducting them frequently, too.

Critically, there's no right or wrong way to conduct these cycles. And performance cycles will evolve depending on what your organization needs-you may be able to conduct them quarterly with a team of ten, and shift to semi-annually as you scale to a hundred. More important than the timeframe is their consistency. Make sure your engineers can count on receiving regular reviews, as well as knowing when they will have their input heard.

Iterating on The Process

As you write and implement your performance management system, keep at the fore of your mind that none of your process is written in stone. These are living systems, and they can (and should) evolve with your company. Each interaction between the performance management system and an engineer is an opportunity to test and refine that relationship.

"What's really interesting are the rough edges and unexpected emergent behaviors that come into play when you start to design and run these performance systems with lots of real people involved," Larson says.

He recommends that you get to the place where you have real numbers written down from your trials with the system, and then test it. In this way, it's no different than any other product your team develops. "Often we run these people systems, and there's no test, no metrics," he says. "Just slow down a bit and take the same level of rigor to these systems and process — ultimately, they are a large part of someone's experience of working with you. Take the way you approach product or design problems — the thought process and skillsets that have already made you successful in your role — and apply them to these systems, as well."

Also, don't just think of these systems as a result of the work your team does. You can flip them around to use them as part of your recruiting process, too. Once you understand how you want to evaluate and recognize people internally, that same knowledge gives you a great framework for understanding who you want to hire.

"Take the way you approach product or design problems — the thought process and skillsets that have already made you successful in your role — and apply them to these systems, as well."

Ultimately, a performance management system isn't the bureaucratic nightmare it's sometimes thought to be when you allow the system to serve you instead of hindering you. After all, these different elements combine to focus your team's efforts toward activities that further the organization's purpose. They provide your engineers with the knowledge of how the company values their work.

And, Larson stresses, the structures discussed here are simply the most common foundational pieces of a performance management system. Your own implementation of these (and other) systems will reflect the particular view of the ideal relationship between your company and your engineers. We all have to start somewhere, though, and these are his recommendations for where to begin.