I. Extreme Ownership
If you saw it, you own it.
The single most expensive sentence in software engineering is "I assumed someone else was handling it."
We've lived the cost of it. We've had pull requests go through where someone noticed a potential issue but didn't follow through. They were busy, or they figured another reviewer would catch it. The result wasn't a small miss. It was bugs and functional regressions that lived in production for weeks, sometimes months.
Nobody did anything wrong, exactly. And that's the trap. When ownership is diffuse, everyone is a little bit responsible, which means no one is.
So we make it sharp instead.
Own your intent
Ownership shows up most clearly the moment you hit an ambiguity. The weak move is to stop and ask someone to write you a spec. The owner's move is to make the call, then check it.
So when you meet an edge case, don't go to your PM, designer, or a teammate asking them what to do. Go to them with a decision already in hand:
"We've got this edge case. I intend to handle it this way, for this reason. What do you think?"
Why this is the ownership move and not just a communication trick:
- You don't get blocked. If they're busy, you have a sensible default and you keep moving.
- You make their job easier. Reacting to something concrete is ten times faster than producing a spec from a blank page.
- You stay accountable. The decision was yours, and the feedback only sharpens it.
The fear that stops people, what if I suggest something silly?, is mostly imaginary. You won't die from proposing a wrong idea. (Our CTO has proposed many. He's still alive.) The worst case is someone says "no, because…" and now you both understand the problem better.
Owning your intent is the difference between "tell me what to build" and "here's what I'm building, stop me if I'm wrong." We want the second one.
Own the outcome, not the task
A task is "implement the endpoint." An outcome is "the customer can actually do the thing, in production, without it breaking next month."
The difference is everything. Owning the outcome means you care about what happens after you close the PR: whether it works with real data, whether the next person can maintain it, whether it quietly falls over under load in six weeks. You're not done when the code is written. You're done when the problem is solved.
This is also why, for any real feature work, we ask you to prove production readiness right in the PR: show that you tested it with production-like data. If that's genuinely not possible, make the case for why it'll hold up, with integration tests, end-to-end tests, or just clear reasoning. "It works on my machine" is not an outcome. It's a hope.
Own your pull requests
Your PR is yours from open to merge. That means:
- You make it reviewable. A reviewer who has to reverse-engineer your intent can't protect you. (More on how we turn PRs into stories in One Team, One Brain.)
- You route it to the right eyes. As the codebase grows, each of us knows a smaller fraction of it well. Owning your PR means making the effort to find and notify the person with the real expertise, not just throwing it over the wall.
- You use judgment about merging. There are cases where you should wait for broad team approval. There are cases where merging without review is fine. We won't hand you a rulebook for every situation, because we can't. It's your responsibility to use common sense and work responsibly.
That last line is not a cop-out. It's the whole point. We hire people we trust to think, so we let them think.
Own the review, too
Reviewing is not a rubber stamp. If something looks off, say so, and follow through. Take full ownership of the problem you spotted, even if it's not "your" code, even if it's inconvenient, even if you're not 100% sure. The cost of asking an awkward question is a minute. The cost of staying quiet, as we learned, can be months.
Proactivity in review is the immune system of the codebase. It only works if everyone participates.
Why we work this way
Ownership is the price of autonomy, and autonomy is the thing that makes this job worth doing.
We could buy "safety" with layers of process: sign-offs, gates, committees. But that trades away the very thing that makes a senior team fast and happy: the freedom to see a problem and just fix it. We'd rather ask each person to carry real responsibility and give them real latitude in return.
It's no accident that Autonomy and Impact are two of the five things we hire for. This pillar is just those two qualities, turned into a daily habit.
This kind of ownership is the default setting on our team. We're hiring in Paris. See our open positions.