Owner: Vedran Šimunović. Status: agreed with Omer Khalid and Sulabh Chaturvedi, and in effect now.
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 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
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 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.
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.
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.
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. 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.