> ## Documentation Index
> Fetch the complete documentation index at: https://docs.internal.nscale.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Operating Rhythm

> How the Fleet Manager team's ways of working show up in the week — the weekly cadences, the DRI ownership model, and our review and retrospective norms.

This page is how the tenets in our [Ways of Working](./ways-of-working) guide turn into a
weekly rhythm. Read [Ways of Working](./ways-of-working) first — that's the bar; this is how
the bar shows up day to day.

<Note>
  Owner: Vedran Šimunović. Status: agreed with Omer Khalid and Sulabh Chaturvedi, and in effect now.
</Note>

## Why this exists, and why it is not a process

An honest framing first: this is not a process for its own sake, and I would rather not even
call it one. We are a Day-1 team, shipping and innovating hard, and the one thing we will not
trade away is agility, because that is what has made this team and this product what they are.
What follows is simply how the tenets in our [Ways of Working](./ways-of-working) guide — own
the problem not the ticket, drive change through people, do not stall when blocked, be
pragmatic, lift the whole team — turn into a weekly rhythm.

It runs on high trust and high autonomy. We assume you are heads-down and productive, so none
of the cadences below exist to track you or have you justify your time. They exist to set
priorities, surface blockers, and keep the work visible to the rest of the company with as
little overhead on you as possible. This was worked out with Omer and Sulabh, and we are
aligned to run it.

## The week at a glance

| Cadence | When | Led by | Purpose |
| - | - | - | - |
| Monday planning | Mondays, about 1 hour | Vedran | Review last week, a short ops handover, then reset priorities and create the week's parent problems in Linear. |
| Engineering standups | Per the calendar invites | The team | Surface blockers and things to discuss. Not a status round. |
| Weekly update | Fridays, async | Vedran posts | A tight narrative to #product (what, so what, now what). No meeting, no ticket dump. |
| Backlog refinement | Every other Wednesday | The team | Light pass in the standing Wednesday slot, mostly to see what others have filed. |
| Monthly retrospective | Monthly, the Wednesday slot | Vedran | Takes the Wednesday slot off the biweekly rhythm. Next one: VERNE into LON14. |
| Deployment sync | Evenings, about weekly | Vedran | Clear blockers to LON14 and Oslo, and keep a live ETA. |
| Lunch and learn | Every other Friday, 30 min | Whoever signs up | A deep dive on any topic the presenter chooses. |

## Monday planning, about an hour

We start the week together. The block runs in three short parts:

* **Review, about ten minutes.** What we said we would do last week, and what actually
  landed. We read this off Linear, not a doc anyone filled in by hand. Where we did not do
  what we planned, we ask why. This is never about pointing fingers. Almost always the answer
  is that priorities changed, and that is fine. The questions we actually ask are whether we
  should keep deviating, what the impact is, and who picks up the work we dropped if it still
  matters.
* **Ops handover, ten to fifteen minutes.** Today this is a placeholder, because our
  operational load is still light, and we are putting the slot in now on purpose. We are about
  to own real operations on top of deployments and moving the platform forward, and we want
  the handover habit in place before the load arrives, not after the first incident. As it
  grows, this is where on-call and the state of the [fleet](../start-here/glossary#fleet) get handed over: what broke, what is
  still open, what needs eyes this week.
* **Plan the week.** We create the parent problems and epics in Linear, live, in the meeting,
  and map them to the milestones, so we walk out with them already created and nobody has to do
  ticket admin later, because we know that does not happen. Then we align on who is taking
  what, and off you go.

We plan in problems and outcomes, not in granular tickets and dependencies. You figure out the
best path to the solution. The tickets fall out of that thinking, not the other way around.

The Monday meeting is recorded in Fellow, so if you miss it, or want to rewatch how we landed a
particular alignment, it is there.

## Engineering and UI standups

All standups come from the calendar invites. They are deliberately not a go-around-the-circle,
tell-me-what-you-did meeting. We assume you are productive, so we do not spend the team's time
on status. We lead with two questions instead:

* Who is blocked right now, or needs input from the team?
* Did anyone work on something that was not an agreed priority, and if so, why? We assume you
  made the right call. The point is only to decide together whether to keep going that way,
  what the impact is, and whether the original priority still holds.

This is a place to raise pain points and ask for help openly, not to justify your time. If you
can unblock yourself by reaching out to someone directly, do that. Do not save it for the
meeting.

## How we track work, and the Friday update

The Friday Fleet Manager Weekly Goals meeting is going away. Here is what replaces it, and why.
The real problem was never stale tickets; it was work happening that had no ticket at all, plus
a weak goals ritual where people called out whatever came to mind rather than working from the
board. So:

* Parent problems and epics are placeholders with real context, created on Monday and mapped to
  milestones. That is what the roadmap view needs, since the product leads, including Nidhi,
  look at the Fleet Ops roadmap, so milestones are never empty.
* Sub-tickets attach to those parents retroactively, off the PRs. Sulabh is automating the
  ticket-to-PR mapping in CI. We are not going to force a ticket onto every PR by hand. We
  track the work through the PRs and let the tickets lag a day or two.
* Status comes from PR state, not from anyone updating a field: in progress once work has
  started, in review when the PR is open, and done when it is merged. A bot can surface that so
  the rest of us can see how far along something is.
* The weekly #product update goes out on Friday, drawn from what the board shows we shipped, so
  nobody is chased for status. How we actually write it is in the next section: it is a
  narrative, not a ticket dump.

## The Friday product update

We keep the weekly #product update tight, and we write it for the people reading it. Other
teams paste in the list of tickets they closed. We do not. Our stakeholders are not measuring
us in tickets and do not care about them individually; they care about what moved in the
product and what it means. So the update is a short narrative of the product increment since
last week, grouped into a few themes only if that genuinely makes it clearer.

We write it as what, so what, now what.

* **What.** What actually shipped or changed this week, in plain language.
* **So what.** Why it matters to the reader: what it unblocks, who it helps, the impact on a
  deployment, a customer, or the timeline.
* **Now what.** What is next, what to expect, and anything we need from other teams.

If anyone wants the underlying detail, it is in Linear. The post is the story, not the backlog.

## Backlog refinement

We keep the refinement session, in a standing Wednesday slot, every other week. For our own
work, tickets should already hang off the parent epics, so this is a light pass rather than a
line-by-line review. The real value is seeing what other teams have filed for us, and keeping
priorities groomed. The monthly retrospective shares this same Wednesday slot, on a week off
the biweekly rhythm, so the two never collide.

## Monthly retrospective

We are adding a monthly retro. We have not had one, and the cost has been that lessons only
surfaced through people venting in 1:1s, which is too late and too quiet. Once a month we do it
properly, as a team. It takes the same standing Wednesday slot as backlog refinement, but off
that biweekly rhythm, so once a month that Wednesday becomes the retro instead. The next one is
the lessons from VERNE applied to LON14, and we keep going in that spirit.

## Deployment sync, led by Vedran

I am taking the deployment meeting and moving it to the evening so it works across time zones.
The single goal is to find and clear the blockers to moving deployments forward, with LON14 and
Oslo the focus now.

**On [burn-in](../start-here/glossary#burn-in).** Long term this should not be something we track, and the aim is to hand it off,
but for now it is on us. The way we run it: estimate how many tests are left and how long they
take, and turn that into where the timeline actually lands. We keep one live final ETA, and the
job is to keep pulling it in. When we push harder, that ETA should visibly move earlier; that is
the signal the effort is working.

**Audience.** Deliberately tight, and we run it for about four weeks on LON14 and Oslo before
deciding whether to renew in August: the VDs; the NVDs (Oscar, Anthony, Paddy); product (Omer)
and Steve; Martin O'Hare's key people (Martin, John G, Tom C); Harold and his key folks
(Robert, Manesh); Tony, Karl and Ida from Network ops; Paul Pham from CHAD; and Greg Siekas
from FOE.

## Lunch and learns, every other Friday

Every other Friday we run a 30-minute lunch and learn. Anyone can take a slot and go deep on
whatever they like: a part of the system, a lesson from a deployment, a tool, a technique. It
is informal, and it is for us. Grab a slot in the sign-up sheet. This operating rhythm was the
session that kicked the series off.

**How these run.** It is the speaker's 30 minutes: the speaker talks, and the rest of us
listen. Keep your camera off if you like; the safe assumption is that everyone has a mouth full
of sandwich. This is meant to stay semi-break time, so eat, and nobody should have to shorten
their slot to make room for lunch. Every session is recorded in Fellow, and the link, along
with any slides or artifacts, goes into the sign-up sheet so anyone who missed it can catch up.

## Ownership and the DRI model

We are moving from tribal ownership to an explicit DRI — a directly responsible individual —
per domain. If you are the DRI for an area, you own its delivery clarity: the scope and
non-goals, the success criteria and the current risks, who is working the active slices, and
the interfaces with other teams. You do not have to write every line, be on call for every
issue, or approve every PR that happens to touch your files. What we ask is that you own the
outcome and escalate blocked decisions early.

This pairs with mentoring. On larger or riskier work, a mentor or architecture partner pairs
with the DRI without taking the seat, so people can stretch into ownership with support. Where a
domain has no DRI yet, volunteer for it in planning. The full model, the domain map, and how it
is evolving live in the Fleet Manager DRI and Mentoring Model working doc, and each domain is
growing its own Linear initiative for the live detail.

## Reviewing each other's PRs

When you open a PR, ask for a review explicitly, and name someone. Do not assume it will get
picked up. Just as importantly, feel encouraged to step into an area that is not yours and help
review, because we will not let PR reviews become the new bottleneck. AI has raised how fast we
can produce code; the human part — reviewing it well and keeping it moving — is now where
throughput is won or lost.

New joiners, please review, even when you do not understand everything yet. You will learn the
system faster, a second set of eyes always helps, and questions from someone new often catch
the things the rest of us have stopped seeing.

## Mistakes are part of it

Mistakes are okay. If we are not making any, we are not doing anything. Think of it like tennis:
if you never double-fault, you are not serving hard enough. We still try to land as many aces as
we can, but serving hard means the occasional fault, and that is the trade we want. When we do
make a mistake, we document the gap and improve the process, the same blameless way we run the
retro. We do not point fingers, because that is how you teach a team to stop serving hard, and
agility is the one thing we will not give up.

## What we deliberately do not do

To be clear about the things we are choosing not to do:

* We do not measure expected versus actual deliveries, or count hours. We are a Day-1 team and
  productivity is high by default. That kind of accounting is for a Day-2 company, and it would
  cost us the agility that got us here.
* We do not run status-round standups.
* We do not force a hand-written ticket onto every PR.
* We are not moving to a slow bi-weekly cycle. The weekly rhythm stays, because the weekly
  \#product expectation is real and we will not change that from our seats.

None of this lowers the bar. It keeps the bar on outcomes and agility, where it belongs. This is
meant to reduce friction, not add it. If a part of it is getting in the way rather than helping,
say so in a standup or the retro, and we will change it.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.