V. Protect the Flow
Deep work is fragile. So we build a system that protects it.
Great engineering happens in long, uninterrupted stretches of concentration. The problem is that a real company is a constant rain of interruptions: alerts, questions, production hiccups, "quick" requests. If every engineer fields every interruption, nobody ever reaches depth, and the whole team operates in a permanent shallow.
So we don't leave focus to willpower. We design the system to protect it.
The on-duty shield
At any given time, at least one engineer is on duty, and their primary mission is to absorb the chaos so everyone else doesn't have to.
The on-duty person has two jobs:
- Be the team's reactivity. Watch every alert source, answer the questions and requests that come from the rest of the company, handle the daily release, keep an eye on performance, and chew through bugs at the top of the backlog.
- Be a shield. So the rest of the team can focus deeply, knowing that anything urgent will be caught, and anything truly critical will be escalated.
That second job is the quiet genius of it. On-duty isn't just "support duty." It's the thing that buys everyone else the right to ignore Slack for three hours and actually think. We rotate through it, so we all take our turn holding the shield, and we all get long stretches behind it.
Help finish before you start
A subtle one, and a favorite.
Whenever you come back from a break or finish a task, before you pull something brand new, you start by reviewing the pull requests waiting on you.
The logic is pure flow optimization: it's almost always more valuable to help finish a task than to start one. A PR that's ready for review is closer to the finish line than anything you'd start fresh. Reviewing it promptly moves real work into production; starting a new task just adds to the pile of half-done things.
A team obsessed with starting accumulates work in progress. A team that helps finish keeps the pipeline flowing. Be the second kind.
A rhythm for projects
Bigger projects get a light, predictable cadence, just enough structure to stay aligned without strangling the work:
- A daily where everyone on the project leaves with a clear, shared picture of where things stand. We take the time to actually solve problems together; it's fine if it runs long.
- Progress reports aimed at people outside the project, so the rest of the company can follow along without sitting in our meetings.
- A clear definition of "done": not "the core features are in prod," but "there is no more work to do." The last 10% is real work, and we name it as such.
Honesty when things slip
Surprises happen: unexpected work, a mistake that needs rework. When they do, we don't bury them. We spend fifteen minutes doing the honest thing: write down on the project channel what the problem was and how much the estimate slips because of it.
A good update sounds like:
"Feature X is taking longer than expected because of Y. We're trying Z. We're less confident about that part. If we can't get back on track by tomorrow, we'll consider alternatives."
No spin, no heroic silence. If the slip is large, we pull the right people into a room early rather than hoping it resolves itself. Transparent bad news beats a death march and the chaos that follows, every single time.
Why we work this way
Flow is the most valuable and most perishable resource an engineering team has. You can't store it; you can only protect it or waste it.
Every practice here, the shield, finishing before starting, a calm cadence, honest reporting, exists to keep the maximum number of engineer-hours in the state where the best work actually happens: focused, unblocked, and unafraid.
Want to do deep work on a team that defends it? We're hiring in Paris. See our open positions.