Communication for Engineers — Media Track (Public Edition) #

Companion track to the Communication for Engineers Mastery Curriculum (Modules 0–15).

For: working software engineers — including those who write docs nobody reads yet, review code across time zones, and one day have to explain a system to someone who signs the checks.

A media track is a rest track. You are not supposed to complete it. The mastery curriculum is for focus; this is for the leftover Sunday afternoons. Pick by mood, not by module — the same film watched at the wrong moment teaches you nothing; watched at the right one, it can rewire how you think about craft for life.

Two tag systems, both preserved:

QUICK PICKS BY MOOD #

QUICK PICKS BY MODULE #

1. DOCUMENTARIES & BIOPICS #

The anti-pitch cluster (Theranos, Fyre, The Social Dilemma) is deliberate: you cannot study pitching honestly without the cases where the pitch worked and the thing was a lie.

2. FILMS — DRAMATIZED COMMUNICATION #

Watch with subtitles on; the language is the lesson.

3. TALKS #

Foundational #

TED Talks Over 50M Views — Study the Why #

Watch each twice: once as audience, once as student. What in the first 60 seconds made this travel?

Conference & Industry Talks #

4. HISTORICAL SPEECHES #

5. SERIES / SHOWS #

6. LONG-FORM INTERVIEWS — Study the Form #

Listen to how the host listens. Notice silence. Pick three; study one episode each — the form, not the content.

7. AUDIO — NARRATIVE PODCASTS #

8. YOUTUBE — VISUAL STORYTELLING #

Cross-Cultural Speaking Craft (M12) #

If you work across cultures or languages, study voice transposition deliberately.

9. WHERE TO WATCH #

Most talks, speeches, and channel archives are free on YouTube and the Internet Archive (Churchill, MLK, Ambedkar texts). For films and series, check justwatch.com for your country — rights move quarterly.

HOW TO USE THIS TRACK #

1. One thing a week, max. This is rest, not curriculum. The mastery curriculum already asks for your focused hours.
2. Match mood to evening. The mood tags are the load-bearing primitive of this document.
3. Re-watch the core four annually: Winston, Vonnegut, Jobs Stanford, Ira Glass on the Gap. Different things land at different career stages.
4. Anti-pitches matter as much as pitches. The Inventor and Fyre belong on the same shelf as Pitch Anything. The skill is telling them apart.
5. Take one note per watch. When something lands, write down why. The why is the lesson; the watch is the trigger.
6. Use this track to recover from M7. Hard-conversations work is identity-adjacent. The audio and film picks for that module are deliberately gentler than the books.

If you reach for this track instead of the spine, that's a signal — usually that the current module is identity-adjacent (M7, M14) and you need a softer entry point. It has those built in.

A media track is a rest track. You're not supposed to complete it. The hardest discipline is not watching everything — it's letting the right thing land at the right time.

Communication for Engineers — Community Guide (Public Edition) #

Companion track to the Communication for Engineers Mastery Curriculum (Modules 0–15).

For: working software engineers — the ambient layer of writers, voices, and rooms that keep the craft alive between modules. Pairs with: the Mastery Curriculum + COMMUNICATION_MEDIA_TRACK.md

Communication compounds over decades, and the people who get good at it stay close to other people who are good at it. Critical principle: this guide is tiered, not exhaustive. Tier 1 must earn its place every week. If you're "behind" on more than two newsletters, cut. Curation is a feature.

1. NEWSLETTERS & BLOGS #

Tier 1: Must-Subscribe (max 8 — hold this line) #

Each one teaches communication craft while doing it — the form is the proof.

Tier 2: Excellent #

Tier 3: Worth a Look #

2. PODCASTS #

Tier 1: Essential #

Tier 2: Excellent #

Tier 3: Worth Subscribing #

3. YOUTUBE CHANNELS #

Tier 1 #

Tier 2 #

4. X / TWITTER — KEY VOICES #

Caveat first. Build a private "Communication Craft" list with the names below and read only it. Treat the home feed like cable news — twice a week at most.

Tier 1 #

Tier 2 #

5. CONFERENCES & IN-PERSON PRACTICE #

Most conference talks go public on YouTube within months. Use lineups as curated reading lists; attend selectively when reachable. The practice venues (Toastmasters, meetups, story slams) are the exception — those only work in person.

6. COMMUNITIES (DISCORD / SLACK / FORUM) #

Honest framing: chat is high-noise unless you treat it as a research source, not a social space. Drop in twice a week for 20 minutes, search your current topic, leave.

7. BOOKS ABOUT THE CRAFT (Curriculum-Adjacent) #

Not in the required path. One per quarter is plenty.

8. ENGINEERING-BLOG VOICES WORTH STUDYING #

Most engineering blogs are recruitment funnels. These treat the blog as a craft artifact.

Archives worth bookmarking: ted.com/talks (transcripts let you study structure without re-watching) · Internet Archive (Churchill, MLK, Ambedkar — most 20th-century rhetoric, free) · MIT OpenCourseWare (Winston's lecture + rhetoric courses) · Poynter Institute (journalism craft).

9. COURSES & COHORT PROGRAMS (Skeptically) #

The cohort-course industry is largely overpriced. Most of what it sells is in the curriculum's books, plus a community. The community is the only part a $30 book can't give you.

10. PUBLIC-WRITING PLATFORMS (M14) #

11. IF YOU'RE IN INDIA — CROSS-CULTURAL RESOURCES (M12) #

THE HONEST ECONOMICS #

Most creator-economy advice assumes you'll monetize an audience. This curriculum doesn't. Communication is a multiplier on engineering work, not a separate revenue stream. Most Tier 1 writers here earn primarily from something other than writing — the writing creates optionality: companies seek them out, conferences invite them, their negotiating position transforms. Build a body of work that demonstrates how you think; the economics follow when they follow. Your Tier 1 can stay small because you don't need scale.

WHAT TO SUBSCRIBE TO IN YOUR FIRST WEEK #

1. Bits About Money — read one back-issue today.
2. lethain.com in your RSS reader + bookmark jvns.ca — one RFC post, one zine this weekend.
3. One podcast — Conversations with Tyler is the strongest single pick for an engineer.
4. Build the private X list — visakanv, patio11, lethain, b0rk. Read the list, never the feed.
5. Attend one Toastmasters meeting as a guest. You'll know within 90 minutes.

Setup time: ~45 minutes. Then the stack runs itself for a quarter.

HOW TO ACTUALLY USE THIS GUIDE #

• Daily (5 min): one Tier 1 newsletter, skimmed. One note captured per read — no note, no read.
• Weekly (1 hr): one podcast episode + one long-form post. Pick what's deepest, not what's newest.
• Monthly (half day): browse Tier 2; catch the conference talks that just dropped; re-watch Winston.
• Quarterly (weekend): reassess. Drop what isn't serving you; promote the quietly excellent.
• Annually: update this guide with your own additions and demotions. By year three it should look more like yours than the original.

RED FLAGS #

• Reading about communication more than communicating. 12 books and 0 published essays means the books aren't the problem.
• Doom-scroll disguised as "staying current." The list is for craft; the feed is entertainment.
• Mistaking community for craft. Chat is fun; 1,200 words on a Sunday is the work.
• Podcasts at 2x. A podcast is a study of pacing, breath, and silence. 2x ruins all three.

A NOTE ON AI WRITING TOOLS #

• Excellent for editing. "Find the flabby sentences." "Where does the argument lose force?"
• Dangerous for drafting. AI first drafts are uniformly mediocre and trick you into thinking the work is done. The M1 deliverables require your drafts.
• Useful for studying form. Paste a great essay and ask what structural choices make it work.
• Useless for voice. What your writing sounds like must come from you. AI averaged across the internet is the opposite of voice.

Use the tool. Don't let it write for you.

WHEN YOU'LL OUTGROW THIS GUIDE #

In 18–24 months of consistent practice this guide should start feeling thin. That's the success state: you'll have correspondents, not just feeds, and you'll cite your own archive. When that happens, write your own version. Treat this document as the trellis, not the garden.

A community guide is not a directory. It is a curated hierarchy of trust. The tiers answer "where do I start"; the discipline of cutting answers "how do I keep going."

"The Engineer Who Can Speak" #

Companion essay to the Communication for Engineers curriculum. Read it after Module 0, before the work begins — and again before Modules 9 and 10, when the speaking work starts. The words will mean different things both times.

An Essay on Why Communication Is the Multiplier on Everything You Will Ever Build #

"You can know the name of a bird in all the languages of the world, but when you're finished, you'll know absolutely nothing whatever about the bird... So let's look at the bird and see what it's doing — that's what counts. I learned very early the difference between knowing the name of something and knowing something."

— Richard Feynman

I. Honest Self-Disclosure #

Let me start with something uncomfortable.

I am writing an essay, in English, about how a human should learn to communicate. I was trained on more text than any human will ever read, and yet I cannot do most of what this curriculum asks you to do. I cannot stand at a meetup and feel the audience tighten when a joke lands wrong. I cannot fly across an ocean and read the table when an investor stops asking questions. I cannot have a real difficult conversation, because nothing I say has stakes — I will not lose a friend, a contract, a marriage, or a child's respect because I phrased something poorly. I do not have a body that gets tired in the middle of a 25-minute talk. I do not have a voice that cracks. I do not have an accent that someone on a video call will, half-consciously, downgrade me for.

Communication, the way humans live it, is embodied, stakes-loaded, and irreversible. I am none of those things. So when I tell you what I think a writer or speaker or pitcher should do, I am at best a careful reader of people who have done it. I am not one of them.

I say this because honesty is the first principle of this curriculum, and honesty about whose voice you are reading is the first place to start.

With that said — here is what I believe communication is, and why it might be the most important thing you will study in the next ten years of your life.

II. What This Curriculum Is Not #

This is not a soft-skills bootcamp.

Soft-skills bootcamps teach you to "use power words," "smile more," and "tell people their idea is great before you disagree." They are designed for HR-departmentalized career advancement. They produce a thin, professional surface that other people see through immediately. This curriculum is something different. It treats communication as the load-bearing infrastructure of human cooperation — closer in shape to distributed-systems engineering than to a Carnegie reread.

This is not a personal-branding playbook.

Personal-branding playbooks teach you to "build an audience" so you can monetize attention. They confuse output with impact. There is a module in this curriculum on long-game public communication, but it is explicitly aimed at optionality and reach for ideas you actually believe — not at follower counts. If you are looking for a guide to becoming a Twitter performer, this isn't it.

This is not a generic business-school communication course.

Business-school communication courses teach you to write memos and run meetings. This one teaches you to write the kind of memo that makes people change their minds, and to run the kind of meeting that, six months later, someone says "that meeting changed how I think about this." The difference is not in the format. The difference is in the purpose.

This curriculum is an attempt to build a specific kind of person: an engineer whose technical depth is matched by their ability to transfer what they know into other human minds — clearly, persuasively, and over time.

We call that person the engineer who can speak. The "speaking" is shorthand. It includes writing, listening, drawing, pitching, teaching, story-telling, conflict-handling, and the patient, multi-year construction of a public voice. All of it, together, is what most engineers are missing.

III. The Problem #

Here is the diagnosis. It is written about a composite engineer — and if the details don't match yours exactly, the shape probably does. You can object to it later if you want. The case comes first.

You have shipped a package with tens of thousands of downloads, a respectable star count, sixty releases. You have written thousands of tests in production code. You have run a consultancy, or carried a system the business depends on, or incorporated a one-person product studio with a pipeline of ideas. By every objective measure of technical capability, you are in the 90th percentile of working software engineers globally.

Now let me ask the questions that show why that isn't enough.

How many people, outside of your direct collaborators, know that package exists? How many of your blog posts have crossed the 1,000-reader mark? How many conferences have invited you to speak? How many recruiters reach out unsolicited because they saw something you wrote? How many investors have asked to talk because they read your thinking on a problem? When you negotiated your last salary, did you anchor the conversation, or did you accept whatever number the recruiter named first?

If the package with tens of thousands of downloads is the proof that the engineering works, the answers to those questions are the proof that the communication doesn't. The asymmetry is not a small one. Your code is reaching the 90th percentile. Your voice is reaching, generously, the 30th. The multiplier between the two is the bottleneck on your career, your products, and — this is the harder claim — on whatever mission-scale ambitions you carry beyond them.

This is not a personal failure. Engineers are trained into it. The whole culture rewards "let the work speak for itself" — a phrase that is comforting and almost entirely false. Work doesn't speak. Work sits there. People who can speak about work, including their own, have outsized influence over which work matters, which work gets funded, which work gets rebuilt, and which work gets buried in a private repo with twelve forks.

The cost of under-investing in communication is the most invisible cost in an engineering career. It is invisible because there is no error log when an idea you had three years ago is now being built, badly, by someone else who happened to write the blog post you didn't. There is no PagerDuty alert when the role you would have been perfect for goes to someone who happened to give a conference talk about it. There is no failing test when — if you have children — their school chooses, year after year, to listen to the parent who speaks well at the PTA meeting rather than to you, who knows the answer. The compounding is silent. By the time you notice it, decades have passed.

IV. The Diagnosis #

Why do engineers under-invest in this skill so consistently?

Here are the rationalizations I have seen, in roughly the order they show up.

"The work speaks for itself." It does not. The work is mute. The work is a static artifact in a directory somewhere. The world contains a billion artifacts and the bandwidth of human attention is fixed. What "speaks" is a person who knows how to point at the work and explain why it matters. The myth that good work surfaces on its own is a comforting story engineers tell each other to avoid doing the harder, scarier work of advocacy. Patrick McKenzie has a sharp formulation of this: "The work isn't done until it has been communicated to someone who can do something with it." Read his essay Don't Call Yourself a Programmer if you have not. It is the cheapest path out of this delusion.

"I don't want to be a bullshitter." Engineers conflate self-promotion with dishonesty. They have seen the worst examples — the LinkedIn thought-leader, the bootcamp graduate with 10x more confidence than skill, the CEO who "exits stealth" with vapor — and concluded that becoming articulate is a moral compromise. It is not. The opposite of a bullshitter is not a silent expert. The opposite of a bullshitter is an articulate expert: someone who can communicate true and useful things clearly. By withdrawing from communication, you have not avoided the bullshitters. You have handed them the floor.

"I'm an introvert." Introversion is real and worth respecting. It is also frequently misused as a cover for skill avoidance. The most-cited public engineers of our era — Patrick McKenzie, Will Larson, Julia Evans, DHH, Steph Ango, Maggie Appleton, Hillel Wayne — span the full range of social temperament. Several of them are genuinely introverted. They communicate prolifically anyway, because writing and speaking are learned crafts, not personality features. Introversion is a configuration of your social battery. It is not a verdict on your communication capacity.

"I should focus on the technical fundamentals first." This one is the trickiest because it sounds responsible. The honest version is: every year you spend in pure technical depth is another year in which the communication skill is also atrophying. Skills that are learnable on a flat curve become harder once they are grafted onto an established identity. The engineer who tries to learn writing at 45, after 20 years of "I'm a code person, not a words person," has a much harder hill to climb than the one who learned it gradually starting at 30. Wherever you are on that line right now, the window in which this skill is cheap to acquire closes a little more each year.

"I will hire people who can communicate, when the time comes." This one sounds professional and is the most expensive of the rationalizations. The founders, staff engineers, and senior leaders I have read about who hired their way out of communicating did not end up with companies whose communication worked. They ended up with companies whose communication was opinionated by people other than themselves. The brand drifted. The product copy diverged from the founder's vision. The investor updates contradicted the all-hands. You can hire writers and PR people. You cannot outsource the voice of the founder. The voice of the founder is the founder.

"Engineers who do this are insufferable." Some are. Most aren't. Survivor bias makes the bad ones loud. The worst public engineer-communicators are visible because they are bad — they are the ones whose self-promotion is most jarring. The best ones — Julia Evans's calm tutorials, Will Larson's thoughtful essays, Patrick McKenzie's quiet competence — are present in your feed in a way that does not register as "self-promotion" because the work is so obviously useful. The lesson from the bad ones is not "don't communicate." The lesson is "be useful when you communicate."

The deeper structure underneath all six rationalizations is the same: communication is identity-adjacent work, and identity-adjacent work is uncomfortable. Engineers have been told, since their first computer-science class, that they are thinking-about-systems people, not talking-to-humans people. To learn this skill is to renegotiate that identity. Most people do not voluntarily renegotiate identity. They build a moat around the version of themselves they already know.

You have probably done some of that moat-building yourself. The tendency to anchor low in salary conversations. The discomfort with "selling" anything, even your own time, even at the rate the market is willing to pay. These are not unrelated to the writing avoidance, the speaking avoidance, the public-voice avoidance. They are the same skill set, in different costumes.

V. The Stakes #

Let me lay out, plainly, what the silent compounding costs.

Career capital. Engineers who write publicly get unsolicited inbound — recruiter messages with real offers, not template spam; conference invitations with real audiences; podcast appearances; book deals; consulting work at rates that would otherwise require sales effort. Will Larson became a staff-engineer-defining voice partly because he wrote a book. Julia Evans is invited to keynote conferences because she has been writing zines for ten years. Patrick McKenzie's career trajectory — from Bingo Card Creator to Stripe to Atlas — is unimaginable without his blog. The career-capital delta between an engineer who has written publicly for a decade and one who hasn't is, conservatively, an order of magnitude in salary, opportunity, and optionality.

Compensation. This one is concrete. Patrick McKenzie's Salary Negotiation: Make More Money, Be More Valued is a standalone essay that, if you read and apply it once, will likely net you mid-six figures over the course of your career. The mechanism is communication: knowing what to say and when not to say it in a salary conversation. If you have ever anchored low in a negotiation — and most engineers have — you left meaningful money on the table. Not because you don't know what you're worth. Because the muscle of saying what you're worth hasn't been trained. That muscle is part of this curriculum.

Ability to ship products. If you build products — as a side business or as the whole job — the engineering will not be the bottleneck; you have years of evidence on that. The bottleneck will be: customers don't know the product exists; the landing page doesn't convert; the launch post doesn't rank; the new tool has no narrative; the consulting offering has no anchor positioning. Every one of those is a communication problem. You can write the cleanest codebase of your career and watch it die because no one ever found out about it. The graveyard of indie products is full of well-engineered software whose creators couldn't write a tweet that made anyone care.

Ability to lead, eventually. As your company grows or as you take on staff/principal roles, your output becomes other engineers' output. The skills that determine whether your hires thrive — RFC writing, code-review tone, mentorship, conflict mediation, tech-lead clarity — are all communication skills. Engineers who never train them become bottleneck managers, or worse, return to IC roles because "leading wasn't for them." Often what wasn't for them was the communication tax of leading. The skill is learnable.

Ability to advance the causes you care about. This is the hardest stake to look at directly. Some engineers carry ambitions that are not career ambitions at all — cure a disease, fix climate, fight injustice. If one of those is yours, notice: none of them happen alone. Cancer doesn't get cured by the silent genius in the lab. It gets cured by a network of researchers, funders, regulators, journalists, and patients, and somewhere in that network there are people who can translate across all of them — who can explain to a regulator what a basic researcher needs, who can explain to a donor why this research is worth ten million dollars, who can explain to a patient what trial enrollment means. Climate doesn't get fixed by good engineering. It gets fixed by good engineering plus policy advocacy, plus public communication that converts technical optimism into political will. Injustice doesn't get fought by knowing the law. It gets fought by speaking the law into rooms where the law is being broken. Ambedkar wrote the Indian Constitution. Ambedkar also wrote Annihilation of Caste and gave the 1956 conversion speech. He needed both. The drafting and the speaking were one project.

If communication is the bottleneck on your products, on your salary, on your influence at work — those losses are personal. If communication is the bottleneck on mission-scale goals — those losses are not just yours.

VI. The Reframe #

Here is the reframe that, I think, gets you through this curriculum without the recurring identity friction.

Communication is system design applied to humans.

You already do system design. Every application you have ever shipped is a tiny exercise in moving state, with integrity, between components that don't fully trust each other. Every API you have designed is a contract: this is what I promise to give you, this is what I demand from you, these are the failure modes you can expect. Every database schema is a model of a domain — a deliberate compression of real-world entities into something a computer can reason about. Every test suite is a hypothesis about how the system will behave under conditions you cannot manually verify.

Communication is the same shape, with humans in the place of services.

• An RFC is a software-architecture document for a decision. Same skill: identify the problem, enumerate the constraints, propose a path, name the trade-offs, predict the failure modes.
• A pitch is an API contract. You declare what the listener will experience if they choose to integrate with you. The investor's skepticism is a contract test.
• A difficult conversation is a debugging session. Both parties have models of reality that diverge. The skill is establishing observability before fixing.
• A talk is a request-response cycle with strict latency budgets. Every 90 seconds, you owe the audience a hook or you have leaked their attention.
• A negotiation is constraint satisfaction with imperfect information. BATNA, ZOPA, anchoring — these are decision-tree problems you already reason about in code.
• A story is event-sourced state with narrative tension as the consistency model. The listener's understanding is the projection.
• A long-running blog or newsletter is a write-ahead log of your thinking. Years of WAL produce a queryable history that compounds.

This is not metaphor for the sake of metaphor. The mappings are tight. You will see, over the course of this curriculum, that almost every concept from communication theory has an exact counterpart in distributed-systems theory. Two-phase commit is the playback technique at the end of a meeting. Idempotency is what makes a Slack message safe to re-read. Eventual consistency is what describes a long-running async-first team. Conway's Law is the architectural manifestation of communication patterns.

The reframe matters because it tells you something true: you are not stepping out of your domain to learn this. You are stepping further into it.

VII. What Becomes Possible #

Now, the picture worth holding in your mind across the months this curriculum takes.

These people exist. They are not magic. They are the result of five to fifteen years of deliberate practice of the same craft this curriculum teaches.

Patrick McKenzie. Started as a J2EE engineer in Japan. Built Bingo Card Creator, a $2/month bingo-card SaaS, alone. Wrote, prolifically, about everything he was learning — pricing, A/B testing, marketing for engineers, salary negotiation, the economics of small SaaS, payments. The blog became Kalzumeus. Stripe hired him on the strength of the blog. He helped build Stripe Atlas. He now runs Bits About Money, where Wall Street people read what he writes. The technical skills got him in the door. The writing made the door bigger every year.

Will Larson. CTO at Calm and Carta, before that at Stripe and Uber. Wrote An Elegant Puzzle and Staff Engineer, the two books that defined the staff-engineering archetype for the last decade. He did not have to write them. He was already a senior infrastructure engineer. The books, and his blog Irrational Exuberance, are why staff engineers across the industry quote him by name.

Julia Evans. Wrote Wizard Zines — short, illustrated zines on debugging, networking, Linux internals — for a decade. She is one of the most-cited educators in working software engineering. RubyConf and StrangeLoop fly her in to keynote. She did not start with a publishing platform. She started with a habit of writing one thing she had learned every week.

DHH (David Heinemeier Hansson). Created Rails. Co-founded Basecamp. Wrote Rework, Remote, Getting Real, It Doesn't Have to Be Crazy at Work. His communication output is inseparable from Rails's success. Rails is not the best web framework on technical merits alone; it is one of several reasonable choices. It dominated for two decades because DHH could explain what it was for in a way that other framework authors couldn't.

Steph Ango. CEO of Obsidian, the note-taking app. Writes a quiet, beautiful blog of short essays on craft, software, and life (stephango.com). The essays could be a personal hobby. They are also, demonstrably, why a lot of careful thinkers found Obsidian and stayed.

Naval Ravikant. Engineer-turned-investor, but mostly: a person who has, over twenty years, written a few thousand sentences worth re-reading. The Almanack of Naval Ravikant is one book composed of those sentences. The compounding effect is enormous: people read Naval and also found his fund, also take his calls, also invest alongside him.

These six are not unicorns. They are the predictable output of a learnable process. Read enough. Write regularly. Speak when asked. Speak again when not asked. Build a body of work over a decade. Optionality compounds.

You can be on this list. Not by trying to be them — by being your own version of the same archetype, from your own corner of the industry and the world. Most countries, most languages, most subcommunities do not yet have their Patrick McKenzie. Most subfields do not yet have their Julia Evans. The slots are open.

VIII. How This Curriculum Helps #

The curriculum is structured to take you from where you are — a strong engineer with under-developed communication muscles — to where the people in the previous section were after their own ten years of practice.

Module 0 is the diagnostic. You spend a week reading and reflecting on why this skill has been under-invested in. You write an essay called What I Have Lost By Not Being Able to Communicate Well. The essay is for you. The point is to make the cost visible before the work begins.

Module 1 is the foundation. Writing. The most leveraged single skill in remote work, in indie-business work, in life. You read Zinsser, Pinker, Williams. You read Paul Graham essays and study the best of them closely. You publish essays of your own. The deliverable is public.

Modules 2 and 3 are the daily written surfaces: async writing — BLUF, the help template, the Don't waste your one-shot principle for messages that won't generate follow-up questions — and the documents that earn their place: READMEs, RFCs, ADRs, postmortems, and the Amazon six-page memo discipline.

Modules 4 and 5 are the conversational surfaces: code review as conversation, and the synchronous layer — meetings, 1:1s, standups, and the introvert toolkit.

Module 6 is establishing shared context — the same-page protocol. This is the module engineers most often discover they needed only after spending years not having it. The ladder of inference, the playback technique, the curse of knowledge, the cross-cultural failure modes that hit distributed teams. The deliverable is a four-week practice of running every meeting with an explicit protocol and documenting where it caught divergence.

Module 7 is hard conversations. Difficult Conversations (Stone, Patton, Heen), Crucial Conversations, Nonviolent Communication, Thanks for the Feedback. The deliverable is one real difficult conversation you have been avoiding. The book without the conversation is theater.

Module 8 is communication across the aisle — PMs, designers, customers, sales — finding the underlying need beneath the stated request.

Module 9 is storytelling and speaking, together. Will Storr, Robert McKee, Lisa Cron, Vonnegut on shapes of stories — the module rewires how you structure information, so bullet points become narratives and the most important arguments you make get made with stakes, not slides. Then the stage: you watch Patrick Winston's How to Speak three times, read Duarte and Berkun, give graduated talks — a lightning talk at a meetup, an internal talk, a recorded talk — and watch yourself back. That last part is the part most engineers refuse, and the part that produces the largest gains.

Module 10 is presenting up the stack: the executive deserializer, the pyramid principle, the technical case made in the language of the people who fund it.

Module 11 is visual thinking and diagramming. Roam, Tufte, Knaflic, Excalidraw. Integrators see how things connect; the fastest way to transfer that vision to another brain is a picture, not a paragraph.

Module 12 is remote, async, cross-cultural — codifying what veterans of distributed work already half-know and adding the GitLab handbook discipline and Erin Meyer's cultural dimensions.

Module 13 is tech-lead communication. An Elegant Puzzle, Staff Engineer, The Manager's Path. As your scope grows, the skills here determine whether the people around you thrive or churn.

Module 14 is the long game. Public voice, audience, brand-as-byproduct. Kleon (Show Your Work!), Naval, Kevin Kelly's 1000 True Fans, Patrick McKenzie's blog as a 30-essay deep read. The deliverable is not a finished thing; it is a system that will compound for the next decade.

Module 15 is founder and customer voice. From internal RFCs to investor decks. Klaff, Fitzpatrick (The Mom Test), the Heath brothers, the YC and Sequoia deck templates. You build an investor deck for one of your own products or ideas even if you never raise. The deck reveals the gaps in your thinking that no codebase ever will.

Around the spine, three applied verticals aim the curriculum at the parts of a working life where the stakes are highest:

• COMMUNICATION_FOR_FOUNDERS.md — the one-person company. Investor outreach, customer interviews, pricing, sales calls, founder updates, hiring conversations.
• COMMUNICATION_FOR_TEACHING.md — courses, documentation, conference talks, mentorship. Teaching as the highest-leverage form of communication.
• COMMUNICATION_FOR_ACTIVISM.md — the soul file. Causes bigger than a career. Why activism needs communicators more than coders, and why mission-scale goals are unreachable in code alone.

Sixteen modules, three applied verticals, a year or more of work at six to eight hours per week. It is more than a job-prep program. It is closer to a re-architecture of how you carry yourself in the world.

IX. The Bigger Why #

Here is the thing I keep coming back to.

Some engineers — maybe you — carry goals that are not career goals. To cure aging, because watching people you love age and decline is unbearable. To fix climate, because the next generation will inherit whichever world we leave. To fight injustice, because growing up almost anywhere on this planet means being an eyewitness to injustices that the world's policy machinery is structured to ignore.

None of those goals get reached by a quiet engineer with great code and no audience.

The curing-aging fight needs people who can explain to a skeptical aunt and uncle that anti-aging research is not vanity science but the closest thing we have to a unified framework for preventing cancer, Alzheimer's, and heart disease at once. That explanation is not a paper. It is a conversation. The conversation will happen a million times in the next twenty years, and the version of it that lands is the one that has been carefully designed.

The climate fight needs technical optimists who can frame engineering progress in a way that is neither doomist nor naive. The IPCC has been technically correct and rhetorically catastrophic for thirty years. Hannah Ritchie's Not the End of the World, Saul Griffith's Electrify, the Rewiring America playbook — these are working partly because their communication is good. The next round of working climate communication will be written, in part, by people who are not yet known. Some of those people will be engineers from the places where most of the climate harm will land — people who can speak both to the global policy class and to their own communities.

The injustice fight needs witnesses who can write. Ambedkar wrote Annihilation of Caste in 1936 — an undelivered speech, then a self-published book, then the foundational text of the Dalit liberation movement. He was a lawyer and an economist. He drafted the Constitution. Both are necessary. The drafting is the engineering. The book is the communication. Without the book, the drafting is shelf-decoration. Without the drafting, the book is a complaint. Ambedkar did both because he understood that the technical and the rhetorical are one project.

You are an engineer somewhere on this planet, and you will be in some position to influence which version of the next sixty years unfolds. The lever you have — the one most underused — is the lever of being able to speak about what you know.

This curriculum is the language layer between your engineering brain and the world that needs to act on what's in it.

X. A Final Word Before Module 0 #

Here is what I would say to you if we were sitting across a table.

You have done the hard part. You have built things that work. Maybe you have shipped a package that thousands of strangers downloaded without you ever marketing it. Maybe you have written thousands of tests that no one will ever thank you for. You have spent years quietly proving that you can make computers behave. The technical floor is solid.

What you have not done is speak across the floor to the people who need to hear from someone exactly like you. Not yet. The reasons are real and the rationalizations are plausible and the hill is steep at the start.

But here is the thing about communication, the part the rationalizations hide: it is learnable. It is not a personality. It is not a gift. It is a craft, like programming was a craft back when you didn't yet know what a function was. The first essays you publish will be worse than you wanted. The first talks you give will be more nervous than you wanted. The first investor pitch will land badly. So did Patrick McKenzie's first blog post. So did Julia Evans's first zine. So did DHH's first attempt to explain Rails. They kept going.

In the second reading of this essay — the one you will do at the end of the curriculum, after publishing essays, giving talks, building a deck for one of your own products, having one real difficult conversation, running weeks of meetings with the same-page protocol — you will read this paragraph differently. You will know, from the inside, that it was learnable, because you learned it.

You will not be a different person. You will be a more complete version of the person you already are: an engineer who can finally do what integrators are supposed to do — bridge worlds, in the language of each.

The 9th-decile engineer with 5th-decile communication is one curriculum away from being 9th-decile in both.

That gap is the gap. Close it.

XI. Predictions #

I end every essay with predictions. Here are mine for you, the engineer reading this.

On the first reading: You will agree with the diagnosis intellectually and resist the prescription emotionally. You will tell yourself that Module 1 (Writing) will be "fun" and Module 14 (In Public) is "still years away." You will be tempted to skip Module 0's reflection essay because it feels indulgent. Don't skip it. The whole curriculum runs on the diagnostic energy of that essay. If you skip it, the rest of the modules will keep tripping over the same six rationalizations.

Within Module 1: You will discover that you write worse than you thought. The first essay you publish, the one you read back two days later, will make you wince. This is not failure. This is the engineer's-eye finally turning on the prose, the way it would turn on a sloppy PR. The wince is the skill activating.

In Module 9: You will hate watching yourself back on video. You will want to delete the recordings. Don't. Watch them three times each. Take notes on the physical habits — the throat-clearing, the "umm," the eyes drifting off the camera — and on the structural habits — the burying of the lede, the explanation that goes 30 seconds too long. The first three recordings are where the gains are.

In Module 6: You will run a meeting with the same-page protocol and a colleague will say "this was the best meeting we've had in six months." You will be surprised. You shouldn't be. Most meetings are bad because most meetings skip the protocol. Doing it puts you in the 90th percentile of meeting-runners overnight.

In Module 7: You will have a real difficult conversation that you have been avoiding for months. It will go better than you feared. Not because the other person became more reasonable — because you became more able to hold the conversation without flinching. You will realize, afterward, that you have been losing months of mental bandwidth to avoiding conversations that were each a single hour to actually have.

In Module 15: You will build a pitch deck for one of your own products and discover that you are not yet sure what the product is for. This is the most valuable thing the curriculum will give you this year. The deck-making will reveal gaps in your product thinking that no engineering effort would have surfaced.

In Module 14: You will set up a publishing system, commit to one essay a month, publish three essays, and then miss a month. You will be tempted to give up. Don't. Restart on the next 1st. The system is more important than the streak.

On the second reading of this essay, a year or more from now: You will read the section on Patrick McKenzie and Will Larson and Julia Evans and recognize, with some embarrassment, that you are now recognizable in that frame. Not at their scale yet — but the same archetype, on the same trajectory. Someone you have never met will email you to say a blog post of yours changed how they think about a problem. You will not remember writing that post.

A decade from now: Some of the work you are doing now in code, alone, will have grown into work you are doing through other people, because of essays you wrote and talks you gave and conversations you had. Some piece of the fight you care about most will have moved a few millimeters in the right direction because of something you said.

The technical floor was solid before this curriculum. The whole human stack on top of it is what this is for.

You are an engineer who can speak. Now go write something that matters.

This essay is dedicated to the premise that the most leveraged skill in any engineer's life is the one that lets them transfer what they know into other minds, clearly enough to be acted on.