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 <10 people working on a specific feature or area. If a pod grows to be more than 10 people, it will be time to split it in two and assign each one a more specific goal or focus. Pods also need to have a focus, and a north star metric that ties into the overall company metrics.

Inside growing companies, there’s a danger that product and engineering teams start shipping great slides decks instead of great products. It can be tempting to “manage up” and feel like a meeting went great with a beautiful deck shown to superiors. But our customers never see the slide decks we create. They only see the product.

So we’re experimenting with banning slide decks in product and engineering reviews. Instead of a slide deck, you can show:

• A dashboard with your metrics — hopefully your team is looking at this at least weekly anyway
• Figma mockups
• But most importantly….show the product itself and use it live!

It’s fine to include a one page agenda to capture action items, or to link to any pre-reads like technical design documents. But the best use of time in product and engineering reviews is to share your screen and walk through the actual product on mobile or web. It could be the production version, or a staging version. The important thing is to get hands-on with the product, see what the customer is seeing (or is about to see), and make it better.

As we do this, we should avoid spending too much time talking about what’s going well in meetings. We can share what’s going well in the pre-read, and take a moment to celebrate it, but the majority of the time in meetings should be focused on what is not going well, so we can improve the product.

It’s hard to overstate this point. Inside companies, there are plenty of things that feel like work, but ultimately don’t improve the customer experience — from market cycles and negative press, to policy efforts, internal politics/drama, titles, and compensation. We have teams that focus on these areas, so that the vast majority of the company (80%+) can remain focused on talking to customers and building better products.

Larger companies also get slowed down by endless meetings around prioritization and feature requests. We need to move to a model where all product and engineering teams (not just shared services) publish APIs so that other teams can benefit from what they’re building without ever needing to schedule a meeting. In other words, they need to productize their services and allow other teams to use them in a self-service way.

This requires us to adopt an internal API catalog where any engineer at Coinbase can browse to find an appropriate service. Without this, it’s difficult for any engineer to even know if an API exists, leading to duplicate work. All services need to be architected using “paved roads”, meaning consistent libraries and languages for authentication, logging, instrumentation, etc. Many of these APIs will be surfaced in Coinbase Cloud for external customers as well, making them even more robust.

Ultimately, a lot of this comes down to retaining the founder mentality inside the company and acting like owners. Most companies start off by being anti-establishment, seeking to right some wrong in the world. But as they grow bigger and more successful, they start to become the new establishment. They get complacent, feeling that they’ve won, and bureaucracy sets in.

At Coinbase, one of our values is repeatable innovation, meaning we always want to be pushing the frontier. We use a 70/20/10 resource allocation model where we invest 70% of our resources in our core business, and 20% in strategic efforts, we also ensure 10% of our resources are always going toward ambitious new bets. And we always try to make products that are the most trusted and easiest to use, so we can bring a billion people into crypto. This is the best way to accomplish our mission of increasing economic freedom in the world.

Coinbase’s success has always been rooted in an ability to operate efficiently with a startup mindset. Now, as we adjust to our new scale, we need to get back to the things that made us successful — to drive more efficiency and shake off the complacency that can creep into a bigger company. We need to empower our leaders to make decisions, and our teams to deliver great products to customers. It won’t be easy, and we’ll need to keep adjusting. But we got this far, and I’m confident that if we make smart decisions now, it will only be the beginning.

Companies approach this problem of declining efficiency in different ways, to best fit their situation. We’ve aligned on implementing these changes and tools after doing significant research on how other companies have navigated this. Here are a few great books and resources that helped educate me on this topic:

• Amp It Up: Frank Slootman has a great blog post on this that turned into a book. The core message is that when someone says I’ll get back to you next week, say how about tomorrow. When someone says it will take six months, ask how we would do it in six weeks or six days if we had to.
• Turn The Ship Around: The core message of this book is instead of asking your manager what you should do, tell him or her what you intend to do, and they will edit your thinking if needed. You still need to inform, but it’s your responsibility to decide the best path.
• Founders Mentality: The core message is to maintain an insurgent mindset, with a bias for action, bold mission, customer advocacy, and more. Try the quiz for more details.
• Coordination Headwinds: Scaled organizations need to be loosely coupled and tightly aligned. In other words, align on a high level mission, values, and metrics, then empower leaders to make their own path with more localized decision making.