English for Senior Engineers: RFC Writing, ADRs, and Technical Strategy
Learn the vocabulary and writing patterns senior engineers use for RFCs, Architecture Decision Records, technical strategy documents, and cross-team alignment.
Senior engineers spend a significant portion of their time writing — not code, but documents. RFCs (Requests for Comments), ADRs (Architecture Decision Records), technical strategy documents, and tech-debt proposals are the tools through which senior engineers influence systems and organisations beyond their immediate team. Writing these well in English is a high-leverage skill.
RFC Vocabulary and Structure
An RFC is a document that proposes a change, invites feedback, and records the decision-making process. The vocabulary in an RFC signals the author’s level of rigour.
Key RFC Sections
| Section | Purpose | Vocabulary to use |
|---|---|---|
| Problem statement | Describe what is broken or missing | ”Currently, the system lacks…”, “This results in…”, “The consequence is…” |
| Proposed solution | Describe your recommended approach | ”We propose…”, “This solution addresses…by…” |
| Alternatives considered | Show you evaluated other options | ”We evaluated X but rejected it because…”, “An alternative approach would be…” |
| Trade-offs | Acknowledge what you’re giving up | ”The primary trade-off is…”, “This approach introduces…” |
| Open questions | Flag unresolved decisions | ”It is unclear whether…”, “We have not yet determined…” |
RFC Language Patterns
RFCs are written in the first-person plural (we) because they represent team decisions, not individual preferences. They use formal but plain language — avoid unnecessarily complex sentence structures.
- “We propose migrating the authentication service to a token-based approach in order to reduce coupling between the API gateway and individual services.”
- “The current architecture requires all services to query the user database directly, which results in N+1 query patterns and unpredictable latency under load.”
Architecture Decision Records (ADRs)
An ADR records a single architectural decision — the context, the decision, and the consequences. They are shorter than RFCs and written after the decision is made (or at the point of making it).
ADR Template in Plain English
Title: Use PostgreSQL as the primary data store
Status: Accepted
Context:
We need a relational data store for the billing service. The team has strong
PostgreSQL expertise, and the data model is highly relational.
Decision:
We will use PostgreSQL 15 hosted on AWS RDS.
Consequences:
Positive: familiar tooling, strong ACID guarantees, mature ecosystem.
Negative: introduces a managed service dependency; requires DBA oversight at scale.ADR Vocabulary
| Term | Meaning |
|---|---|
| Status | Proposed / Accepted / Deprecated / Superseded |
| Superseded by | A newer ADR that replaces this one |
| Consequences | The outcomes — both positive and negative — of the decision |
| Constraints | External factors that limited your options |
Technical Strategy Document Language
A technical strategy document explains how engineering decisions support business goals over a 12–24 month horizon. The language must connect technical choices to business outcomes.
Connecting technical work to business value:
- “By reducing deployment lead time, we will be able to respond to market changes more rapidly.”
- “Consolidating our data pipelines will reduce engineering maintenance burden by an estimated 20%, freeing capacity for product work.”
- “This architectural change is a prerequisite for the international expansion planned for Q4.”
Cross-Team Alignment Phrases
Senior engineers often need to coordinate changes that affect multiple teams. These phrases help you communicate dependencies, negotiate priorities, and build consensus.
- “This change will require interface updates from the platform team — we’d like to discuss the timeline with them before committing.”
- “To move forward, we need alignment on the API contract between our teams.”
- “I’d like to propose a design review with both teams present to ensure we’re solving the shared problem consistently.”
Communicating Technical Debt
Technical debt is a common topic in strategy documents. Avoid using the phrase as a vague excuse — be specific about the nature of the debt and its cost.
| Vague | Specific |
|---|---|
| ”We have a lot of tech debt." | "The authentication service has not been updated since 2021 and uses a deprecated OAuth library. Every new feature in this area takes 30% longer than it should." |
| "This will be hard to maintain." | "This approach will require manual intervention each time a new payment provider is added. We estimate this will happen three to four times per year.” |
Example Phrases
- “We considered a microservices split at this layer but rejected it because the operational overhead would outweigh the benefits given our current team size.”
- “This ADR supersedes ADR-012, which proposed using MySQL; the decision was revisited following our acquisition of a team with deep PostgreSQL expertise.”
- “The open question is whether to adopt the new messaging format immediately or maintain backward compatibility for a transition period of six months.”
- “The primary driver of this strategy is reducing the operational toil that currently consumes approximately 25% of engineering capacity each quarter.”
- “We are proposing this RFC to the wider engineering group to gather feedback before the design is finalised — comments are open until the end of the sprint.”