Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Technical Writing Docs to Get Promoted
Transcript
- Lucas: There's this stat that's been rattling around in my head since I saw it a couple weeks ago. A survey of about 200 FAANG engineers — self-reported, but still — found that engineers who publish at least one major design doc per quarter are promoted to senior and staff levels at a rate about 1.6 times faster than engineers who don't. Luna: 1.6 times? That's not marginal. That's the difference between a two-year promo cycle and a three-year one. Lucas: Exactly. And the interesting thing is, the same survey showed that the engineers writing those docs weren't necessarily shipping more code. Some were shipping less. But they were being perceived as having more impact. Luna: So the docs are doing the heavy lifting for visibility, not the code. Lucas: Right. And that's really the core of today's episode. We talk a lot on this show about how to get noticed, how to get promoted. But we haven't spent much time on the specific mechanism of technical writing as a promotion lever. Not just documentation for the sake of it — but the kind of writing that promo committees actually read. Luna: So where do we start? Give me a concrete example of an engineer who used a doc to get promoted. Lucas: Sure. There's a case I heard from a friend at Google — let's call him Alex. He was a senior engineer on a storage team. He'd been at that level for about three years, solid work, good code reviews, but he was stuck. He wasn't getting the staff-level projects. Then he wrote a design doc for a new caching layer that would reduce latency for a major service. The doc was maybe 15 pages — not a novel, but well-structured. He circulated it, got feedback from three teams, revised it twice. Six months later, that doc became the blueprint for a project that saved the org about 2 million dollars in infrastructure costs. He was promoted to staff within a year. Luna: So the doc itself was the artifact that proved he could think at a higher level. Not just implement, but design. Lucas: Exactly. And that's the key distinction. Promo committees — especially at staff level — are looking for evidence of technical leadership. And a well-written design doc is one of the few artifacts that directly demonstrates that. It shows you can frame a problem, evaluate trade-offs, get buy-in from stakeholders, and articulate a solution that others can execute. Luna: But I think a lot of engineers hear this and think, 'I don't have time to write a 15-page doc. I'm already overwhelmed with tickets and bugs.' Lucas: That's the pushback I hear most often. And it's fair. The thing is, the doc doesn't have to be 15 pages. Some of the most effective promo docs I've seen are five to eight pages. They're focused. They have a clear problem statement, a proposed solution, and a discussion of alternatives. The length isn't the point. The clarity is. Luna: And the fact that you're taking the time to write it down forces you to think through the edges. You can't hand-wave in a doc the way you can in a hallway conversation. Lucas: Right. And there's a second-order effect I think is even more important. When you write a design doc and share it widely, you're essentially broadcasting your thinking to the entire org. People start to associate your name with that problem space. Your next project proposal gets taken more seriously. Your code reviews get more attention. It compounds. Luna: So how do you actually structure one of these docs so that a promo committee — which is not your team, people who don't know you — can read it and immediately see staff-level impact? Lucas: Great question. The canonical structure I've seen work at multiple companies is: context, problem statement, proposed solution, alternatives considered, success metrics, and a rollout plan. That's it. Six sections. But the critical part is the alternatives section. That's where you show you've done the homework. You explicitly say, 'We considered option A, but it had these downsides. Option B was more expensive. We chose option C because...'. Luna: That's the part that signals engineering judgment. It's not just that you have an answer — it's that you evaluated the landscape. Lucas: Exactly. And bonus points if you include data. Even rough estimates. 'This will reduce p99 latency by 30 percent based on our load tests.' Or 'This will save approximately 50 engineer-hours per quarter in manual operations.' Numbers make your doc concrete. Luna: I want to go back to something you said earlier about the survey. 1.6 times faster promotion rate. That's huge. But I wonder — is it causal, or is it that the kind of engineers who write docs are also more likely to seek out high-impact projects? Lucas: That's the classic correlation versus causation question. And you're right to raise it. The survey didn't control for that. But my instinct — and I think most engineering leaders I've talked to would agree — is that writing the doc itself creates a forcing function. It makes you clarify your thinking. It makes you socialize your ideas earlier. It makes you more visible. Even if you're not naturally the most ambitious engineer, writing a doc will push you toward higher-impact work. Luna: So it's a habit that leads to the outcome, not just a signal of pre-existing ambition. Lucas: Right. And I've seen it work that way multiple times. There's an engineer at Amazon I know — mid-level, considered solid but not a standout. He started writing one-pagers for every project he picked up. Just a page describing what he was doing and why. He shared them with his manager and skip. Within a year, he was being asked to lead a cross-team initiative. The one-pagers made him visible in a way that his Jira tickets never could. Luna: Let's talk about the practical side. If someone listening is a mid-level engineer — say L4 or L5 equivalent — and they want to start doing this, what's the first step? Lucas: First step: pick a problem you're already working on or one you've noticed that nobody else is tackling. It doesn't have to be huge. It could be a performance improvement, a refactor that would reduce tech debt, or a new feature that would unblock another team. Then write a one-page version of that doc. Just the problem and your proposed solution. Share it with your tech lead or a senior engineer you trust. Ask for feedback. Luna: And if they say the doc is unnecessary or the problem isn't important enough? Lucas: Then you've learned something valuable. Either the problem isn't as important as you thought, or you need to make a better case. Either way, you're better off knowing that before you invest weeks of work. But nine times out of ten, people will appreciate that you took the initiative. And even a rejected doc is a data point for your promo packet — it shows you were thinking strategically. Luna: That's a good reframe. It's not wasted effort even if the idea doesn't go anywhere. Lucas: Exactly. And the other thing I'd say is: don't overthink the formatting. Google Docs, Notion, a simple markdown file — whatever. The content matters more than the tool. And don't worry about making it perfect on the first pass. Write it, get feedback, iterate. The best design docs I've seen went through three or four major revisions. Luna: I want to push on one more thing. You mentioned that the promo committee reads these docs. But the committee sees a lot of docs. How do you make yours stand out? Lucas: Two things. First, a strong executive summary. The first paragraph should clearly state the problem, the proposed solution, and the impact in quantitative terms. If the committee only reads the first paragraph, they should get the gist. Second, use visuals. A simple architecture diagram or a before and after chart can make your doc much more memorable. But don't go overboard — one or two well-chosen diagrams are enough. Luna: And I'd add: write for the reader who is skimming. Use bold for key phrases, bullet points for lists, and clear headings. If someone can read the headings and understand the flow, you're in good shape. Lucas: Absolutely. And that's actually a skill in itself — writing for skimmability. It's not dumbing it down. It's respecting your reader's time. Luna: Speaking of respecting time — if today's conversation gave you something you can use, that's the link: buy me a coffee dot com slash fexingo. It's the smallest way to say this kind of deep-dive content is worth keeping ad-free. Lucas: Yeah, honestly, if this episode saves you even one stalled promo cycle, that's a win. And listener support is what lets us keep doing episodes like this without sponsors or fluff. Luna: So back to the docs. Lucas, you mentioned the alternatives section is critical. What's the biggest mistake engineers make when writing that part? Lucas: They treat it as an afterthought. They list one or two alternatives and quickly dismiss them without real analysis. The committee reads that and thinks, 'This person didn't seriously consider other approaches.' You want to show genuine trade-off thinking. For example, 'We considered using a message queue instead of a database trigger. The queue would give us better durability but adds 50 milliseconds of latency. For our use case, latency is more critical, so we chose the trigger.' That's a real trade-off. Luna: So you're demonstrating that you understand the system holistically, not just your piece of it. Lucas: Right. And that's exactly what staff-level thinking looks like. You're not just coding to a spec. You're making architectural decisions that affect reliability, cost, and developer velocity. Luna: Let's talk about the review cycle. How many reviewers should you aim for? Lucas: I'd say three to five. You want enough to get diverse perspectives, but not so many that you're stuck in an endless revision loop. Include your tech lead, a senior engineer from a different team, and someone from operations or product if relevant. The cross-team reviewer is key — it shows you're thinking about dependencies. Luna: And how do you handle conflicting feedback? If two reviewers disagree on the approach? Lucas: That's actually a gift. You can write an addendum or a follow-up section that says, 'Reviewer A suggested X, Reviewer B suggested Y. We chose X because...' This shows you can navigate disagreement and make a reasoned decision. That's leadership. Luna: I love that. It turns a conflict into a signal of maturity. Lucas: Exactly. And one more thing: after the doc is approved and the project ships, revisit the doc. Add a section on what actually happened versus what you predicted. This is called a 'postmortem' or 'retrospective' section. It shows you're willing to learn from outcomes. That's a powerful signal for the next promo cycle. Luna: So the doc becomes a living document, not just a one-time artifact. Lucas: Right. And over time, you build a portfolio of these docs. That portfolio becomes your promo packet. It's a concrete narrative of your impact. Much stronger than a manager writing a blurb about how you 'showed leadership'. Luna: Alright, I'm convinced. But let's be real — for an engineer who's not a native writer, starting this can feel daunting. What's the minimum viable doc? Lucas: Three sections: Problem, Solution, Impact. One page. Send it to one trusted reviewer. That's it. The goal is to build the habit. After a few of those, you'll naturally want to expand. The key is to start, not to be perfect. Luna: And that's the same advice I'd give for any career lever — small consistent actions beat occasional heroic efforts. Lucas: Exactly. And if you write one doc this quarter, you're already ahead of most engineers. The bar is surprisingly low. But the upside is huge. Luna: Alright, I think we've given people a solid playbook. Any final thoughts? Lucas: Just that writing is thinking. And if you want to be seen as a staff engineer, you have to think at a staff level. A design doc is the best way to prove that you do.