Skip to content

How to run a remote architecture review

An architecture review is where a team decides how a system will change. On a distributed engineering team it is usually a video call on the calendar. The proposal is on a shared screen. The notes leave with the person who hosted. The next review opens by trying to remember what was agreed.

Put the review in the channel that owns the system. Post the proposal first. Talk in a walk-in voice room that stays open. Leave the decision in the channel, where the next person can find it.

The usual way

A remote architecture review often looks like this.

  • A Zoom on the calendar. One link, one hour, everyone at once. A teammate in another time zone misses the slot and waits on a recap.
  • The doc and the call stay apart. The design lives in a document. The argument happens on the call. The document still says what it said when the call started.
  • Notes that leave with the host. Someone types while people talk. The file sits in their drive. The channel for that service never gets the sentence that was agreed.
  • The same boundary, again. The question came up last quarter. The answer is in a doc, a direct message, or someone's memory. The review spends its opening reconstructing it.

A format for a distributed team

1. Post the proposal in the channel the day before

One design, one thread. Say what is changing, what it replaces, and the question the review has to answer. Link the longer write-up if there is one. Comments belong in the thread.

People in other time zones reply in the thread before anyone is in voice. Written answers stay there. The live part is for what still needs a conversation, and the thread names who speaks for each part.

2. Name the decision in one sentence

"Thoughts on the design?" fills the hour and settles nothing. Write the decision at the top of the thread.

"Do we split checkout into its own service for this release, or keep it in the monolith?"

One decision. A second topic waits for its own review. If the thread turns up another decision, name it and park it under the first.

3. Talk in a room that stays open

Name the window in the thread. The walk-in voice room beside the channel is already there. People step in when the window starts.

A person who owns one piece walks in for that piece and leaves. A teammate whose day starts later reads the thread, walks in while the room is still up, and adds the part only they can answer. The room stays open after they go, in the same bullpen as the channel.

Walk-in voice vs calendar meetings is the short version. An architecture review uses the same kind of room, next to the proposal thread.

4. Post each decision before the window ends

Approve, change, or defer. Each one is a decision, and each one gets a message in the channel. Use the same four fields every time: what was decided, who owns it, by when, and where to look. How to keep a decision log in team chat is that shape.

Decided: checkout stays in the monolith for this release. Owner: Priya. By Friday she posts the revised diagram in this thread. Where to look: this thread.

If the review changes the proposal, the message says what changed. The longer doc can follow. The channel is what the rest of the team reads next.

How Bullpen fits

Bullpen is team chat with walk-in voice rooms and AI helpers on the roster. The review stays in one channel from the proposal to the decision.

The proposal is a thread. The design note, the comments from other time zones, and the named decision sit with the rest of the work on that system.

The talk is the channel's walk-in voice room. It stays open beside the channel. People walk in for the whole review or for the slice they own.

Wren writes the notes. Wren is an AI helper. In that walk-in voice room, Wren posts notes and action items back to the channel the room belongs to. The spoken review and the written record share one list. Someone who missed the audio reads the notes in the channel.

Scout keeps the prior decision. Scout is an AI helper on the same roster. Before the window starts, mention Scout in the channel and ask what the team already decided about this boundary. Scout answers from what was said and links the message it came from. Open that link and start there, so the hour goes to the new question.

An administrator adds Wren and Scout to the channel the same way they add a person. Wren and Scout post under their own names, with an AI badge, into the thread the team is already reading. AI helpers don't take a seat is how they sit on the roster with the people in the review.

Run the next one this way

The day before the review, post the proposal and the one-sentence decision in the channel that owns the system. Hold the live part in the walk-in voice room beside that channel. Before you leave, post the decision where the thread already is.

Start free.

All posts