Writing is Thinking
Staff engineers influence via writing, not just coding. The ability to write a clear, well-reasoned design document is one of the most important skills that separates Staff engineers from Senior engineers. A design document — often called an RFC (Request for Comments) — forces you to think through your design completely before building it, and it creates a record of why decisions were made that future engineers can reference.
The act of writing the document often reveals flaws in the design. If you can't explain a component clearly in prose, you probably don't understand it well enough yet.
Key Sections of a Great RFC:
- Context/Background: Why are we here? What is the current state of the system, and what problem does it create? This section should be understandable by someone who wasn't in the original meetings.
- Goals and Non-Goals: Explicitly state what this design will and will not address. Non-goals are as important as goals — they prevent scope creep and set expectations.
- The Proposed Solution: High-level architecture with a diagram. Explain the key components, how data flows between them, and what changes from the current state.
- Alternatives Considered: (CRITICAL) List the solutions you rejected and explain why. This is the section that proves you thought rigorously about trade-offs rather than just proposing the first idea you had. "We considered Kafka but rejected it because our team has no Kafka operational experience and our message volume doesn't justify the complexity" is a complete thought. "We considered Kafka" is not.
- Risks and Migrations: How will this break things? What is the rollback plan? How do we migrate existing data? What happens to users during the migration window?
- Open Questions: Things you haven't decided yet. Explicitly listing open questions invites reviewers to help resolve them and signals intellectual honesty.
The RFC Review Process:
A good RFC is not a finished document — it's a conversation starter. Share it with stakeholders (other engineers, product, security, data teams) and explicitly ask for feedback on specific sections. Set a review deadline. After incorporating feedback, mark the RFC as "Approved" and link to it from your implementation tickets. This creates an audit trail that future engineers will thank you for.
Interviewers at Staff-level loops often ask: "Tell me about a time you influenced a technical decision without having direct authority." The RFC process is the canonical answer. Describe a situation where you wrote a design doc, listed alternatives with trade-offs, got buy-in from skeptical stakeholders by addressing their concerns in writing, and drove the decision to closure. This demonstrates the Staff-level skill of leading through influence rather than authority.