English for Senior Engineers: RFC Writing, ADRs, and Technical Strategy

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

1. “We considered a microservices split at this layer but rejected it because the operational overhead would outweigh the benefits given our current team size.”
2. “This ADR supersedes ADR-012, which proposed using MySQL; the decision was revisited following our acquisition of a team with deep PostgreSQL expertise.”
3. “The open question is whether to adopt the new messaging format immediately or maintain backward compatibility for a transition period of six months.”
4. “The primary driver of this strategy is reducing the operational toil that currently consumes approximately 25% of engineering capacity each quarter.”
5. “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.”

Navigating Nuances: Refining Your Approach to Feedback & Requests

Senior engineering communication isn’t just about conveying facts; it’s about shaping understanding and driving action. A common frustration for non-native English speakers is the subtle but powerful way feedback is delivered, particularly in asynchronous channels like Slack or during code reviews. It’s easy to interpret a seemingly blunt comment as personal criticism when the underlying intention – to improve the code – isn’t immediately clear. Let’s explore how to refine your approach and confidently engage with these situations.

Consider this scenario: A junior engineer pushes a PR with several duplicated sections of code. The senior reviewer, Sarah, leaves a comment in the associated pull request: “This section is redundant.” While technically accurate, it lacks context and doesn’t offer a path forward. A more helpful response would be something like, “I noticed some duplication here; could you clarify the intent behind repeating this logic? Perhaps we can refactor to avoid redundancy.” Notice the shift in tone – focusing on intent rather than simply pointing out an error. Another common situation is requesting clarification: “Can you elaborate on what you mean by ‘this needs more tests’?” Instead of reacting defensively, a clarifying question shows engagement and allows Sarah to provide specific guidance. Similarly, when describing changes in a PR description, avoid vague statements like “Fixed bugs.” Instead try, “Implemented fixes for issue #123 and #456, addressing performance bottlenecks identified during testing.”

A crucial element is understanding the difference between stating a problem and requesting a solution. Senior engineers often frame their feedback as requests for collaboration – “Let’s discuss how best to handle this…” or “Could we explore alternative approaches?”. This collaborative framing reduces defensiveness and fosters a sense of shared ownership. Furthermore, actively demonstrating you’ve understood the feedback is vital. A simple acknowledgement like, “Okay, I see - so you want me to prioritize refactoring this component before addressing the new feature?” shows that you’re listening and taking action. Don’t be afraid to ask for clarification if something isn’t immediately obvious; it’s far better to seek understanding than to proceed with assumptions. Remember, technical communication is fundamentally about human communication – building relationships and working together towards a common goal. Focusing on clear, respectful language will dramatically improve your effectiveness and confidence within the team.