Design Documents, RFCs, and What They Show
The documents an engineer writes are the most under-claimed evidence available. A design document that changed a decision, a postmortem that produced a permanent fix, a standard other teams now follow — these are artefacts with your name on them, and most resumes mention none of them.
The reason is usually that they are internal and cannot be attached, so people conclude they cannot be cited. That is a mistake: a resume cites work all the time without linking it, and a document is easier to describe convincingly than most systems are.
What a written artefact evidences that a bullet cannot
That you can hold a problem in prose. Anyone reviewing a senior candidate wants to know whether you can explain a system to someone who doesn’t already understand it. Writing is the only direct evidence of that, and it correlates with almost everything else the job requires.
That your influence had a mechanism. The staff-level resume problem is that influence work has no natural unit. A document is a unit. “Other teams changed what they were doing” is a claim; “wrote the schema-compatibility RFC that four teams’ producers now conform to” is a claim with an object attached to it.
That you were in the room when the decision was made. Design documents are written by the person who owned the decision, or at least by the person who framed it. Citing one is a scope statement that doesn’t need the word “led” in it.
That you finished things. Documents get abandoned constantly. One that was written, reviewed, argued over, and adopted is evidence of follow-through, which is a trait most resumes assert and almost none demonstrate.
The four kinds worth citing, and the form each takes
A design document or RFC. Cite the decision, not the document. The document is the artefact; the decision is the content.
Illustration: Wrote the RFC that settled how services would emit domain events — one topic per aggregate, schema registry with compatibility checks in CI — after a review that rejected an initial per-consumer-topic proposal.
The rejected alternative is what makes this a real design document rather than a write-up.
A postmortem. The valuable part is never the incident; it is the follow-up work and whether it happened. An incident report that produced two mechanical changes is a much stronger line than one that produced action items.
Illustration: Ran the postmortem for a multi-hour outage caused by a cache stampede after a deploy, and implemented the two changes that came out of it: request coalescing at the cache layer, and a warm-up step in the deploy sequence.
Note the honest scope: you ran the review and you did the follow-up. If someone else did the follow-up, say so — “wrote the postmortem; the coalescing work was picked up by the platform team” is entirely respectable and instantly credible.
A standard, convention, or guideline. The thing to name is the class of problem that stopped occurring, and the adoption, which is the part that was actually hard.
Illustration: Wrote the error-handling convention for the service layer and got it retrofitted across the existing estate — errors now carry a stable code and a retryable flag, which is what let the client libraries stop guessing from status codes.
A migration or upgrade guide. Documents written so other engineers could do something you couldn’t do for them. These are frequently the highest-leverage writing an engineer does and they never appear on resumes because they don’t feel like achievements.
How to reference one without attaching it
Most of these documents are internal and always will be. Four workable approaches, in rough order of preference.
Describe it in a bullet and don’t offer a link at all. This is the default and it is fine. Nobody expects an internal RFC to be attached, and describing its content specifically enough is what makes it credible. A resume asserts unverifiable things on every line; a document is no different.
Name the artefact type explicitly. “Wrote the RFC”, “wrote the postmortem”, “authored the standard” all carry information about the process you were operating in — an organisation with RFCs and postmortems is a particular kind of place, and saying the word signals that you have worked in one.
Offer a redacted version on request. One clause is enough: design documents available on request (redacted). Only write that if you have actually prepared one, and prepare it carefully: no customer names, no internal hostnames, no unreleased product detail, no security specifics, nothing your employment agreement covers. If in doubt, rewrite it as a generic version of the same problem rather than redacting the original.
Write a public version of the same thinking. Not the document — the reasoning. A public write-up of a class of problem you’ve solved is the only fully linkable option and it works better than any of the above. That’s the subject of a personal site that earns the link.
What does not work is a link to a private repository, a document behind a corporate login, or a folder you’d have to grant access to. A reviewer will click once, fail, and move on.
Where they go on the page
Inside the experience bullets, in almost every case. A separate “Publications” section is right for papers and conference talks and wrong for internal documents — it inflates them and separates them from the work they belong to.
The exception is if writing is unusually central to your case: a developer-advocacy role, a documentation-heavy platform role, or a staff application where two or three artefacts are your strongest evidence. Then a short block works, and the selected-work block format handles it well — one document, its context, the disagreement, the outcome.
Public work is different: conference talks, published papers, and a widely-read technical blog are all worth their own line, because they are checkable and because they carry a signal about your standing that internal documents cannot.
Four ways to get this wrong
Claiming a committee’s document. Design documents frequently have several authors and a review process that changed them substantially. If you wrote the first draft and three people rewrote half of it, “wrote” is a stretch. “Drafted and drove” is accurate and reads better anyway, because driving is the harder part.
Citing the document instead of the outcome. “Authored twelve design documents” is a productivity metric for a job nobody has. One document with a consequence beats a count every time.
Citing a document that was ignored. Be careful here — a rejected design is not automatically a bad line, and a proposal that lost for good reasons can be an excellent one if you say what you learned. But a document nobody read, presented as impact, will not survive the question “and what changed as a result?”
Overloading the word “architected”. It is the verb people reach for when they wrote a document, and it invites exactly the scrutiny the document would have withstood. “Wrote”, “designed”, “proposed”, and “argued for” are all more specific and none of them sound like a job title.
The reason this is worth the effort
Technical writing is one of the few genuinely scarce skills in engineering, and it is invisible on a standard resume. An engineer who can write a document that changes a decision is more valuable than one who can only implement decisions, and that gap widens with seniority.
If you have written those documents, put them on the page with their consequences. If you haven’t, the next design decision on your team is an opportunity to produce one — and it will be the easiest strong line you ever add.