“Measure twice, cut once.”
It is an old cliché but the team at Segment (the customer data platform) learned it the hard way.
In 2018 their engineering team followed the industry hype and broke their core product into 140 microservices. It was an architectural marvel. It followed every “best practice” in the book.
Three years later they published a famous post admitting it was a disaster.
The complexity had exploded. Engineers were spending more time managing message queues and debugging distributed traces than shipping features. In 2020 they had to burn months of effort to move everything back to a Monolith.
What went wrong?
They jumped to the Solution (Microservices are scalable!) before rigorously validating the Problem (Does our team size justify this operational complexity?).
The root cause is always the same. The rush to code beats the discipline to think.
Senior engineers prevent this with a deceptively simple practice. They write things down before they write code. Not because they love documentation but because three days of planning prevents three years of pain.
The “Google Doc” That Saves Months
When an engineer says “let me write an RFC before we start” they are not adding bureaucracy. They are buying insurance.
RFC stands for Request for Comments. It is a structured document that forces you to answer the hard questions before you open your IDE.
The magic isn’t the format. The magic is that it forces Explicit Thinking about Implicit Assumptions.
In the Segment case, an RFC would have surfaced the core question: “Do we actually have the staff to maintain 140 separate deployment pipelines?”
Someone would have commented: “No. We will spend 50% of our week just keeping the lights on.”
That comment would have saved them millions of dollars.
What Good Looks Like
You don’t need a complex template. You just need to answer six questions in plain English.
1. What problem are we solving? Don’t use vague product-speak. Use specific pain.
- Bad: “We need to re-architect the backend.”
- Good: “Our current monolithic build takes 45 minutes to deploy. This costs us 10 developer-hours per day in waiting time.”
2. What approaches did we consider? List at least three options. This proves you didn’t just fall in love with your first idea.
- Option A: Microservices (High scale, high operational cost).
- Option B: Modular Monolith (Medium scale, low cost).
- Option C: Serverless (High vendor lock-in).
3. What are we proposing and why? Give a recommendation with clear reasoning.
- Verdict: “We recommend Option B. It solves the deployment speed issue without requiring us to hire a dedicated DevOps team.”
4. What are the tradeoffs? Every decision has a cost. If you pretend there are no downsides nobody will trust your plan.
- Tradeoff: “A Modular Monolith is harder to split up later if we grow to 500 engineers. We accept this risk because we are currently only 20 engineers.”
5. What could go wrong? Paranoid thinking during planning prevents panic during execution.
- Risk: “What if the build time doesn’t actually improve?”
- Mitigation: “We will prototype the build pipeline for one module before migrating the rest.”
6. What are the open questions? Admitting what you don’t know encourages others to help you.
- Question: “Do we need to update our CI/CD provider to support this?”
The AI “Red Team”
The hardest part of writing an RFC is seeing your own bad ideas. You are biased. You want your solution to work.
This is where AI becomes a superpower. Not for writing the text but for challenging the logic.
Before I share a draft with my team I paste the “Tradeoffs” section into Claude or ChatGPT and I use this prompt:
“Act as a cynical Principal Engineer. Read this architectural proposal. Tell me exactly how this system will fail at 10x scale and list three edge cases I have forgotten.”
It simulates a harsh review instantly. It finds the holes in your logic before your boss does. Use AI to stress-test your thinking, not just to fix your grammar.
The “Async” Review
The best part of an RFC is that it kills meetings.
You write the doc. You share it in Slack or Teams. You let people comment on their own time for 3 days.
- The Skeptic will ask: “This database schema looks complex. Have you considered a simple key-value store?”
- The Product Manager will clarify: “Actually we need to support offline mode. This architecture relies too much on the cloud.”
- The Junior will ask: “How does this handle user timezones?”
You fix the flaws in the document. Fixing a flaw in a Google Doc takes 5 minutes. Fixing that same flaw after you wrote the code takes 5 days.
Disagreement during the RFC phase is productive. Disagreement during the Code Review phase is expensive.
A Real Example: The “Comfort Zone” Trap
A fintech team needed to store data for a new transaction service. They had a “Golden Hammer” which was a specific technology stack they loved and used for absolutely everything.
When this new complex feature came up the team naturally reached for their favorite tool again. It was the comfortable choice.
But the Lead Engineer wrote an RFC to challenge it.
He pointed out that their “favorite tool” was actually terrible at handling the specific requirements of this new feature.
He wrote: “If we use our standard tool we will have to write massive amounts of hacky code to make it work. It will be buggy and slow. I propose we use a specialized tool that is designed for this exact problem.”
The team pushed back. “We don’t know that new tool! It will take too long to learn!”
But the RFC made the tradeoffs clear. The cost of learning the new tool was high but the cost of maintaining the hacky solution was higher. The team agreed.
Six months later that decision saved them. The feature ran perfectly. If they had skipped the RFC and stayed in their comfort zone they would have been drowning in technical debt.
When to Skip It
Don’t be the person who writes an RFC for a button color change.
Skip the RFC for:
- Small, reversible decisions.
- Urgent bug fixes.
- Work that takes less than 3 days.
Write the RFC for:
- Architectural changes.
- New tools or libraries.
- Decisions that are hard to reverse (like picking a database or a framework).
Your Homework
Look at the biggest ticket in your current sprint.
Ask yourself: “If I am wrong about how I plan to build this, how expensive will it be to fix later?”
If the answer is “Very Expensive” then open a blank document. Write down the problem, three solutions, and your recommendation. Send it to your team.
You might just save yourself three months of work.