Engineering Meetings

The live formats a team can show up to — standing blocks you protect on the calendar, plus working sessions they pull on request.

What these are

These are the recurring engineering formats — the help that happens in a room, in real time, on a rhythm a team can plan around. They’re pilots, not permanent commitments: each one is meant to be low-effort to offer and high-return for the team using it, and each one is something you can stop, reshape, or hand off the day it stops earning its place. None of them is a substitute for embedded engineering work — they’re the connective tissue between deployments, the thing a team reaches for in the moment without waiting for a new engineer to be hired and onboarded.

There is one throughline: enablement, not capacity substitution. The job is to upgrade the team you’re helping so it can do the next thing without you — not to become the engineer it never staffed. A standing block that drifts from answering questions into doing the team’s work has stopped being a pilot and started being load you’ll carry until you leave.

These three formats sort into two kinds. Standing blocks — office hours and sounding-board hours — are recurring slots you protect whether or not they fill. On-request sessions — architecture reviews — are pulled, not pushed: a team asks, usually through intake, and you run a timeboxed working session. The front door teams use to reach any of these, and the artifacts they walk away with, live in Engineering Support.

Format	What it is	When it happens	Link
Office hours	A standing open block where teams bring questions	~45 min/wk, protected	Office hours
Technical sounding-board hours	A standing block to think through technical ambiguity together	Standing block, async-friendly	Sounding-board hours
Lightweight architecture reviews	A technical second opinion on request — not a gate	60–90 min each, on request	Architecture reviews

Notice the “when it happens” column is the commitment you’re signing up to protect. The standing blocks cost you the slot whether or not it fills; the review costs you nothing until a team pulls it. Read the column as the difference between protecting time and answering a call — a block you can’t protect is one you shouldn’t offer.

Each format page ends with a Templates section — copy-paste calendar invites and launch emails — so standing one up is mostly swapping the [brackets] and sending. If you’re starting one of these for the first time, that section is where to go.

How they group

The three formats aren’t a flat list. They sort into two kinds, and the kind tells you how to run it.

Standing blocks

Office hours and sounding-board hours are recurring slots you protect on the calendar. Their product is consistency: a team has to be able to count on the block being there, even on the weeks attendance is thin. You spend the time whether or not it fills, because a standing block that flickers in and out isn’t one teams can plan around. The two split by what a team brings — a concrete question goes to office hours; an unformed ambiguity goes to the sounding board.

On-request sessions

Lightweight architecture reviews are pulled, not pushed. A team asks, usually through intake, and you run a timeboxed working session. The discipline here is staying timeboxed and staying a second opinion — the moment a review becomes something teams wait for before they ship, it’s stopped being help and started being a gate.

Notice a standing block spends your time on a schedule you set, while a review spends it on a schedule a team sets. The first you defend against drift into a meeting nobody needs; the second you defend against drift into a gate nobody can ship past.

This is also where new recurring formats land. If a standing team meeting or some other regular block earns its place, it joins this menu and gets sorted into the same two kinds — a slot you protect, or a session a team pulls. The test for adding one is the same test for keeping the three already here.

How you decide what to keep

Run the formats themselves through the same four questions the intro uses to screen incoming work. The questions aren’t only for requests — they’re how you keep your own calendar honest.

Question	How you’d detect a format failing it
Is this an engineering gap we can actually move?	The block keeps surfacing procurement, budget, or staffing walls it can’t touch — and the room talks past the real blocker every week.
Does it unblock more than one team?	Attendance traces back to a single loud engagement; no second team has shown up in two months.
Are we the team best positioned to run it?	Research, design, or another team already runs a block like this better, and you’re duplicating their room.
Will it carry forward without us?	The block only works while you personally show up; nothing about it would survive your rotation.

Notice every row is testable. You don’t decide whether to keep a block on a feeling — you look for the named tell, and a format that trips a row is one to kill or reshape, not defend.

Re-ask these at month three and month six, not just at the start. The answers change. A block that unblocked four teams in its first month can quietly become a standing meeting that serves one — and the discipline of revisiting the questions is what catches a format drifting from enablement into capacity substitution before you’ve spent a quarter on it.

Saying yes to everything is saying yes to doing nothing well. Every block you keep on the calendar out of habit is time you’re not spending on the one that’s actually working. Killing a drifting block isn’t a failure of the format — it’s the whole point of running them as pilots.