Communication as a Product
If no one understands the decision, the system is already broken
Most engineering teams say communication matters. Fewer treat it like a product.
After working across different programming cultures, as a Ruby developer embedded in teams that range from highly process-driven to aggressively informal, I have come to a strong conviction: RFCs and technical documentation deserve the same rigor as production code. Not “nice to have” rigor. Product-grade rigor.
This is not about writing more docs. It is about recognizing that communication is itself a system, with users, failure modes, and long-term maintenance costs.
The Hidden Cost of “Just Write It Down”
In many teams, documentation is treated as exhaust. Code is the product; docs are a side effect. RFCs are often written quickly to unblock a decision, then abandoned. The result is predictable:
Design intent lives in Slack threads no one can find.
RFCs exist, but no one trusts them to be current.
Onboarding depends on tribal knowledge rather than artifacts.
Engineers re-litigate the same decisions every six months.
When this happens, the organization pays the cost repeatedly.
The cost shows up as slower delivery, misaligned implementations, and avoidable architectural churn.
We would never accept this behaviour from production code. We do not say, “It worked once; ship it and forget it.” Yet we routinely apply that logic to communication.
Communication Has Users
The moment you treat communication as a product, the first thing that becomes obvious is that it has users.
Future engineers (including future you)
Adjacent teams integrating with your system
New hires trying to understand why things are the way they are
Incident responders under time pressure
These users have needs that are remarkably consistent:
Clarity over cleverness
Stability over novelty
Explicit trade-offs rather than implicit assumptions
Just like any product, if you ignore your users, they will work around you. That is how shadow docs, private notes, and folklore emerge.
RFCs as Design Artifacts, Not Formalities
In healthy engineering cultures, RFCs are not ceremonial. They are design artifacts.
A good RFC does the same things good code does:
Defines a clear problem boundary
Makes assumptions explicit
Explains trade-offs and rejected alternatives
Optimizes for readability over brevity
When I write an RFC, I apply the same standards I would to a critical library:
If a new engineer cannot understand it in one sitting, it is not done.
If the decision rationale is unclear, it is a bug.
If the scope creeps without justification, it needs refactoring.
An RFC that cannot stand on its own will not age well. And aging is the real test.
Documentation as a Maintained Surface Area
Production systems have surface area: APIs, interfaces, invariants. Documentation has the same property.
Every paragraph you publish is a contract with the reader. If it becomes outdated, it actively harms understanding. This is why “some documentation” is often worse than none.
Treating documentation as a product changes how you approach it:
You version it alongside code.
You remove dead sections aggressively.
You prefer fewer, authoritative documents over many partial ones.
You design for long-term readability, not speed of writing.
Rigor Without Bureaucracy
Treating communication seriously does not mean adding process for its own sake. It means applying engineering judgment.
Not every change needs a 10-page RFC. Not every doc needs exhaustive detail. But the important artifacts, the ones that shape systems and teams, deserve intentional design and review.
The goal is not more writing. The goal is less ambiguity.
When communication is clear, engineers move faster. When it is vague, speed is an illusion.
The Payoff
Teams that treat communication as a product experience second-order benefits:
Decisions scale beyond the people in the room.
Architectural intent survives team churn.
Disagreements become more productive, because the problem is well framed.
The organization builds institutional memory instead of losing it.
None of this is accidental. It is the result of choosing to invest in communication with the same seriousness we invest in code.
Closing Thought
Software engineers are trained to think in systems. Communication is one of the most critical systems we build; yet we often leave it under-designed.
When you start treating RFCs and documentation as production assets, something subtle changes. You stop writing to “get it over with” and start writing to be understood.
That shift, in my experience, is one of the highest-leverage changes an engineering team can make.