Skip to main content

Appendix: Processes

We like process. Not the bureaucratic kind that exists to cover someone's back, but the useful kind: a good process is frozen judgment, a decision we already made well, written down so we stop re-making it and so the right thing becomes the easy thing.

This is not all of it. It's a small, deliberately concrete sample, here to show how we turn the principles above into simple, actionable routines. The pillars are the why; this is a taste of the what, as it actually looks today. Snapshots, not laws carved in stone.

Last updated: June 2026.

Code review​

Our pull request template, which doubles as a checklist:

  1. Closes: a link to the ticket
  2. Release note: explain the change and mention the team (an AI rephrases it for the public changelog)
  3. Context: the business context worth knowing
  4. Problem (or opportunity): what's wrong, or what we're trying to achieve
  5. Solution: how you addressed it
  6. Test: why you're sure it's correct
  7. Demo: screenshots or a Loom when relevant
  8. BTW: drive-by fixes and anything else worth flagging

Shadow calls​

A monthly, thirty-minute session sitting next to someone in sales, care, or broker support.

Before the session:

  1. Plan to be at the office (you can do it remotely, but you learn more watching the tooling in person)
  2. Bring working earphones (you won't need to speak)
  3. Get access to the Aircall activity feed via the shared shadowing account (credentials in 1Password)
  4. Announce yourself in the team's Slack channel and ask for a partner
  5. Add your partner to the recurring "Shadow call session" invite, and move it if the timing doesn't work

During the session:

  1. Open the Aircall activity feed and sit next to the person you're shadowing
  2. The moment they start a call, find them in the list and click "Coach"
  3. Uncheck the "notify the participants" option, so you don't disrupt the call
  4. You now hear everything they say in your headphones
  5. Observe, take notes, and look for insights and quick wins

After the session:

  1. Post your learnings in the #product-discovery Slack channel
  2. Archive them on the UR-internal-Tech-Shadowings-2026 Notion page
  3. If you spotted a quick win under an hour with no debate needed, just ship it
  4. Improve this page for whoever shadows next

On-duty​

A rotating role: at any time, one engineer holds it. A day on duty, in priority order:

  1. Watch every alert source (#tech-alerts, #product-requests, third-party emails) and triage each one
  2. Ship the daily production release
  3. Open the weekly dependency-bump PR
  4. Open the weekly PR that refreshes activity-group seed data from production, so tests stay accurate
  5. Check the Top 10 slowest-requests graph and file a bug for anything slower than 5 seconds
  6. Fix as many bugs at the top of the backlog as you can
  7. Bonus, once all of the above is handled: implement the quick wins you spot

Zero-bug triage​

Bugs sit at the top of the list. Each one runs the same loop:

  1. Reception: a bug arrives (an alert, a #product-request, an on-duty find)
  2. Triage: the on-duty person sizes it and assigns a squad
  3. Route it by size:
    • 3.a, fix: it can be fixed in a few days at most and needs no major architecture overhaul. Create the ticket with the type:bug tag; it automatically takes priority over other tasks.
    • 3.b, refactor: it needs a complex refactoring project (core model migration, feature removal, and the like). Open a pull request adding an item in docs/tech-debt and tag the CTO on it. The item documents the core problem in depth, its consequences, and the strategy to stick to while the problem is still live. This becomes input for the roadmap.

Project warm-up and reporting​

Before any code (the warmup, about a week):

  1. Kick-off: the PM hands the project from Product to Tech; the project team meets with the CTO and the lead PM and designer; a scoping message goes on the project channel
  2. Scope presentation: the project's tech lead presents how it will be built, tested, released, and monitored, from a written document reviewed in advance; a "dev start" message goes on the project channel

During the project:

  1. A daily where everyone leaves with a clear, shared picture (it's fine if it runs forty minutes; solve the real issues there)
  2. Progress reports written for people outside the project
  3. On a surprise or scope change: within fifteen minutes, post the cause and the new ETA on the project channel and log it in the red bin; if the slip is more than about two days, call a meeting with the CTO and the lead PM
  4. Dev end: signal it explicitly. "Done" means there's no work left, not "the core features are in prod"

Architecture Decision Records​

For a decision that impacts everyone, is hard to reverse, or needs to stay consistent across the codebase:

  1. Write a short file in docs/adrs/, named adr-YYYY-MM-DD-short-title.md
  2. Fill the template: decision / context / rationale / consequences
  3. Open it as a pull request; it's approved by the CTO and a majority of squad leads

Requires an ADR: adding an eslint rule that discourages a pattern, introducing an org-wide file-upload store, making the app a PWA. Doesn't: adding a store for a single feature, removing the Redis dependency, hacking together a quick A/B test (all local or easily reversible).

info

We're hiring in Paris. See our open positions.