Small Teams, Hard Problems First: How Rippling's Jeremy Henrickson Keeps Velocity at Scale

Henrickson recalls 2017 as the strongest memory of his time as Coinbase's chief product officer. Crypto climbed out of a low in early 2016 and then entered public consciousness, and Coinbase, then essentially an exchange acting as a fiat on-ramp and off-ramp, saw usage grow 40 times over the year. He calls it both a dream and a nightmare, with Saturday mornings regularly interrupted by something breaking at the edges of the system.

To stay focused, the team did not talk about people getting rich. They talked about customers and their money, and security came first. A security leader at Coinbase, Philip Barton, could put fast decisions in context and say what was safe at speed. Alongside firefighting, the team kept asking what they were shooting for over the next six months and what volumes to expect.

The biggest challenge was uncertainty. Questions like whether Ethereum would matter had no known answer and strong opinions on every side. His approach was to have the debate, then come out with one clear company point of view and go full speed toward it until you decide to go full speed toward a different answer. He adds that such crucible periods accelerated his growth and, looking back, were worth it.

Asked how to maintain velocity at scale, Henrickson says the answer depends on the business, but one universal truth is small teams with clear missions. With 300 people on one thing, communication overhead and Dunbar's number make quick action very hard. Break a large problem into pieces small groups can attack wholeheartedly and minimise horizontal communication.

Second, bake as much as possible into a clear platform with an interface that engineers and product people find easy, which reduces decision complexity for everyone working on the domain. Platforms must be built iteratively, he cautions, by people who combine systems thinking with product thinking. Third is leadership diving deep, because it is tempting to float above and assign hills when the real lessons are in the trenches with the hardest or most complicated problem.

The fourth is getting the right mix of experience and seniority. People who excel at zero-to-one work may not enjoy or be good at scaling a product to millions two or three years later, so leaders should keep recalibrating the team. Do all this with very precise product leadership, he says, and you can actually accelerate over time, because the platform lets engineers do more with less.

Henrickson's example is time and attendance, which Rippling decided to build about three years ago when he was just joining. They found one talented systems engineer with product instincts, had CEO Parker spend time on it, and the engineer brought a few others. Those four people spent roughly nine months building the product, ignoring payroll, benefits and IT except for the integration points.

He says this was mostly about being small and focused rather than Parker unblocking things, and the pattern has since been replicated a dozen times. Leaders can check in on any team quickly without going through layers, he explains, so the management structure never gets in the way of anyone seeing what is really happening.

The model is simple. When the company has a one-page view of what to build, it finds one very entrepreneurial engineer who can decide with low information and work fast with a designer. That person first spends a few months on another team to learn the platform and talk to earlier founders, then recruits two to four like-minded engineers. In six to nine months there is a launched or heavily dogfooded product, and the team may grow from four to about fifteen as it heads to production.

The team meets whoever is the directly responsible individual, Henrickson or Parker, every couple of weeks to critique designs from the viewpoint of an admin at a small company or a large one. Lenny clarifies that the design partner is a designer who knows Rippling's component library, not an external company.

Henrickson does not knock MVPs, which he says suit a zero-to-one company with no market validation. For Rippling, though, a minimum viable product would disservice customers and the team. An MVP optimises for speed, which shrinks the deeper thinking about what can differentiate the product and what it should do in the future.

Worse, he says, it leads engineers to the wrong technical assumptions. If no one pushes with a mission-critical case such as hospital administration, the team stacks dozens or hundreds of architectural assumptions on top of simple cases over six to twelve months, and unwinding them is extremely difficult. You can still decide not to support a hard case at launch, as long as the product does not prevent you from getting there later.

Global payroll is the example. The fastest option would have been to copy the US system for the UK, but instead Rippling launched with six very different countries, each with its own requirements for HRIS, employer of record, contractors and payroll. Now 80 percent of the system is shared, and the 20 percent that is country-specific can often be configured by compliance or legal staff rather than expensive engineers.

He admits this is counter to most people's backgrounds, where you pick one case as a wedge and grow from there. That is why new founders spend months absorbing the culture, and why Rippling is highly hands-on with new products, balancing the need to ship fast with the need to avoid the trap.

Henrickson explains Rippling as a compound startup: many businesses, such as payroll, benefits, device and identity management and time and attendance, each of which supports entire companies on its own, built on one platform. Founder Parker's insight was that data is replicated everywhere and impossible to keep in sync, so the right answer is one system of record that all downstream systems draw from. Workflow, reporting, analytics and permissioning can then be built on top.

He says the activation energy is extremely high, and the founders, including technical founder Prasanna, built the first versions of all these products, which he calls a minor miracle. Having done that, the company can keep adding new verticals on the same foundation.

Lenny suggests this is Rippling's differentiator, and Henrickson agrees: a single source of truth also enables things competitors cannot do. A permissioning system can use attributes across products, and any product can instantly know who someone's manager is, while most products rely on an exported spreadsheet that is out of date immediately. That capability, he says, boils down to one fundamental decision that lets Rippling do things literally impossible for others.

The most distinctive part of Rippling's culture, Henrickson says, is speed of decision-making, which is hard to grasp until you experience it. If a decision is needed mid-meeting, they make it or pull in the right person over Slack and finish that day. Irreversible decisions are the exception, and he says no company he has worked at, from five to 5,000 people, has operated at this tempo.

It starts with Parker, who likes making decisions quickly and has made it a deliberate strategic choice, modelling it constantly in Slack and in person. It also shows up in the leadership principles and in quarterly planning, where decisions have dates. Product leaders own a whole product rather than a feature, and are expected to be its foremost expert, so they can answer off the top of their head or in thirty minutes.

When a decision date passes, Rippling moves on without it, which shocks newcomers. He says it is not hostile: you do not get to retroactively make everyone react to the fact that you were not quick enough. The leadership principles, driven by COO Matt MacInnis, came from asking what made people successful at the company and why some people did not enjoy it.

For leaders who want to move faster, Henrickson advises being extremely clear about the priorities and, even more, about what is not a priority. Then comes a Rippling leadership principle, go and see: walk all the way to the ground and talk to the engineer writing the code, because top-level communication never conveys what matters in detail. You do not need to do it everywhere, he says, but doing it in enough places sets the expectation of clarity for everyone.

His example is the early global payroll effort. Rippling's head of payroll studied the UK and found differences nobody had anticipated, which changed how they approached learning each country and led to the design of a tax filing system flexible enough for every country. In the US, he adds, studying local taxes in places like Ohio or Pennsylvania shows how a city changing its rate without warning must be handled.

Lenny notes the point is not to delegate this to an expert, and Henrickson agrees: the product person learns first and then the company hires the tax specialist, which Rippling now has. Specialists are great at their craft but not necessarily product thinkers. He says that for an 80-hour week, 40 hours go to this learning, since there is no point writing a document if you do not know what you are talking about, which is why Rippling keeps its product organisation thin.

Among the leadership principles, Henrickson names "leaders are right a lot" as a favourite, especially for product leaders whose decisions ripple across the whole organisation. He values people who can walk into an ambiguous, incomplete-information situation, listen to everyone and make a call, even if others disagree, and be proven right a year later. It is hard to test in interviews and, in his view, mostly cannot be learned.

On global expansion, Rippling assumed it would ultimately be everywhere, since you want to pay people and contractors in any country and keep their information in your HRIS. With thousands of customers already, they knew where US companies had other employees, listed demand in raw numbers, weighed difficulty and strategic value, and stack-ranked countries. That list has been revisited but remains mostly right.

He says the right time to go international is before you think you need to, because it is harder and more specialised than expected. Companies that are not global will not be around in ten years, in his thesis, and COVID pushed even very small companies into multiple countries. The most surprising lesson, from an earlier role at Guidewire and again at Rippling, is that every country is unique and finds a US-first approach insulting, such as a demo screen showing a social security number.

Henrickson says he is not anti-framework but anti-process as a substitute for deep product thinking. Companies as they scale can fall into believing that if everything were categorised correctly in Jira, good prioritisation would follow. What matters is deciding what is important to build and building it efficiently, and the right process depends on a team's life cycle.

He does not push scrum or the latest trend, and is comfortable with different teams using different approaches. Only two things must be uniform: the quarterly planning process, and everything being in Jira so work can be rationalised. He distrusts anyone who dogmatically says to use process X, though he supports practices such as test-driven development on the engineering side.

Comparing Coinbase and Rippling, he says the differences come from the domains. At Coinbase the work was about debating an unpredictable future, committing, and reacting quickly to the crypto markets and regulation. At Rippling the team largely knows what must be built, so the challenge is differentiating on platform capabilities, and day-to-day decision velocity is higher. He adds that both were stressful, but in the shape of an interesting problem, and he remembers them fondly.

For product managers, Henrickson looks at two things. In Rippling's case study, which is deliberately too complex to answer fully upfront, he changes an assumption and watches how the candidate reacts. Some candidates rattle off hundreds of implications while others get flummoxed, and for Rippling the former matters greatly.

The second is the insightfulness of the candidate's questions, which signals real interest in the role and depth of research. He recalls interviewing Kyle Boston, now head of platform product, whose question about creating pillars of underlying platform technology came before Rippling had formalised its platform concept. That a person with little context had thought that deeply gave him confidence.

Lenny adds that PM candidates should think about the bigger business, and Henrickson agrees, citing revenue, strategy and detailed implications. The process is short: a hiring manager conversation, a product discussion with Henrickson and a case study. He asks "What questions do you have for me?" before the product discussion and names it his favourite interview question.

For early-career PMs his advice is to be humble. Product people live in a world where nobody yet knows the right answer, because if someone did it would already be built, so you must be open to absorbing and synthesising what others know. He says humility separates early-career leaders who let go of how great they were in school or a first job. Lenny connects this to the principle that great leaders change their minds, and Henrickson stresses that people need an environment where they can say they were wrong and move on.

On working with a strongly opinionated, product-minded founder like Parker, he says you must be adaptable and make sure the person is willing to be challenged. Parker is both opinionated and well informed, which makes for great debates, and Henrickson likes being what he calls a moldable puzzle piece. A deep foundation of mutual respect, built over years, matters more than always agreeing.

His recent small change with big impact is what he calls imperatives: a force-ranked list of things everyone in product and engineering must do, regardless of whether they come from the top or the bottom. Each team still sets its own priorities but must factor these in. The list is about ten items at the moment, reflecting globalisation, platform improvements and other cross-team efforts, and what matters most is what is left off it.