Latest / The Tech Career Podcast with Fexingo: Engineering Jobs, Interviews, and FAANG Career Strategy / How FAANG Engineers Use Writing to Get Promoted Faster
Transcript
- Lucas: So there's this stat that's been floating around inside Amazon for years — engineers who write strong six-page narratives get promoted about one point six times faster than peers who don't. Now, correlation isn't causation, but it's not nothing either. Luna: One point six times — that's huge. But I've always wondered, is it the writing itself that drives promotion, or is writing just a proxy for clearer thinking? Lucas: That is exactly the question. And I think the answer is both. Writing forces you to clarify your logic in a way that whiteboarding or Slack threads just don't. But there's also a signaling effect — when you write well, senior leaders assume you think well. And in a promotion committee that sees fifty packets in an hour, that signal matters. Luna: Yeah, I can see that. A messy doc makes people question your reasoning even if the idea is solid. So what's the actual structure of a good engineering memo? Lucas: Let's use Amazon's PR/FAQ as a template, because it's probably the most famous internal writing ritual in tech. PR stands for press release — you write a hypothetical press release announcing your finished project. FAQ stands for frequently asked questions — you anticipate every objection a reader might have. The whole thing is limited to six pages, narrative format, no bullet points. Luna: No bullet points? That's brutal. I feel like every engineering doc I've ever seen relies on bullet lists. Lucas: Exactly. And that's the point — bullet points let you hide weak logic behind formatting. Narrative forces you to connect ideas with actual sentences. At Amazon, the first page of the press release needs to hook a VP who has thirty seconds. If they don't finish page one, the rest doesn't matter. Luna: So it's not just writing — it's storytelling with a clear customer benefit. Lucas: Right. And here's what most engineers get wrong: they start with the solution. They open with 'We will build a new caching layer' instead of starting with the customer problem. The best PR/FAQs start with a specific customer pain — 'Customers in Southeast Asia wait four seconds for checkout to load' — and only then introduce the solution. Luna: That makes sense. But let's be real — most engineers I know hate writing. They see it as a distraction from real work. Lucas: And that's exactly why writing is such a differentiator. If 80 percent of engineers avoid writing, then the 20 percent who invest in it stand out disproportionately. A senior director at Google once told me that the single biggest predictor of an engineer reaching staff level was the quality of their design docs. Not their coding speed, not their system design skills — their ability to explain complex tradeoffs in plain English. Luna: But how do you get better at something you're not naturally good at? Do you just write more docs? Lucas: Partly. But volume alone isn't enough — you need feedback loops. The best engineers I've seen treat writing like code: they ask for peer reviews on their docs before submitting them. They're specific — 'does the problem statement on page two make you care?' or 'is the decision rationale clear in section four?' They iterate based on that feedback. Luna: You know, this reminds me of something from my own career. I used to write these long, detailed docs that covered every edge case — and no one read them. My manager told me to cut from ten pages to three and start with the recommendation, not the analysis. That changed everything. Lucas: That's a classic mistake — engineers write like textbooks, building up to the conclusion. But senior readers want the conclusion first. They call it 'bottom-lining it.' If your recommendation is on page one, they can decide if they need to read the rest. If it's on page six, they've already mentally checked out. Luna: So structure matters as much as content. What about style? Should engineers try to sound smart? Lucas: God no. The best technical writing reads like a conversation with a smart colleague who respects your time. Short sentences. Active voice. Concrete examples. Jeff Bezos famously banned PowerPoint from Amazon executive meetings and mandated narrative memos — but he also said that the memos should be written in everyday language, not corporate-speak. Luna: That's refreshing. I've seen way too many docs with phrases like 'leverage synergistic capabilities' — which means nothing. Lucas: Exactly. So let me give you a practical framework. When you sit down to write a design doc or a promotion packet, structure it like this: one — state the problem in one sentence. Two — state your recommendation in one sentence. Three — provide the key evidence, no more than three points. Four — address the top two objections. Five — end with a clear ask. That's it. Luna: That's almost like a pitch deck but in prose. Does this apply to performance reviews too? Lucas: Absolutely. In fact, promotion packets are the highest-stakes writing most engineers ever do. And the same rules apply. Don't list every project you touched — pick the two or three with the biggest impact, and for each one, tell the story: what was the problem, what did you do, what was the measurable result, and why was it hard. That last part — why it was hard — is where most engineers fall short. Luna: Because they assume the reviewer knows the context. But the reviewer doesn't. You have to spell out why this was technically or organizationally difficult. Lucas: Right. And use numbers. 'Improved latency by 40 percent' is good. 'Reduced p99 latency from 200 milliseconds to 120 milliseconds, saving an estimated 50 engineering hours per week in on-call' is better. Specificity builds credibility. Luna: I want to circle back to that stat about 1.6 times faster promotion. Is that really about writing quality, or is it that engineers who write well also tend to work on higher-visibility projects? Lucas: That's a fair point, and I think there's some selection bias. But the data from internal Amazon studies controlled for project scope and still found a significant correlation. The theory is that writing well makes your work visible to people who sit above your org chart. A great project that's documented poorly might never get noticed by a director three levels up. A good project documented brilliantly can get you a sponsor. Luna: So writing is essentially a leverage tool for your technical work. Lucas: Exactly. And here's the thing — this is a skill you can practice without any special tools. You don't need a promotion cycle to start writing better. You can write a one-page analysis of a system design decision for your team's wiki tomorrow. You can volunteer to write the weekly team update. You can rewrite a confusing doc you inherited just to clarify your own thinking. Luna: If today's conversation gave you something you can use, consider supporting the show at buy me a coffee dot com slash fexingo. It's a small way to keep this ad-free and focused on what works. Lucas: Yeah, listener support makes a real difference. Now back to the framework — one thing I want to emphasize is that writing is not about being literary. It's about being clear. The best engineer-writers I know use short words, short sentences, and concrete nouns. They avoid jargon unless it's absolutely necessary, and when they use it, they define it. Luna: So an example: instead of 'we will optimize the data pipeline to improve throughput,' you'd write 'we will reduce the time it takes to move data from source to dashboard from two hours to ten minutes.' Lucas: Exactly. The second version is specific, measurable, and meaningful to someone who doesn't live in your codebase. And that's the test — would an engineer in a completely different part of the company understand the problem and the solution after reading your doc? If not, revise. Luna: Let's talk about feedback. How do you get honest feedback on your writing without annoying your teammates? Lucas: Make it easy for them. Send a doc with a specific question: 'I'm most unsure about the tradeoff section starting on page three — does it cover the right alternatives?' Or 'The implementation plan on page five feels too detailed — should I cut it?' When you ask a pointed question, you get a pointed answer. When you just say 'let me know what you think,' you get silence. Luna: Also, timing matters. Don't send a doc on Friday afternoon and expect feedback on Monday morning. Lucas: Right. Give people at least three business days. And if you can, schedule a thirty-minute doc review meeting where you walk through it together. That's often more productive than async comments. Luna: I've seen some engineers use a technique called 'reverse outline' where they ask someone to read the doc and summarize it back in their own words. That quickly reveals if the structure is clear. Lucas: That's a great tactic. And it's low effort for the reviewer. Now, let's talk about one more thing: the 'write-only' culture at some companies. At Amazon, writing is so central that even a two-sentence email can take an hour to polish. That's extreme, but there's a lesson — the medium forces discipline. If you can't explain an idea in one page of clear prose, you might not understand it well enough to build it. Luna: But isn't there a risk of over-investing in writing at the expense of actual engineering output? Lucas: There is. You don't want to spend three days polishing a doc when the feature needs to ship next week. The key is proportionality. A high-risk, high-visibility project deserves a thorough design doc. A small bug fix might just need a few lines in a ticket. The best engineers calibrate — they know when to write a full memo and when to send a two-line Slack message. Luna: So it's a judgment call. And that judgment itself is a skill that gets recognized at promotion time. Lucas: Exactly. Promotions are about impact, not effort. Writing is just a vehicle for impact. If you can communicate complex ideas clearly, you can influence decisions, align teams, and get buy-in from leadership. That's what staff engineers do — they multiply their impact through communication. Luna: Let's bring this back to the listener. If someone is listening on their commute and wants to start improving their writing today, what's one concrete action? Lucas: Write a one-page doc about a decision you're facing right now. It could be a system design choice, a project prioritization, or even a personal career decision. Use the five-part structure I mentioned earlier. Show it to a colleague you trust. Ask them two questions: 'Is the problem clear?' and 'Do you agree with my recommendation?' That's it. You'll learn more from that one exercise than from reading ten blog posts about writing. Luna: And if you want to go deeper, there's a book called 'The Memo' by an ex-Amazon executive that breaks down the PR/FAQ method. Also, Google's internal 'Design Doc' template is widely available online. Lucas: Great resources. But the real growth happens when you write, get feedback, revise, and write again. It's a cycle. And over time, you build a reputation as someone whose docs are worth reading. That reputation is career currency. Luna: It's also a way to reduce meeting overhead. A well-written doc can replace a one-hour meeting. Lucas: Yes! That's another promotion signal — you respect everyone's time. When you send a doc instead of scheduling a meeting, leaders notice. They think 'this person is efficient and thoughtful.' That's exactly the kind of signal that sticks. Luna: Alright, let's wrap with a challenge. Pick one doc you've been meaning to write and commit to finishing it this week. Use the structure we discussed. Lucas: And if you write it, share it with someone. That's the accountability loop. I think we've given listeners a solid playbook here. Next episode, we'll talk about something slightly different — how to handle technical disagreements with your manager without damaging the relationship. That's a tough one. Luna: Looking forward to it. Thanks, Lucas. Lucas: Thanks, Luna. Talk to everyone next time.