IV. One Team, One Brain
As we grow, knowledge, not code, becomes the bottleneck.
When a company is five people in a room, everyone knows everything. Context is free. Then you grow, and something quietly breaks: each person knows a smaller and smaller fraction of the whole. Left alone, a growing team fragments into islands, each fluent in its own corner and blind to the rest.
We refuse to let that happen by accident. Staying one team with one shared brain takes active, deliberate effort, and it's some of the most valuable work we do.
Code review is a knowledge pump
The most obvious purpose of code review is catching mistakes: a second pair of eyes. That's real, but it's the smaller half.
The bigger half is spreading knowledge. Every review is a tiny transfer: the reviewer learns a part of the system they didn't write, the author gets their mental model stress-tested. Over months, this is how understanding stays distributed instead of trapped in whoever happened to write the code.
For that pump to work, a PR has to be more than a diff. It has to be a story the reviewer can follow:
- Business context: what we're doing and why.
- Implementation highlights: the parts that deserve attention.
- Compromises: what you traded off, and why.
- Alternatives: the roads not taken, and the reasoning.
- Testing: how you tested it, with scenarios, edge cases, screenshots.
- Scalability limit: if relevant, how long this should hold.
- What you expect from the reviewer: essentially, "why am I not just merging this to main myself?"
A PR written like this doesn't just get a better review. It teaches. It becomes a little piece of durable documentation about how the system thinks.
This is also why routing matters: we make the effort to get each PR in front of the person with the real domain expertise, because that's where both the best review and the best knowledge transfer happen.
Decisions that outlive the conversation
Some decisions are bigger than a single PR. They touch everyone, they're hard to undo, or they're the kind of tricky situation we need to handle the same way everywhere in the codebase. Those deserve more than a hallway chat that three people remember differently a month later.
For a long time we handled them in a weekly informal architecture meeting. It worked, until it didn't: past a dozen engineers, the meeting got slow and lossy, so we killed it. But that left a hole. Without it, good ideas stayed local, the same debate happened in different corners, and some decisions simply never got made (and we paid for it in mistakes). With the team heading from fifteen toward double that, the hole only got more expensive.
So we adopted ADRs, Architecture Decision Records: short documents that live in the repo and capture a decision plus the thinking behind it, with a simple decision / context / rationale / consequences shape.
A few things made us pick the format:
- They lived in git, so they were right there while we coded, and our AI agents could read them too.
- The pull request flow already gave us review and approval for free. (An ADR is approved by the CTO and a majority of squad leads.)
- The chronology read itself, because an ADR is named for the day it was decided.
The hard part was scope, and we resisted the urge to write a rule for everything. An ADR is for what impacts everyone, what's hard to reverse, or what needs to stay consistent across the codebase. Adding an eslint rule that nudges the whole team away from a pattern? ADR. Turning the app into a PWA because we told a partner we have a mobile app? Hard to undo, so ADR. Removing our Redis dependency, or hacking together a quick A/B test? Local and easily reversible, so no ADR. We couldn't enumerate every case, so we trusted common sense.
It's the same instinct as the rest of this pillar: take the reasoning out of one person's head and make it durable, reviewable, and shared, so the team keeps thinking with one brain even as it doubles.
Shadow calls: see other teams in their daily work
Here's a habit that surprises people. Once a month, every engineer spends half an hour sitting next to someone in sales, care, or broker support, headphones on, watching everything they do, listening to their calls.
You're not there to fix anything. You're there to understand.
Why we do it: one of the biggest strengths of Orus is that people from different teams genuinely understand each other and pull toward the same goals. As the company grows, that understanding doesn't maintain itself. You have to actively top it up. Half an hour next to a colleague on the phone teaches you more about a real customer's pain than a month of tickets, and it sparks a hundred informal conversations that no org chart could plan.
The output isn't just empathy. Engineers routinely walk out with concrete insights and quick wins, small fixes you can ship the same day, and they share the bigger learnings with the whole team afterward.
Share what you learn
Whatever you discover, from a shadow call, from a project, from a nasty bug, push it back out to the team. When a project wraps, we present a success report, run a retrospective, and share the REX (return of experience) with the wider company.
A lesson learned by one person is a footnote. A lesson shared with everyone is an upgrade to the whole organization's brain.
Why we work this way
You can think of all of this as fighting entropy. The natural drift of any growing team is toward silos, surprise, and "wait, who knows how this works?" Reviews, shadowing, and sharing are the counter-forces: small, constant inputs of energy that keep us coherent.
It's the same reason we care so much about how we hire: we look for people who lift the team, not just themselves, who teach, unblock, and leave things better than they found them. A shared brain is only as good as the people willing to share theirs.
If you like teams that actually talk to each other, we're hiring in Paris. See our open positions.