External voice: writing, speaking, OSS, brand
Status: drafted · Time: 35 min · Audience: staff-plus Outcome: Manage the personal-versus-company voice tension across writing, speaking, and OSS contributions.
Council members write, speak, and contribute to open source. Some do so prolifically; some occasionally; a few not at all. This chapter is for the moments when a Council member is deciding how to present themselves and the program externally, or is helping another senior engineer navigate the same decisions.
The chapter draws on Lara Hogan’s Demystifying Public Speaking (A Book Apart, 2016), Will Larson’s writing at lethain.com, Charity Majors’s writing at charity.wtf, GitHub’s publicly available Balanced Employee IP Agreement, and the editorial culture of engineering publications including Etsy Code as Craft, Cloudflare’s blog, GitHub Engineering, Stripe Press, and Increment magazine.
The literature on this subject has a known thin area. Most companies’ internal IP, NDA, and external-voice policies are confidential. GitHub’s Balanced Employee IP Agreement is the only clean public artefact. The chapter covers what the public literature provides and is honest about where it does not.
If you’re short on time
Section titled “If you’re short on time”External voice is high-leverage and structurally asymmetric. The company gets recruiting and brand value from a senior engineer’s external work; the engineer accumulates reputation that travels with them. Both can be true simultaneously and naming the asymmetry is healthier than hiding it. A written-and-spoken-and-OSS portfolio works best when the work is congruent with what the engineer is actually doing. Editorial standards beat marketing capture for engineering publications. IP and NDA frameworks should be explicit at the company level, and absent that, the engineer has to defend their own boundaries.
Why this matters at the Council level
Section titled “Why this matters at the Council level”Council members shape external perception of the program by their own external activity. A program with a visible senior-IC voice in the engineering commons is one that prospective hires want to join, that peers respect technically, and that stays connected to the broader practice. A program whose senior engineers do not write or speak externally drifts inward.
The Council also reviews and supports other engineers’ external work. Black Belt candidates and Layer 2 working-forum members often produce their first conference talks, blog posts, or OSS contributions during their senior-IC arc. The Council’s role is to support that work without directing it: review drafts, sponsor talk submissions, advocate for time and travel, and protect against the patterns that cause external work to land badly.
Four shapes of external work
Section titled “Four shapes of external work”Each is structurally different. Each requires a different posture from both the engineer and the Council.
Writing. Engineering blog posts, longer essays on the engineer’s own platform, contributions to publications like Increment. The writing reaches the largest audience in time-shifted form and stays accessible for years.
Speaking. Conference talks, podcast appearances, panels. Higher impact in the moment, lower long-tail audience. More demanding on the engineer’s time per unit of reach.
OSS contributions. Public code commits, library maintenance, contributions to projects the engineer or program depends on. Less visible than writing or speaking but technically substantive.
Brand. The engineer’s overall external presence: their public identity as an engineer, their reputation in the broader community, the body of work that their external activity produces over years.
The four overlap. A blog post can become a talk; a talk can become a podcast appearance; an OSS contribution can become the subject of a blog post. The shapes are not exclusive, but each carries its own considerations.
Writing
Section titled “Writing”The publicly visible engineering blogs from Etsy Code as Craft, Cloudflare, GitHub Engineering, Shopify Engineering, Square’s blog, and Stripe Press demonstrate what good engineering writing looks like at scale. The pattern is consistent: editorial standards beat marketing capture. The bar is that a post would be useful to a reader who does not work at the company.
For a Council member writing externally, three considerations:
Congruence with actual work. Larson is direct: writing about what you are not actually doing is worse than not writing. The reader can tell. The post that ages best is the one rooted in real work the writer was responsible for. Council members who write about platform decisions they helped shape, RFCs they sponsored, or mentoring patterns they have actually run produce work with staying power. Posts that synthesise from theory without the writer’s own work in the loop are weaker.
Time horizon. Larson’s lethain.com material is explicit: write at a level of generality that you can defend in two years, not just at the moment of writing. The program may change direction; specific tactical decisions may be revised. Write at the level of the underlying patterns and the post stays relevant.
Editorial line. When the writing appears on a company-affiliated channel, an editorial line distinguishes engineering writing from marketing copy. The Etsy Code as Craft archive is a clean example: the posts could appear without the Etsy brand and still be useful. The marketing-captured engineering blog (covered in failure modes below) loses its technical audience and becomes recruiting copy. Council members who contribute to a company-affiliated channel push back on marketing capture as part of the contribution.
Speaking
Section titled “Speaking”Hogan’s Demystifying Public Speaking is the most useful single reference. The book is explicit about the asymmetry: the company gets recruiting and brand value from a talk; the engineer gets reputation that travels with them. Hogan argues this is fine and should be made explicit, not hidden.
For a Council member speaking externally, four considerations:
Talk-to-deliverable congruence. Hogan’s strongest pattern: do not promise something the company will not actually let the engineer ship. A talk that previews architecture the company has not committed to, or describes practices the team is not actually running, fails the reader and damages the speaker’s credibility. The talk should describe work that has actually shipped or is genuinely in flight.
Time and travel support. The literature is consistent that talk preparation takes more time than it appears. A forty-minute conference talk represents twenty to forty hours of preparation including research, drafting, practice, and revisions. Travel adds calendar days. Council members negotiating talk acceptance should treat these costs as real and articulate them at the manager level.
Post-talk cycle. A talk that lands well produces follow-up: invitations to other conferences, podcast requests, blog posts riffing on the talk’s themes, and direct messages from listeners. Hogan covers managing this cycle. For Council members, the post-talk cycle is part of the cost of speaking; budgeting for it prevents the talk from consuming the next quarter.
Preparing the next cohort. The Council can support Black Belt candidates and Layer 2 members who are giving their first talk. Reviewing drafts, sitting in on practice runs, sponsoring talk submissions, and advocating for the time-and-travel budget all matter. The first talk for any speaker is harder than the next ten; mentor support reduces the difficulty.
OSS contributions
Section titled “OSS contributions”Open-source contribution by senior engineers is sometimes program-relevant (the engineer is contributing to a library the program depends on) and sometimes personal (the engineer maintains a project unrelated to the program’s work). Both are legitimate; the governance is different.
Program-relevant OSS. The engineer contributes to a library or project the program uses or depends on. The contribution improves the program’s posture: bugs fixed in upstream, features added, maintenance shared. The work is on the company’s time, and the company’s policies on OSS contribution apply.
Personal OSS. The engineer maintains projects unrelated to the program. The work is on the engineer’s time, and the IP carve-out (covered below) determines whether the company has any claim on the work.
GitHub’s Balanced Employee IP Agreement is the cleanest public artefact on this. The agreement explicitly carves out personal IP and OSS contributions from the company’s IP claims, with a small set of exceptions (work that uses company resources, work that competes directly). Most companies do not publish their equivalents; the GitHub agreement is the public reference for what a balanced policy looks like.
For Council members specifically, OSS contributions can be sponsored: the Council recommends company-supported time for engineers contributing to libraries the program depends on. This is a form of sponsorship as covered in C.4: advocating in rooms the contributor is not in for the contributor’s work to be recognised.
The accumulating consequence of writing, speaking, and OSS contributions over years. A senior engineer’s brand is their identity as a technical thinker in the broader community. It travels with them across employers and outlasts any specific program.
Two perspectives in the literature, and they disagree.
Hogan’s perspective. The company-versus-personal-voice distinction should be managed with explicit policy from the company. The engineer should know what is allowed, what requires review, and what is unequivocally personal. The company writes the policy; the engineer operates within it.
Charity Majors’s perspective. The engineer must defend their own boundaries because companies will not write the policy that protects them. By the time the company writes the policy, it has been shaped by the company’s interests. Majors’s writing at charity.wtf is direct on this; the senior engineer’s brand is theirs and they have to act like it.
Both are right at different career stages and in different organisational shapes. Junior senior engineers benefit from clear company policy because they do not yet have the political capital to negotiate exceptions. Distinguished engineers eventually carry their own brand and the company’s policy is a baseline, not a ceiling.
For Council members helping other engineers navigate this, the framing matters. Recommending the company-policy approach to a Black Belt candidate who is building their first external presence is different from recommending it to a Distinguished engineer with a substantial public following. The Council’s mentoring (per C.4) accommodates this gradient.
What governance applies
Section titled “What governance applies”Honest area: the public literature is thin. Most company-level external-voice policies are confidential. GitHub’s Balanced Employee IP Agreement is the only clean public artefact. Stripe, Shopify, Square, Atlassian, and Cloudflare all clearly have policies; none have published them.
What the chapter can responsibly say:
- The program should have a written external-voice policy. Without one, engineers do not know what is allowed and either over-self-censor or get surprised. The Council can recommend such a policy to engineering leadership through the leadership liaison; the Council does not write or own the policy itself.
- The policy should distinguish program-relevant external work (which uses company time and may surface program details) from personal external work (which uses the engineer’s time and is the engineer’s own). GitHub’s Balanced Employee IP Agreement is the public model.
- Pre-publication review for program-relevant work should be fast and minimal. Cloudflare and Shopify ship engineering posts at a cadence that requires this; a slow review process kills momentum and the publication degrades.
- NDA and IP boundaries are where confidential program details live. Engineers writing externally should know what is on the public side of the line and what is on the confidential side. The line is not always obvious; the company’s policy should clarify it.
What the chapter cannot responsibly say is what the policy should specifically contain. That is a program-level decision, informed by the program’s regulatory context, its competitive posture, and its engineering culture. The Council can advise; the policy itself is owned elsewhere.
Worked example — a representative shape
Section titled “Worked example — a representative shape”A Council member is approached by a Black Belt candidate who wants to give their first conference talk on a skill pack they shipped during their boss-fight embed.
The Council member’s framing conversation. Is the talk congruent with what you actually did? Yes. Does the talk reveal anything the company has not committed to publicly? No, the skill pack is on the public marketplace; the talk describes what is already visible. Have you cleared time and travel with your manager? In progress. Have you done a practice run? Not yet.
The Council member’s support. Reviews the draft outline, attends a practice run, helps the candidate refine the post-talk Q&A preparation, sponsors the talk submission to the program’s external-talk pipeline, and connects the candidate with another senior engineer who has given a similar talk.
The candidate’s experience. The talk is accepted by the conference. The candidate gives it, lands well, and begins receiving follow-up requests. The candidate writes a blog post version of the talk on their own platform, which the program’s engineering blog cross-references. The candidate is now visible in the broader community in a way that supports their next-level development.
The Council’s reflection. At the next monthly session, the Council notes the candidate’s talk as a healthy pattern. The candidate is on track for Council invitation later in the year if the pattern continues. The talk is added to the program’s external-talk archive (covered below).
The pattern works because it was supported, not directed. The Council member helped the candidate prepare; the Council did not script the talk or claim authorship.
The external-talk archive
Section titled “The external-talk archive”A library of past talks, blog posts, and OSS contributions by senior contributors that the next cohort can study. The pattern is implicit in how staffeng.com itself is structured. Maintaining one for the program is a Council-shape contribution.
The archive contains: title, speaker or author, publication or venue, link to the work, year, and a one-line note on the work’s relationship to the program (was it about a program decision, was it personal, was it OSS contribution to a dependency, etc.). The archive is browsable; new senior engineers building their first external presence can find work that is similar in shape and learn from it.
The archive does not police what counts. A talk on AI infrastructure that the speaker gave on personal time appears in the archive. A blog post on org-shape questions that the writer published on their own site appears in the archive. The archive’s value is its breadth.
Common failure modes
Section titled “Common failure modes”Drawn from the literature.
The marketing-captured engineering blog. Once the marketing function takes editorial control, the technical audience leaves and the blog becomes recruiting copy. Discussed in passing by Majors and on lethain.com; visible in any number of engineering blogs that have died a quiet death after a marketing-led redesign. Fix: an editorial line held by senior engineers, not by marketing. The Council can sponsor or staff the editorial line; it does not have to own it personally.
The talk that promises something the company will not actually let the engineer ship. Hogan’s most-cited failure mode in Demystifying Public Speaking. The engineer commits publicly to architecture the company has not committed to internally. The talk lands; the work does not happen. The engineer’s credibility takes the hit. Fix: the congruence-with-actual-work check before submitting the talk.
The personal brand that the company resents. Majors’s writing at charity.wtf is direct on this. An engineer’s external presence outgrows their employer’s comfort. The relationship deteriorates. Anecdotal in the Kelsey Hightower / Google case; documented less specifically but widely. Fix: the engineer manages their boundaries; the company writes a policy that explicitly accommodates senior-engineer brand growth; both sides treat the asymmetry honestly.
The unpublished policy. The company has a policy on external voice but has not published it. Engineers do not know what is allowed; they over-self-censor or get surprised. Fix: the Council recommends publishing the policy through the leadership liaison.
The post that ages badly. The engineer wrote at the level of the moment rather than the underlying pattern. The program changed direction; the post is now embarrassing. Larson covers this in the writing-publicly material on lethain.com. Fix: write at a level of generality that the writer can defend in two years.
OSS contributions on company time without sponsorship. The engineer contributes to a library the program depends on, but the work is invisible in performance reviews because it is not associated with a project. The engineer’s other contributions are under-counted. Fix: program-relevant OSS contributions are sponsored by the Council and named in performance conversations; the recognition pattern from C.4 applies.
The closed senior-engineer publication. A blog or publication that only senior engineers contribute to becomes inaccessible to junior engineers who could write competently. The engineering commons narrows. Fix: the editorial line is technical, not seniority-based; junior engineers contribute to the publication when they have something to say.
Talk-as-recruiting-tool capture. A talk pipeline driven by recruiting needs (rather than what engineers want to talk about) produces talks that read as recruiting pitches. The technical audience disengages. Fix: the talk pipeline is owned by engineering, not by recruiting; recruiting can request talks but does not control their content.
What this is not
Section titled “What this is not”Not a substitute for the company’s external-voice policy. The chapter advises; the policy is owned by engineering leadership and (often) legal. A program that operates on this chapter alone has not done the policy work; the chapter’s purpose is to inform the policy work, not replace it.
Not a permission structure. Council members do not approve other engineers’ external work in any formal sense. The Council can sponsor, advocate, and support; it does not gate. A senior engineer who wants to write or speak externally goes through the company’s published policy, not the Council.
Not unlimited. Senior engineers’ external bandwidth is finite. A Council member who is publishing monthly, speaking quarterly, and maintaining significant OSS contributions has very little time for the Council’s other work. Recognising the trade-off is part of the Council’s planning.
Not a vanity project. External voice that is congruent with the engineer’s actual work compounds the engineer’s career. External voice that is not congruent reads as performance. The four-shapes section above addresses this; the engineer has to do the work they write about.
What you can say after this chapter
Section titled “What you can say after this chapter”“I understand the four shapes of external work and the asymmetry in why they matter. I can support other engineers building their external presence without directing it. I know what the public literature can responsibly say about IP and NDA and where the gap is. I can recommend that the program publish an external-voice policy and contribute to drafting it without writing it for the program.”
Where to go next
Section titled “Where to go next”C.6 covers the multi-year horizon: what the Council shapes that no quarterly artefact captures. The Council’s deliverable, across years, is the program’s posture across model generations, regulatory shifts, and platform-builder community changes. The chapter is the closer for the Council section.
Previous: ← C.4 Mentoring and sponsorship · Next: → C.6 The multi-year horizon
Further reading
- Lara Hogan, Demystifying Public Speaking (A Book Apart, 2016). The canonical engineer-side reference.
- Will Larson, lethain.com, posts on writing publicly as an engineer.
- Charity Majors, charity.wtf. Direct on personal-versus-company voice.
- GitHub Balanced Employee IP Agreement. The clean public IP carve-out artefact.
- Etsy Code as Craft, Cloudflare blog, Shopify Engineering, GitHub Engineering, Stripe Press, Increment magazine. Editorial-driven engineering publication exemplars.