What are Coinbase’s Engineering Principles?

Over the last 3 years, the Coinbase engineering team has nearly tripled in size: from tens of engineers in the early 2016 to hundreds of engineers. At the same time, we’ve also increased the product surface area we are working across: from 1 product (Coinbase) to 6 distinct Coinbase products that are collectively building the cryptoeconomy.

As our team size and product scope has grown, we’ve observed a few challenges:

1. As we’ve added more people, it’s becoming increasingly challenging to maintain consistency in culture across the entire engineering organization.

2. As we’ve increased the number of products, we’ve seen a divergence in how different teams approach building their products (and choosing what to build vs. buy).

3. As we’ve begun embarking on multi-year, multi-team engineering initiatives, we’ve seen variable outcomes across teams based on different sub-cultures.

Each of these challenges can be framed as “increased scale creates increased variability.” And, while we’ve seen that some diversity in approach is valuable, we’ve also seen that large inconsistencies undermine our ability to capture economies of scale. For example, if we’re building all of our products in different ways, we aren’t able to share tools/processes as effectively. Or, if we’re building all of our teams in different ways, we will have a harder time collaborating or changing what we’re working on. Or if we have different perspectives on what’s important, when we embark on a multi-year product across many teams, we’ll see different teams go in very different directions (or not prioritize the same initiatives).

There’s no perfect solution for these challenges — but Coinbase is an organization that prioritizes efficient execution, so we decided to step back and figure out how we could maximize the consistency in approach across our organization.

After talking through how best to solve this challenge, we decided on a two pronged approach. First, we would work as an organization to define a set of Engineering Principles that guide how we should work together. These principles would extend our company values and culture, applying them specifically to our engineering practice. Then, our senior leadership would work together to articulate a long-term strategy that outlines at a very high level what Coinbase’s engineering platform should look like in 2–4 years. With these two pieces, we’d have clear direction for where we want to be, but we’d be able to get there by empowering aligned decentralized decisions (rather than gating on top down decision making).

Based on these conversations, our formalized goals for creating Engineering Principles became:

1. Foster a cohesive engineering approach across our heterogeneous set of products

2. Enable productive, decentralized technical decisions

3. Help new members of our team understand how we work and where we’re going

Over the last 3 months, we ran a process to create these principles and have ended up with six principles: #SecurityFirst, #BuildValue, #OneCoinbase, #ExplicitTradeoffs, #APIDriven, and #1–2-Automate. Our hope is that these principles serve as the thread that weaves all of our teams together and helps us chart a cohesive, aligned engineering approach in the years to come!

#SecurityFirst. We believe security is everyone’s responsibility and we keep it top of mind in everything we build. At each step in the development lifecycle, we work with our security partners to keep customer funds safe — and act with the same care we would give our own money.

#BuildValue. We focus our energy on building the things that provide differentiated value to Coinbase — and use off the shelf or open source for everything else. When we do build, we prioritize internal reusability and aim to do something well, once. Building smarter lets us move faster and gives us the space to make the new things we do create excellent.

#OneCoinbase. We succeed when we work together. We leverage the power of our entire organization by looking for opportunities to let our work accelerate other efforts. We believe that the continual growth of the whole is more important than the success of any one person, taking the time to teach and level up the people around us.

#ExplicitTradeoffs. We think from a customer perspective, and articulate the costs and benefits, when making engineering tradeoffs. For a critical production need, we build with scale, reliability, and extensibility in mind, even if it takes longer. To validate an idea, we get something out the door quickly, then iterate (and are comfortable throwing our work away if necessary).

#APIDriven. We embody clear cross-team communication with APIs. We expose data and functionality through service interfaces and expect teams to communicate with each other through them. We believe clear API contracts keep our teams agile, let them deploy with confidence, and allow our product surface area to grow, while keeping “knowledge required to contribute” to a minimum.

#1–2-Automate. We automate any process we are about to do for a third time. We trade a one-time fixed cost for a series of future payoffs, making our teams more efficient, empowered, and effective.

With these principles created, we’re now focused on integrating them into how we work: while writing things down is valuable, it’s only half of the challenge. It’s critical that we empower our teams to actually use these principles in discussions and decisions, otherwise, our work will be for nothing.

In the next post in this series, we’ll be looking at the process of how we actually created the principles, sharing some actionable advice on how you can create principles for your organization. Then, 6 months from now, we’ll be sharing a retrospective on whether this process was valuable, what we learned, and what we’ll be changing going forward. Stay tuned!

If you’re interested in working on a team that aspires to these principles, please join us!