Operating efficiently at scale

By Brian Armstrong, CEO and Co-founder

As companies scale, they usually slow down and become less efficient. It takes more dollars, more people and more time to get anything done. Coordination headwinds increase, vetocracies emerge, risk tolerance fades, and teams become inwardly focused instead of staying focused on their customers.

While this trajectory is natural, it is not inevitable. Every great company, from Amazon to Meta to Tesla, found ways to retain their founding energy in conjunction with appropriate controls, even as they scaled to be much larger than Coinbase is today. Great companies maintain their insurgent mindset, for fear of becoming complacent and irrelevant over time.

That’s why we’re focusing on driving more efficiency at Coinbase. After 18 months of ~200% y/y employee growth, many of our internal tools and organizing principles have started to strain or break. So we’ve been digging in to identify the set of changes we need to make to help us succeed at this new scale.

The first step was significantly slowing our growth, and making the difficult decision to reduce the size of our current team, which we announced last month. Moving forward, we’ll keep looking for ways to make Coinbase more efficient, and to get back to the mindset and approach that made us successful. I believe that these steps will carry us forward.

We use DRIs (directly responsible individuals) to help us execute faster. DRIs balance input from the team, and make clear decisions in a timely manner.

But now that we’re a larger company with many products instead of one, we need to adjust how we make decisions — pushing most decision making down in the org, removing bottlenecks and empowering our product leaders.

DRIs often have the temptation to push decision making up the chain when they aren’t sure or don’t want to take risks. Sometimes they’re afraid of being fired if the decision doesn’t go well. That’s why, where possible, we are increasingly focused on identifying “single-threaded” DRIs. Single-threaded is tech jargon that simply means solely focused on a single area. The single threaded DRI is the most senior person whose only job is to run a given product or initiative, this will typically be a product management or engineering leader. They can’t be the single-threaded DRI if they are the DRI of multiple areas.

This may mean that not every decision is perfect. But that’s OK if we can scale our impact and empower subject matter experts who are closer to the products and closer to our customers.

Each of our products have well funded competitors that are dedicated companies. We believe the right way to compete is to incentivize our product leaders to also run their product more like a standalone company. Companies must achieve profitable growth on some reasonable time horizon. Over time, we’ll be able to give product leaders direct visibility into their P&L, so they can move their product toward positive margins and make better decisions around where to invest, while at the executive level we will continue to look at consolidated performance.

While product leaders can operate independently, there are often common elements across products. We have shared services around how customers onboard, manage their accounts, store crypto, add payment methods, trade crypto, and more. Done wrong, shared services can slow down and frustrate product teams. But when they work well, they can create amazing synergies between products, and deeper product integration.

Product teams should not be required to use a half baked shared service. But once a shared service is mature, all products may be required to use it. We’ve found that it often helps to start a shared service with one anchor product in mind. When it becomes clear that we are duplicating effort or creating an inconsistent user experience across our products, services need to graduate into clearly decoupled services that any product can leverage.

Small teams are more efficient. That’s why it’s important to set a maximum size on teams, so they don’t grow too large and slow down.

We’re beginning to deploy a new concept that we call “pods” to create more structure around the appropriate size of a team. Within each product, we will be defining pods of