- The Routing Intent by Leonardo Furtado
- Posts
- The Silent Meetings, The Sharp Questions, and the Writing Culture That Defines Success at FAANG
The Silent Meetings, The Sharp Questions, and the Writing Culture That Defines Success at FAANG
Inside the Meeting Rooms of FAANG: Where Ideas Are Written, Read in Silence, and Challenged Relentlessly

Hey, it’s me again, following up on my most recent post about what it’s really like to work as a Network Engineer at a FAANG-level company.
If you haven’t read my previous two posts yet, I highly recommend starting there. They lay the groundwork for what we’ll cover next, particularly around hyperscale automation, software-centric thinking, and operational excellence.
Today, I want to share something different.
Not code. Not topology. Not tools.
Let’s talk about something far more revealing: how communication works inside these organizations.
And specifically, I want to show you what it looks like inside Amazon-style meetings, which are uniquely structured and serve as one of the company’s most powerful drivers of clarity, innovation, and accountability.
Maybe you're wondering, as if you're asking me directly, why this kind of post is useful? I think more technical content is more helpful to me.
I'd suggest you think again.
If you want to succeed as a top-notch network engineer, listen to me: THIS is precisely the kind of post that can teach you exactly what you need to learn to excel in your career as a network engineer!
At the end of this article, I share useful and actionable tips to help you get started with the concepts you've learned here.
Forget Slides. Bring Documents.
First things first:
PowerPoint is banned. Full stop.
If you show up to a meeting with slides at Amazon, you’re not just breaking a norm; you’re showing you don’t understand how leadership teams operate.
Instead, meetings begin with a silent reading session, typically lasting anywhere between 25 to 35 minutes.
No one speaks.
Everyone reads, together, in silence, the written narrative document that you, the owner of the idea, have prepared in advance.
This might feel unusual at first. But here’s why it works:
It ensures everyone consumes the same information at the same time, in the same way, without distractions, and with full focus.
No context switching. No misinterpretation. No one pretending they "skimmed it last night."
At other companies, people are often too busy to admit if they've read the material before the meeting. Everyone pretends to know it all. That's why companies like Amazon approach it differently.
You don't need to do any prep work ahead of time, because it'll all be covered in the meeting. This way, you and everyone else are on the same page at the same time, discussing the same data and ideas.
What Makes or Breaks Your Document?
Writing inside FAANG, especially Amazon in this case, is not casual. There’s a deeply ingrained writing culture with expectations that extend far beyond grammar and structure.
Here’s what people expect from your document:
A clear, purpose-driven narrative
Well-structured sections with strong flow
Minimum verbosity: concise, but not shallow
Explicit identification of the problem or opportunity
Sound technical reasoning supported by business impact
Comprehensive data, metrics, graphs, and historical context
Clear options and trade-offs (not just a single proposed solution)
And if any of that is missing, trust me, you’ll hear about it. People will literally complain that you still don't understand how this unique working & writing culture works.
Then Comes the Fun Part: The Debate
After the silent reading concludes, the real conversation begins.
And here’s where many brilliant engineers stumble:
People will challenge your ideas. Often directly. Rarely softly. Always professionally.
This is not meant to belittle anyone. It’s a culture of intellectual honesty and constructive rigor.
If your assumptions are weak, someone will question them.
If your metrics are off, someone will ask for your source or calculations.
If your design only offers one path forward, someone will point out that you didn’t do your homework.
You are expected to defend your ideas. And not defensively but clearly, with grace and data.
This is not about being “right.” It’s about being thorough.

Subscribe to our premium content to read the rest.
Become a paying subscriber to get access to this post and other subscriber-only content. No fluff. No marketing slides. Just real engineering, deep insights, and the career momentum you’ve been looking for.
Already a paying subscriber? Sign In.
A subscription gets you:
- • ✅ Exclusive career tools and job prep guidance
- • ✅ Unfiltered breakdowns of protocols, automation, and architecture
- • ✅ Real-world lab scenarios and how to solve them
- • ✅ Hands-on deep dives with annotated configs and diagrams
- • ✅ Priority AMA access — ask me anything