↓Skip to main content

How [Type: RFC] Messages Transformed Our Team's Decision-Making

·6 mins
Slack Communication Decision-Making Team Collaboration Async
Table of Contents

TL;DR: Most Slack decisions die in private messages, emoji reactions, and orphaned threads. We fixed it with one convention: structured message prefixes. [Type: RFC] for proposals needing input, [Type: FYI] for informational, [Type: Decision] for outcomes. Three months in, a single RFC collected input from 8 engineers across 3 time zones in 48 hours - no meeting required - and our weekly alignment sync shrank from 90 to 30 minutes. Here’s the system and how to roll it out.

When I joined the team, the first decision I tried to look up was already lost.

I had been there a week. I asked, in a thread: what had we decided about the database migration? Three people answered. They gave three different answers. One pointed at a Slack message from the previous Tuesday. Another said it had come up in standup. The third was sure we had pushed it to next sprint. Some decision existed, somewhere, but nobody could reconstruct it from the available evidence.

The team was not bad at communicating - they communicated plenty. The problem was that every Slack message looked the same. Important architectural decisions were buried under emoji reactions in the general channel. Half the conversations happened in DMs nobody else could see. Threading was inconsistent - some people replied in-thread, others dropped responses directly in the channel, and critical context got split across both.

I tried the obvious fixes first. I asked the team to please use threads consistently. I wrote a wiki page titled “How We Communicate” that, based on the page analytics, exactly two people read - and one of them was me. I suggested we add a weekly sync to “get aligned,” which just added another meeting to everyone’s calendar without solving anything.

Then a colleague suggested we try structured message prefixes - a simple tagging convention borrowed from the RFC tradition in internet engineering. The first week felt awkward. By the third week, I could scan our engineering channel in two minutes and know exactly what needed my attention, what decisions were pending, and what had already been resolved. That shift is what this post is about.

The RFC Convention #

RFC stands for “Request for Comments” - borrowed from the internet engineering tradition where technical proposals are shared for community feedback. The IETF has used this format since 1969 to shape the internet’s core protocols. We borrowed the spirit - structured proposals inviting input before implementation - and adapted it for Slack.

In our Slack workflow, an RFC is a structured proposal that:

  • Presents a problem or opportunity
  • Proposes a solution or change
  • Invites team discussion before implementation
  • Sets a clear timeline for feedback

Anatomy of a Good RFC Message #

Here’s the template we use:

[Type: RFC] [Brief, clear title of the proposal]

**Context:** 
What's the current situation? Why does this matter now?

**Proposal:** 
What are you suggesting? Be specific.

**Alternatives Considered:**
1. Option A - pros/cons
2. Option B - pros/cons

**Impact:**
- Who/what will this affect?
- Timeline estimate?
- Any risks or concerns?

**Questions for the team:**
- Specific questions you need answered
- Areas where you want input

**Feedback deadline:** [Date/time]

Real Example (Anonymised) #

[Type: RFC][Priority: Medium] Switch from REST to GraphQL for mobile API

**Context:** 
Our mobile app makes 15+ API calls on the home screen, causing slow load times. 
Users in areas with poor connectivity are especially affected.

**Proposal:** 
Implement GraphQL for mobile clients to allow single-request data fetching. 
REST endpoints remain for web and legacy systems.

**Alternatives Considered:**
1. Optimize existing REST endpoints → Still requires multiple round trips
2. Create custom aggregation endpoints → Maintenance burden, inflexible
3. GraphQL → More complex initially, but flexible and efficient long-term

**Impact:**
- Mobile team: 2-3 weeks implementation
- Backend team: 1 week to set up GraphQL server
- No breaking changes for existing clients
- Expected 60% reduction in mobile API calls

**Questions:**
- Any concerns about GraphQL learning curve?
- Should we migrate all endpoints or start with home screen?
- Caching strategy thoughts?

**Feedback deadline:** EOD Friday

Thread replies welcome, or feel free to DM me!

Beyond RFC: A Small Family of Prefixes #

Once RFC clicked, we added a few more. Each one proved its worth by being instantly scannable and trivially searchable:

  • [Type: FYI] - informational, no action required
  • [Type: Question] - quick questions that need a single answer
  • [Type: Bug][Priority: High] - issues needing attention, with severity
  • [Status: Blocked] - progress updates flagging an external blocker
  • [Type: Decision] - documents the outcome of an RFC, cross-referencing the source thread

The [Type: Decision] prefix is the one most teams skip - and the one that pays off most over time. It closes the loop. Six months later, when someone asks “why did we choose GraphQL?”, a search for [Type: Decision] returns the answer, the rationale, and the link back to the RFC where the alternatives were weighed:

[Type: Decision][From RFC: GraphQL Migration]
We're moving forward with GraphQL for mobile.
Start date: Next sprint
Implementation lead: @sarah

Resist the urge to add more types. Five prefixes you’ll actually use beats fifteen you won’t.

What Changed for Us #

After three months of using structured messages:

Decisions got faster What used to take 3-4 meetings now happened in one well-structured RFC thread. Our GraphQL migration RFC collected input from 8 engineers across 3 time zones in 48 hours. No meeting required.

Nothing got lost Searching [Type: RFC] in Slack now returns every major technical decision from the past year, with full context and rationale. Onboarding new engineers became easier - instead of asking around, they could read the thread and understand not just what we decided, but why.

Fewer meetings Our weekly “alignment” meeting went from 90 minutes to 30 minutes. Most topics were already discussed async. The 60 minutes we got back? Engineers used it to actually write code.

Better participation Before prefixes, the same 3 people drove every discussion. After, we regularly saw input from 6-8 engineers per RFC. The structured format gave quieter team members time to think and a clear place to contribute.

Clearer priorities When everything isn’t urgent, actually urgent things stand out.

The Bottom Line #

When you tag a message [Type: RFC], you’re saying: this is important, I’ve thought it through, and I value your input. When you tag something [Type: FYI], you’re saying: this is useful context, but don’t let it interrupt your flow.

The prefixes didn’t transform our decisions. They made our decisions findable - which, six months later, is the same thing.