Plaid and Rippling on Scaling Engineering

A. Speaker Overview

Jean-Denis

Jean-Denis joined Plaid when it had 20 engineers and grew the team to about 550 in EPD
He joined as Head of Engineering. Initial responsibility was recruiting and EPD effectiveness.
Over time, he accumulated responsibility. Eventually, he owned the P&L for specific functions
One year where they grew the engineering team 150%, but most years it was 50%-75% y/y

Albert

Joined Rippling at 500 engineers after they had experienced rapid growth over 12-18 months
The foundation was in place - he had to spend his first year building out the leadership layer
Today, there are 900 engineers. He owns engineering/security and partners with a CPO
Prior to Rippling, Albert joined Segment at 20-30 engineers and eventually led 250+ engineers

B. Engineering will naturally slow down as you scale

As you scale, there is an entropy-like force you will push against. When you are small, everyone is in a room and everyone has knowledge of your technical architecture. When you have 100 engineers, new people only know what they work on and you get hit with massive communication costs. In reality, there is no silver bullet for speed – you need to do hundreds of things well to move fast

Jean-Denis on why shipping velocity decreases as you scale

"Entropy means that disorder will increase as you grow, and everything in your organization is conspiring to slow you down. You just need to agree with that and deeply, deeply understand it. There's no quick fix. You can read an OKR book and get excited, thinking, 'Yeah, let's do it, let's launch OKRs,' and believe it will solve everything. Or you could talk to someone who says, 'Oh, we do product reviews this way,' and you think, 'Cool, let's implement that, and everything will move fast.' The reality is, it's more like 1,000 things you have to do in order to keep moving fast. There's no quick fix."

Speed is relative to your competitors and your goals. If you are a fintech (like Plaid) and compare yourself to a consumer company, you will always feel slow. Plaid’s goals center around speed with the constraint of 100p reliability. Consumer companies don’t have these same constraints. Jean-Denis always evaluated their speed against direct peers (Yodlee, Finicity) and Plaid was significantly faster than them

C. How to ship fast as you scale

We outline tactics/ideas from Jean-Denis and Albert below:

Creating a culture that rewards speed

If you want to be fast, it needs to be part of your culture. People need to see that is rewarded
First, you need to clearly define what moving fast means and the constraints of moving fast
Facebook’s “move fast and break things” is a cliche, but it worked. This became a mantra at Meta where internal employees challenged each other when they felt projects were moving too slowly

Tactics to embed speed in the culture

Talk about speed during 1-1s and all-hands. Plaid focused on “ambition, urgency, and scrappiness”
Promote people who demonstrate speed consistently. Show the organization you reward this trait
Top down urgency on product/design/engineering reviews and decision making – don’t become the bottleneck
Allocate more resources and dollars to teams that show speed and ambition
Celebrate shipping (Friday ship meeting/slack channel)
Take actions that show speed matters. For example, Plaid had focus days to enable work to get done. On these days, they’d run a script to remove meetings from calendars. This reiterated that speed mattered to the company

Example: How Rippling defined its culture

To codify culture, reverse engineer it. Culture isn’t aspirational, it is how you act and decide daily.
To do this, Rippling identified a set of early employees (executives and key ICs) that were very successful at the company and embodied what it meant to work at Rippling. A group of core leaders spent a couple days with a facilitator teasing out the common values across each of these people
These values are repeated, screen for during hiring, and modeled by Parker and the executive team

Rippling’s Values

Go and see—Zoom in, look at the details, read the code if needed
- Highly painful, but ensures people are sufficiently focused on the details
- Above all else - this is the key leadership principle that matters at Rippling
Pushing the limits of possible—Work hard, normalize setting aggressive goals
- Every goal at Rippling has an MMDD, which is a strongly typed deadline
- Deadlines have a month, a day, and often an hour attached to it
- This normalizes setting very aggressive goals and makes it a cultural principle
Western Union—Customer obsession principle
Building Winning teams—Everyone is responsible for building teams that win
Challenge each other directly—Directly engage, no topic is off limits for the team
- Parker models this behavior. If there is an issue, he raises it in public channels
- The DRI will get called out. This encourages teams to challenge each other
Decide quickly—Decisions can and should be made quickly
- Decisions at Rippling are often decided in a Slack thread in under 2 minutes
Right, often—Decide quickly, but the expectation is that you will be right more often than not
Change their minds—Be willing to change your decision if presented with a better option
Frugal—Everyone is a owner of the business

Come up with meta processes to identify what is slowing you down and to drive urgency

Design meta processes to identify what is slowing you down in the organization and how to fix it
For slow areas - go deep and / or empower people to fix it quickly and get out of the way

Example: Plaid’s Key Project Check-in Meeting

What

Jean-Denis would pick 3-5 projects to deep-dive into each week in a “Key Project Meeting”
He would pick projects that were important for the business or were clearly going to run into issues
The meeting would focus on unblocking to achieve goals, not debating strategy or approach

Who

PM, EM, designer for the project. Not management/leaders because its just about execution

How

Before the meeting, the team would fill out a simple Google Sheet with 3 columns

1) Status versus goal
2) What was recently shipped
3) What are the blockers? [this is what would be discussed]

Impact

They would notice trends (e.g., a few of the projects rely on a particular team or system)
This might cause them to merge teams, do org work, or invest in the stack
The meeting would help Jean-Denis understand structural issues and optimize for speed
More often than not, the problem would solve itself. The pressure of the “eye of Sauron” was enough
If it wasn’t getting resourced, he would often go to the manager and offer other resources to help

Example: Launching to Rippling

Rippling aggressively dog foods their products – they introduced a concept “Launch to Rippling”
This enables the team to create urgency and launch milestones within the company and teams
They treat launching to Rippling as a real customer launch - when it launches, it has to be very good

Technical architecture matters

Bad architectural decisions compound. This requires good taste and is hard to screen for
Early on, you make these decisions. As you grow, you’ll need to figure out how to scale good taste
Scale decision making by promoting and/or uplifting people that have shown they are good at this

Jean-Denis on technical architecture

"There are many factors that contribute to speed that are difficult or impossible to measure. For example, having the right technical architecture is critical to moving quickly, but it's a matter of taste. No metric will tell you to spend 18 months building new infrastructure—that decision relies on judgment, which is the skill of great engineering leadership, whether on the individual contributor or management side."

Start Small. Resource teams over time.

There is no single structure for speed - but small working units can lift and move mountains initially

Example: How Rippling resource’s teams

Team Structure

Rippling organizes teams into small "pizza team" pods

Teams start with 3-5 people and grow as product-market fit (PMF) is reached and products are scaling
Initial team for 3-6 months is an engineering lead and a small group of 3-5 people
Ex. Rippling’s spend management product was built with 10 people initially. Today, the team has 20-25

Quarterly Reviews

Each quarter, Albert, Parker, and the Head of Product closely scrutinize small team plans

They hold quarterly reviews where teams present a short deck summarizing:
- What happened (progress and results)
- What’s next (upcoming objectives)

Resourcing Decisions

Leadership resources teams based on a careful review of these quarterly team plans‍
The golden rule is to never put resources, money, or people behind a team that isn’t delivering‍
If anything, remove resources and “go and see” to figure out how to fix the teams issues
After the team starts to improve, begin adding additional resources behind their efforts
- Rippling’s IT product organization was growing quickly when Albert joined
- Even though it was receiving more resources, the team wasn’t hitting its targets
- Concluded that the team did not have the right manager / leader to scale it
- As a result, they paused hiring and have kept the team roughly the same size for 2 years
- The team is now shipping better and there are repeatable releases happening
By removing resourcing, you force teams to deal with the fundamental problem vs. adding bodies

Best Practices for sizing teams

Keeping Teams Small initially: In the early stages (before PMF), teams should remain small (3-5 people). Scaling too early, especially before PMF, has been shown to lead to failure due to added pressure. If more resources are going into something that isn’t working, it's more likely to get cut

When small teams don’t make sense

In Jean-Denis’ 7 years at Plaid, 3 to 5 people was always the right sizing in the beginning for feature related products. This let you take low risk swings at big product areas and invest as you find PMF
If there is no product-market fit risk and just technical implementation risk, you can staff teams a little larger initially so long as you make the right architecture bets. The goal is to design the team such that you can figure out whether its working in 3-6 months

Staff teams with the right personas

You need to staff teams with the right personas for that product or role
- Situations that require 0-1, need people that thrive in uncertainty and move quickly
- Situations that require 1-100, need people that can execute and drive targets
Jean Denis’ biggest mistake at Plaid was not hiring enough 0 to 1 people
You need these people for new product launches or in situations where there is more uncertainty. These people aren't afraid to make difficult decisions
If you feel a new product is missing 0-1 personas, step in and make the hard decisions for the team. Otherwise, they will be paralyzed and never make the decisions required to win
As you scale, this becomes harder because you will attract “mercenaries” who join for money

Tactics for identifying 0-1 people at scale

Create avenues to find, attract, and identify these people outside of your regular channels
- Acqui-hire small teams with talented engineers. Keep on a look out for opportunities
- Look out for founders that recently failed and hire them onto your team
- Ask your best 0-1 people why they joined and create a repeatable pipeline from that
Look internally. Reward people who are good at 0-1 a ton
- People who are good at shipping…are good at shipping
- Forget your guidelines, promote these people as frequently as needed
- Rippling regularly puts these people in 0-1 roles – some people are on product #3 or #4
Create mentorship opportunities at your company
- At Plaid, they would put people that had 0-1 potential on the same teams as great 0 to 1 people
- These high potential people get mentorship and become the next generation of 0 to1 people
- This acts like a “center of excellence” that naturally helps you train great 0 to 1 employees
- You have to force this and move people. Managers won’t want to give up high potential people
Screen for 0 to 1 capabilities in the interview
- Rippling does a “past project deep dive” where candidates walk through one project in depth
- You want to understand their exact role, how decisions were made, and structure of the team
- You are looking for signs of 0 to 1 where they made controversial decisions and drove progress‍
- “And then I pulled out my knife and stabbed the CEO”‍
Great 0 to 1 people also have knowledge of the stack
- You want to create systems that encourage the best people to learn about the stack. As you grow, new products require teams to touch multiple parts of the stack. Plaid forced really good people to touch multiple parts of the organization by moving them across teams. This sets them up to thrive in 0 to 1 situations

Founder PM as long as you can

Founder-PM as long as you can, the fewer decision-makers the better. Once you introduce more decision-makers, you need to spend more time making it better and more efficient.
Eventually, scale this by empowering people who have shown they are good at this. Jean-Denis estimates the ideal time to start doing this is ~100 people in EPD

Remember that speed isn’t the goal everywhere. Balance speed with craft and reliability

If you push hard on speed everywhere, you are going to find yourself in pain 2-3 years later
Create pockets of speed balanced against teams that have constraints (e.g., reliability, security)
At 500 engineers at Plaid, they had multiple distinct cultures at the company:
- Security and Privacy teams - Different cadence. Not 2 week sprints. Concerned with reliability
- Teams that work with speed - 2 week sprints. Focused on launching features/products.

Great engineering managers (EM) go and see and care deeply about the business

A great EM is much more than being a vanilla good manager or a babysitter of engineers
Great EMs bring something more than management to the table - they often have a superpower
Figure out what that is for your business and try to identify it in potential EMs

Traits of a great EM

Great EMs “go and see” and are in the details
- Tendency as you become a manager is to become more removed from the work
- The best managers remain deeply involved and understand the details of the work
- Usually, these people were great ICs or tech leads and scaled into management
- Note, you’ll need to support these personas because management is different from IC work
Great EMs care about the business
- They understand the levers and what drives success in their product area
- They are close to the details and can move levers in the right direction
- They use this understanding to motivate others - EMs without business sense are dangerous
Great EMs make good technical architecture decisions
- Success and failure can be driven by decisions
- Some of the best EMs at Plaid were exceptional at making infrastructure/design decisions
- This is really hard to find - if you have it, hold on to it and nurture it
As they become more senior, great EMs recruit and retain talent
- People gravitate to them and want to work on their teams
- They have a good talent bar and can identify and pick great talent
Don’t be afraid to remove people from manager positions
- Being a manager is different from an IC – some people are not made for management roles
- At Rippling, Albert pulls EMs out of management and into IC roles again if they aren’t doing well
- This often works out as these EMs are happier as ICs and can succeed in IC paths

D. Metrics

Engineering Productivity Metrics

No standard set of metrics you can collect on engineering. Jean-Denis focuses on process metrics vs. output metrics. In other words, where in the process are engineers waiting or losing time versus writing code or making progress. In his view, this is where time gets eaten up.
He also runs qualitative surveys to try to understand where engineers perceive they are being slowed down. He recommends starting to use these more rigorously when you have ~100 engineers.

Metrics he cares about are below.

Example: Process Metrics

Build, test, deploy times
Look at your long-term graphs and try to get this under 5 minutes.

Code review SLA
Monitor whether teams are meeting code review SLAs. If code reviews are taking too long, this can impact velocity.

PRD Spec to PRD Sign-Off Time
This signals whether you have projects that are off-rails or if you are shifting to a consensus driven culture

Subjective Engineering Survey Responses
Ask your engineers what works well, what is slow via a survey. This will help you identify issues that need to be addressed. If you don’t want to run a survey, start by asking your top 5 engineers what sucks - they will tell you and it's an easy way to identify what is broken

Interview/meeting times
They did regular meeting purges. During times of hyper growth, interview times become a disaster. They solved this by creating interview days for individual teams, so that less time was taken up by interviews and recruiting candidates.

One of the biggest predictors of success at Rippling is the amount of code shipped in the first 90 days. People who ship a lot in the first 90 days are successful versus people who don’t ship anything. Measure and track what people get done when they join your company. Abi recommends time to 10th PR as part of DX's framework for measuring velocity
Oftentimes, the 80/20 of slowness is not your build/deploy time or people’s effort. It is usually either bad architecture decisions slowing people down, too much communication overhead, or lack of fast decision making. Optimize metrics, but don’t immediately resort to metrics. Go and see for yourself first.

Example: Albert “going and seeing” to fix a problem

A team was not performing and were not hitting their shipping targets or business goals
Instead of optimizing process, Albert/Parker agreed that Albert would run the team in the short term
Through this process, Albert and the team identified the 3 or 4 key workflows they needed to get right
They started measuring these metrics week/week and diving into reasons for missing goals
They realized after some deep research that they were skipping a page in their flow asking for info to correctly enroll customers into benefits
The only reason they found this out is because they were looking at the metric every week.
At 900 people, this is the extent to which you need to get involved when a team isn’t performing.

Best Practices for Metrics

Core principles from Abi at DX:
- Focus on a basket of metrics across speed, effectiveness, quality, impact. No single metric is good enough
- Measure metrics at the organization level - this stops developers from feeling “watched”
  - You can dig into the team or individual level, but reporting is at an organization level
- Metrics need to be consistent and operationally meaningful across stakeholders in the company
Metrics also include survey data. Perception is just as important as actual output data
- “Perceived rate of delivery” – do developers believe they are shipping fast?

E. Hiring a VP of Engineering

Note: This portion of the summary was pulled from Jean-Denis’ written document and VP of Engineering video

Why hire a VP of Engineering?

When post product market fit, having people who can look around corners is valuable
Engineering or sales/GTM are the largest functions and typically break because they scale first
In general, the responsibility of a VP are now the highest leverage responsibilities for founders:
- VPs help with EPD execution, accountability, goal setting, recruiting, culture
Hiring a great VP of Engineering lets founders do only what they can do. This includes hiring execs with singular talent, understanding customers, running product and product strategy, business strategy, GTM, the next 0-1 big thing for the business. This also includes thinking through the details of the technical architecture.
VPs are important but are not true multipliers for the business. They give founders back time for 0.5-1.4% equity

When to hire a VP of Engineering?

15-30 engineers. The search will take 6-18 months, so start conversations when you have 10-15 engineers.

What does a VP of Engineering do? How to figure out what you want?

This largely depends on the company and the founder. As the founder, you need to figure out what you want to own and what you want to give up. As an example, Marcelo at Faire kept recruiting because he cared deeply about hiring and he wanted to own technical architecture decisions. He hired a VP of Engineering to manage people management and the engineering process.
To figure out what you want, talk to VPs of Engineering who run 150 person teams. This will help you understand what you want/what to look for when hiring a candidate.
A fail case is hiring a VP of Engineering that clashes with the founding team or that wants to own pieces of the system that the founders are not willing to give up. This upfront exploration process helps you avoid that.

The anti external profile(s)

There are three anti-profiles: (1) mercenaries, (2) journeyman, (3) false prophet

Mercenaries

There is a professional class of VPs of Engineering that move from company to company

Journeymen

The person who has various jobs as an IC at tech companies but never reaches leadership position
Looks good, but they’ve never had the experience of building 0 to 1 - can’t afford learning on the job

False Prophet

Became a VP of Eng at a small startup with 20-30 engineers. Startup scales, but fails before real scale
This candidate is appealing because they’ve managed at your scale, but they’ve never seen scale
If you hire this person because they are smart, you need to provide coaching to help them scale

The ideal external profile

Profile 1

Joined as IC at 10 engineers
Became manager via internal promotion at 30 engineers
Worked closely with VP of Eng from 30 to 150 engineers
Went from managing 5 people to 50 people at the company
Before being at a startup was at a larger organization with a well-run engineering team
Companies like Plaid have a lot of people with these trajectories

Profile 2

Saw company go from 50 to 450 engineers as a manger
Before that worked at a early stage startup as an IC and at a big organization as a manager

Jean-Denis on why his profile worked at Plaid

“One of the things that made me successful at Plaid was that I joined Dropbox at 100 engineers. I was number 101. I saw Dropbox go from that to 600. I wasn’t in charge but I saw all the pain points that happened through that journey. When I could get the VP of Eng at Plaid, it was a huge step up for me, I was so excited to imprint my vision of engineering excellence somewhere. But, I had seen what could go wrong. I had a network of people of great ICs that I could recruit into a place, that were the kind of talent you would want to bring into a new company ”

Internal versus External

Internal candidates can work. They understand your culture and have respect within the organization
You need to support them with the right coaching, especially if they haven’t led large teams before

How to find a great VP of Engineering?

It is difficult. There are a lot of these executives for hire that fall into the “mercenary bucket”
The best VP’s of Engineering are only on the market for 1 or 2 stints - meaning they only do it once
The best profile is to find someone 3x-5x your size who wants to step up into the VP role to prove themselves

Jean-Denis on finding a great VP

“There are some people that jump from company to company as senior director/VP who are good at their job but are not good for a 15-30 person engineering company. Those folks, the best ones, are only on the market for 1-2 stints as VP of engineering. I would count myself there, I was a director of Dropbox, and VP of Eng at Plaid, I don't want to do it again. The really great people will not be VPs again, and again, again. The best profile is to find someone at 3-5x your size that saw the growth you are going through even if they weren't VP but because they have seen all the ways things can break and be fixed.”

Ask your network for referrals. Do the work. You can also work with search firms to supplement your network
Search firms only have 30 profiles available at any given time. Don’t fully rely on search firms because of this.
This also helps you build the muscle to know what is great and will help you evaluate candidates better

Jean-Denis on how to find your VP of Engineering Candidates

“There is no secret. You have to network. Go through every director at a firm and find people who worked at a couple up and coming companies and have the right amount of management scope and before that worked at well run bigger shops. You will find folks. You can definitely work with agencies. Rivera is very good, but the thing to keep in mind is that they have 30 people in their pocket who they know are looking. Initially, there is a big hit of talent and after that you don't get that much of a hit of talent. If that initial group doesn’t have the right person, they have to find more candidates and it takes more time. ”

Evaluating whether you have a great candidate

Calibration

Calibrate by talking to non-candidate VPs to get a sense of what great looks like. Ask them questions you plan to ask candidates and observe how they answer the prompt. Additionally, talk to a lot of candidates, both good and bad. This also helps you build a picture of what “great” looks like.

Characteristics

Flexible and willing to adapt. They need to be willing to adapt their approach to managing and engineering. If they are not a flexible thinker, and are going to use an existing playbook, it's not going to work. It is rare that you can apply what worked exactly from one company to the next as cultures and approach are too different
Self awareness. This is very important because subordinates do not give good feedback. They own up to their mistakes and can reflect on their failures and faults.
You see how they can contribute beyond engineering. They need to be additive to the company. In the process, you find yourself wanting to hear their voice on business problems. This is a sign that they will be a contributor beyond engineering processes.
You’re excited about them. Meeting the “bar” is not enough. You need to be excited about the prospect of working with them and collaborating on building out the engineering function. They also need to match your culture. If you are analytical, you should probably hire a more analytical VP of Engineering.
They have frameworks AND real life experience. They should have frameworks for how they want to set up processes and also real-world experiences. The reality is real-world constraints often impact what you can implement, so you want someone who can adapt their frameworks to the real-world environment.

Jean-Denis on the importance of frameworks and real-world experience

“A good candidate will have frameworks..they might say I [to design an interview system] I would understand our cultural values and our roadmap. I would map out a set of interviews that aligns with both of those things. And this is the process that I would use to create a perfect interview…’ (tell me in practice how that works) ‘This is how I used parts of this framework [because of constraints] to create the interview… They have to be able to apply the framework in a resource constrained environment”

Onboarding a VP of Engineering

VPs of Engineering work only 60%-70% of the time. When it doesn’t work it's typically because the wrong person was hired or because the person was not onboarded properly. There are five goals for onboarding:

1) Build trust with the team
2) Build trust with the founder
3) Quickly identify if it won’t work out
4) Maximize chance of success
5) Make sure the person doesn’t screw up the company

Tactics to drive successful onboarding

Tactic 1: Create opportunities for easy wins

Easy wins help new executives gain confidence and build trust in the organization
The more trust and understanding they have, the more likely they are to be able to solve hard problems
Asking a new executive to solve a really hard problem in their first week is a mistake

Jean-Denis on creating easy wins for his Head of Design

“I hired a Head of Design at Plaid a lover over a year ago. The first thing I asked him to do was to reformat our design review. We had a design review it was okay, but I wanted him to look at it and make some tweak. The changes were easy, the attendance felt random, there was no cross-team design review, we didn’t celebrate the outcomes of design reviews. It didn’t tell him how to fix it but these four things seemed off… I knew he would win, its listening to seven people and taking the intersection of what they say and that would be much better than we we have today”

Tactic 2: Stay close, but do not intervene

Stay close, but intervening can undermine their ability to build trust. It will also make them doubt autonomy
This doesn’t mean that you let them operate independently, but publicly give them the space to operate

Tactic 3: Fire quickly. Set up accountability check-ins to know if you need to make a decision.

Holding yourself accountable to make hard decisions. Most bad VPs are fired within 12-18 months
This is often too late. Ideally, you let go of a VP within 4-6 months
To facilitate accountability Jean-Denis puts an invite on the calendar with his CEO to review performance of new leaders. This helps them objectively measure whether they are doing a good job or if they need to be fired

Tactic 4: Once they are doing well, signal publicly that they are the leader. This helps create trust.

Once confident the VP is good, leadership needs to signal to the team they are doing well
The more signaling, the more that person can take on as the organization will publicly acknowledge them

Example: Plaid’s Onboarding for executives

Jean uses a 30/60/90 plan and evaluates performance at 6-9 months and 12 months

30/60/90 days

30 days: Meet people on the team
60 days: First quick win
90 days: Give feedback, deliver second quick win

3 months

3 months: Perform their first medium fix

6-9 months

6-9 months: Evaluate their fit
This is another escape hatch

12 months:

Evaluate some of the bigger things they have done

E. The VP of Engineering/CEO Partnership

Albert’s Scorecard and Partnership

Scorecard

Recruiting—Was he able to attract a set of leaders and engineers that have raised the bar?
Speed and Quality—Was he able to ship products that were loved by customers?
Platform—Did he invest appropriately into the platform?
Platform—Has he built an exceptional engineering culture?

Relationship

You want direct communication. Albert is never at a loss for what Parker thinks about the business
- Talk once per week for an hour and a bit of slacking. Also communicate in public forums
- They communicate in the open and this sets the tone for the rest of the company
Parker holds him accountable for driving outcomes. Two weeks in, Parker tested him:
- When Albert first joined, he told Albert to fix site performance on Rippling.com
- Two weeks later - he asked for an update. Albert told him he was evaluating/planning
- Parker was nice but said it’s completely unacceptable. Albert needed to fix it and act
- For the next few weeks, Albert set up a performance war room to improve performance
- This was a way for Parker to push Albert to work in Rippling's style, not just manage / convene plans
They’ve normalized pointing out problems or issues to one another (open relationship)
- Sometimes Parker will identify problems before Albert - this is OK because he has context
- This type of working relationship is really important when working with product CEOs
- Your VP needs to be OK with this happening – otherwise it will fail

Jean-Denis’ Scorecard and Partnership