Asking another team to review an RFC

A cross-team RFC fails when the ask is "look at this" and the doc is four thousand words. Name which review you want, list what you already rejected, and make a silent default explicit.

3 min read

You published an RFC. The other team owns the surface it will touch. You drop the link in a channel you both happen to be in, with "when you get a chance." A week later you have one thumbs-up from someone who does not own the area, and a question that reopens the storage choice you closed on page one.

They are not on your team. They do not share your stand-up. They will not absorb the context by sitting near you.

Say which review, in a sentence

Correctness. Does the failure mode you named actually fail that way in their system? Needs someone who runs it, and real time.

Approach. Is this the right shape to land on their side at all? The legitimate answer includes "do not do this."

Blessing to proceed. You are confident and need them not to be surprised later. Five minutes, and saying so is a gift.

Most cross-team frustration is a mismatch. You wanted approach. They spent an hour on line comments in a design you may not ship. Pick a response shape and write it at the top. "Approach feedback, not line-by-line. I will come back for correctness once the shape is agreed."

Give them your dead ends

Reviewing means generating alternatives. If the RFC hides the ones you already killed, a good reviewer spends their budget regenerating week one. You will read that as inattention. They were working.

One line each: the option, and why it lost. Include the one you dropped because you ran out of time. That is the one worth reopening, and the one people omit because it looks careless. On the page it reads as honesty.

Mark what is decided and what would reopen it. A flat RFC looks equally negotiable in every paragraph, so they will pick the one they have an opinion about — possibly the one you cannot change.

Make silence mean something

Ask for a decision with a default: "I will treat no reply by Thursday 17:00 UTC as no objection to the approach, and start the spike. Correctness can still land next week."

That is uncomfortable, and it is clearer than a doc open in a tab for a fortnight. If you would not actually proceed without a named person, write that instead of dressing it as a deadline.

The reply is the point. A reviewer who holds your rejected options can give you a useful no in five minutes. A reviewer holding only a link will give you nothing you can use.

You do not need their Slack

Send a briefing. Point at the RFC; do not paste it. There are no attachments, so the brief has to carry the ask, the rejected list, and the default. You approve what goes out.

If they have accounts, invite them as contacts first. If they do not, the note is email and a page. Different companies, different chat tools — none of that is required.

If the RFC is going out this week, connect your assistant and have it draft the ask that should have been on the link all along.

Frequently asked questions

How do you ask another team to review an RFC?
Name which review you want — correctness, approach, or a blessing to proceed — then list the alternatives you already rejected with one line of reasoning each. Mark what is closed, and say what you will do on a dated hour if nobody replies.
Why do cross-team reviews come back empty or late?
Because the other team cannot tell whether you want an hour of scrutiny or a five-minute sign-off, and they have no shared stand-up in which to ask. Faced with a long document and no index, the cheapest safe reply is silence or a vague LGTM.
Do both teams need to share a chat workspace?
No. The review can travel as a briefing and a link. If they already have RelayLink accounts, you need an accepted contact. If they do not, they can read and reply without installing anything.