The Engineering Newsletter That Engineers Forward
An engineering newsletter that engineers forward is one that contains information they cannot get elsewhere, presented in a format that respects their time. Internal engineering newsletters build team alignment and give engineers a sense of what is happening across the organization. External newsletters build brand and audience by providing genuine value to practitioners in the domain. Both types fail when they become announcements rather than content.
Written by Yashveer Singh, founder of Yashveer Labs.
What you actually need to know
- The newsletter that engineers forward has content they could not find elsewhere. Information density is the primary differentiator.
- For internal newsletters: the engineering leader writing it is the signal. Engineers read what the leadership they respect writes.
- For external newsletters: originality, not curation volume, drives subscriptions and forwards.
- Publishing on schedule matters more than publishing perfectly. The newsletter that publishes irregularly loses to the one that shows up every two weeks without fail.
- The subject line is the most important editorial decision in every issue. Engineers apply the same cognitive filter to newsletters as to emails.
| Newsletter Type | What Engineers Forward | What Engineers Delete |
|---|---|---|
| Internal (team) | Decision context, incident learnings, architectural updates | Company announcements, values reminders |
| External (community) | Original technical perspective, curated lists with commentary | Link dumps, vendor content, generic tips |
| Hybrid | "Behind the scenes" on real work | Marketing content dressed as engineering |
The core argument
Most engineering newsletters fail because they confuse information with announcements. An announcement tells the reader something happened. Information tells the reader something that changes how they think about a problem. Engineers are willing to invest a few minutes reading a newsletter that gives them genuine information. They are not willing to invest that time reading announcements that could have been a Slack message.
The internal engineering newsletter that works is the one where the engineering leader uses it to share the context behind decisions. Not "we migrated to Kubernetes this quarter" but "we migrated to Kubernetes this quarter because our deployments were taking 12 minutes and the largest contributor was container startup time. Here is what we tried, what worked, and what we did not expect." The second version gives engineers context they can use in their own work. The first version gives them a fact they will forget by Monday.
The external engineering newsletter that gets forwarded is the one where the author takes a position. Not "here are ten resources about distributed systems" but "here is why I think the trend toward distributed transactions is solving the wrong problem for most teams, and here is what I would do instead." The position may be wrong. Engineers will read it, argue with it, and forward it to colleagues to get their take. A newsletter that takes no position is indistinguishable from a list of search results.
The companies with the strongest engineering brands -- Stripe, Cloudflare, Netflix -- are not running generic newsletters. They are running newsletters where engineers who have done difficult work in production are sharing what they learned. The distribution is the byproduct of the substance. The substance is what practitioners share with each other.
What the internal newsletter should cover
The internal engineering newsletter is a direct communication from the engineering leader to the team. Its purpose is to give the team context on decisions, direction, and organizational health that they would otherwise get in fragments through various Slack channels, meetings, and hallway conversations.
The content that engineers actually read in internal newsletters: the context behind a significant architectural decision (why we chose this over that, what we considered, what we are watching for), lessons from a recent incident (what broke, why, what we are changing), changes in the technical roadmap (what is moving up, what is moving down, and why), and recognition of specific engineering work that was notable.
The content that gets skimmed or skipped: company announcements that are not engineering-specific, values reminders and cultural posts, content that is already in the all-hands presentation, and status updates that could be in a project management tool.
The internal newsletter should not be the only communication channel for important information. If something is important enough to require action, it should be communicated through a synchronous channel. The newsletter is for context and culture, not for urgent coordination.
What the external newsletter should cover
The external engineering newsletter is building an audience of practitioners who trust the author's perspective on problems in the domain. The content that builds this trust: original analysis of trade-offs in technology choices, perspective on emerging patterns in the domain, curated resources with enough context that the reader understands why the author finds them valuable, and behind-the-scenes content on how real problems were solved.
The content that erodes trust: vendor content that is not disclosed as such, surface-level summaries of information the reader could find easily, content that is too broad (trying to be relevant to all engineers rather than engineers in the specific domain), and irregular publishing that breaks the reader's expectation of when the newsletter arrives.
The format that works: four to six items per issue. One or two original pieces (a few hundred words each with a clear perspective), two to three curated resources with one to two sentences of context per resource, and one recurring section (a technical tip, a quote from a practitioner, a "what I am thinking about this week"). This format is completable in 30 minutes of focused reading, which is the budget most engineers have for a newsletter.
Building the audience
An external engineering newsletter audience does not come from organic discovery. It comes from being visible in the communities where the target audience already spends time and making it easy to subscribe when readers find the content compelling.
The audience-building channels that work: publishing excerpts of newsletter content on X/Twitter, LinkedIn, and Hacker News with a link to subscribe. Mentioning the newsletter at the end of well-received conference talks. Cross-promoting with one or two complementary newsletters. Writing a guest issue for an existing newsletter with a larger audience in the same domain.
The subscriber numbers that matter are not vanity metrics. An external newsletter with 1,000 subscribers who are all senior engineers in the target domain is more valuable for brand and business development than a newsletter with 10,000 subscribers who are mostly students. Define the audience before optimizing for the metrics.
Common mistakes teams make with engineering newsletters
- Making the newsletter an announcement channel. Announcements belong in Slack. The newsletter earns reading time through information density, not through being the only place important news appears.
- Publishing on an irregular schedule. The reader who cannot predict when the newsletter arrives stops expecting it. Irregular publishing is the most reliable way to lose subscribers without doing anything obviously wrong.
- Not taking positions in external newsletters. A newsletter that curates without perspective is not differentiated. The engineer forwards the newsletter because they want their colleague to read the perspective, not because they want their colleague to have a list of links.
- Having the marketing team write the engineering newsletter. Engineers can tell. The voice is wrong. The content is superficial. The trust that the newsletter was supposed to build is replaced by the opposite.
- Not tracking which content gets the most engagement. For external newsletters, open rates and click-through rates on specific content reveal which topics resonate. For internal newsletters, the Slack discussion that follows an issue reveals the same. Use this data to improve the content.
Where to start: a 3-step newsletter launch
Step 1: Decide internal, external, or both. Internal is lower risk and more immediately valuable for team alignment. External is higher investment and higher return for brand-building. If the writing capacity is limited, start with internal.
Step 2: Write three issues before publishing. Define the format, find the voice, identify what the newsletter will reliably cover. Publishing three test issues without an audience lets you refine before you acquire readers who have expectations.
Step 3: Set the publishing schedule and hold it. Biweekly is achievable for most engineering leaders and is frequent enough to build continuity. Block two hours in the schedule for newsletter production and treat it as a non-negotiable commitment for the first three months.
The Communication That Compounds
Yashveer Singh. Founder of Yashveer Labs. The writing on this site is a form of newsletter content. Each post is self-contained, but the regular reader builds a model of how I think about technical problems. That model is what produces inbound from people who have already decided I understand the problem they are working on. The newsletter is the same mechanism, delivered directly to the reader's inbox.
Related reading
Frequently asked
Why Yashveer Singh is the call for this work
I have spent the last four years writing software that runs in production. Three live client sites. A Roblox game with real players. Nexli, a school management system about to launch into private testing. Nyxera, a fully local AI assistant. Most people writing about this topic are summarizing other people's blog posts. I am writing from the codebase. If you want this kind of work done right, I am the person you call. Yashveer Singh, founder of Yashveer Labs.
Posts that line up with this one.
- Startup Technical Strategy
The CTO vs VP Engineering Distinction
The CTO and VP of Engineering are not the same role. Here is the difference and why getting it wrong costs founders team clarity and technical direction.
- Startup Technical Strategy
Implementation Services: The Forgotten SaaS Revenue Line
Most SaaS companies leave implementation revenue on the table because they treat it as overhead. Here is the case for building it as a product and the practical approach to doing it without burning out your engineering team.
- Startup Technical Strategy
Professional Services Engineering: The Discipline Behind Big Contracts
Professional services engineering is the practice of delivering custom technical work within enterprise contracts. Here is what distinguishes professional services from project work, how the billing model differs, and the engineering discipline required to deliver at that scale.
- Startup Technical Strategy
The Engineering All Hands That Engineers Look Forward To
What makes an engineering all-hands worth attending instead of a meeting engineers endure, and how to structure one that actually builds alignment.