Personal Branding Through Writing, Open Source, and Speaking

Personal branding is a phrase that makes many engineers uncomfortable. It sounds like self-promotion, like marketing, like something done by people who care more about appearing competent than being competent. This discomfort is worth examining, because it often prevents engineers from doing things that would make their work more visible, their ideas more influential, and their careers more resilient.

The reframe: personal branding is not performance. It is the practice of making your actual work and thinking legible to people who are not in the same room as you. In a field where opportunities are distributed heavily through reputation and referral, being invisible is a real career cost.

Why Visibility Matters

The job offer that comes without applying. The speaking invitation. The consulting inquiry. The promotion that happens faster than expected because the decision-makers had prior context on your work. These things do not happen to engineers who do excellent work in private.

They happen to engineers whose work is findable. Who have written something someone found useful. Who spoke at a conference and were remembered. Who contributed to an open source project that other engineers use.

None of this requires building an audience or performing expertise. It requires doing real work and documenting it in a way that others can find.

Writing: The Highest-Leverage Channel

Writing is the highest-leverage visibility channel for most engineers because it scales indefinitely and compounds over time. A post you write today is available five years from now. A talk you give reaches the people in the room; a post reaches anyone who searches for the topic.

What to write about:

The thing you just figured out. The moment after you solve a hard problem — a debugging session that took a week, an architecture decision that required comparing three options, an operational challenge you navigated — is the best time to write about it. Your memory of the confusion and the discovery is fresh. That confusion is exactly what a future engineer will feel. The post where you describe both the journey and the solution is more useful than the post where you explain the solution as if it were obvious.

The opinion you hold that is not obvious. "Here is why I think gRPC is the wrong choice for most startups" is more interesting to read than "Here is an introduction to gRPC." Opinions are scarcer than information; they create discussion and are remembered.

The thing you wish had existed when you were learning. If you struggled to find good documentation on something and eventually figured it out, you are in a better position than anyone to write the post that would have saved you time. Write for the version of yourself from six months ago.

Length: write until the point is made. Most technical posts are too long, not too short. The constraint to apply: would anything be lost if this section were removed? If no, remove it.

Open Source: Compounding Reputation

Contributing to open source builds reputation in a specific and durable way: through code that other engineers can read, use, and evaluate. Unlike a claim on a resume, an open source contribution is verifiable. Unlike a title, it says something specific about what you can do.

How to contribute without starting from zero:

Bug reports and documentation. The lowest-friction contribution is a well-researched bug report or a documentation improvement. These are welcome in almost every project and require no relationship with the maintainers.

Fix something you already use. The highest-value contributions happen when you encounter a bug or limitation in a tool you use regularly. You already have context on what the problem is and why it matters. A fix with context is more valuable than a fix without it.

Small, complete contributions over ambitious incomplete ones. A pull request that fixes one well-scoped issue and is easy to review ships and is attributed to you. A sprawling refactor that requires weeks of maintainer attention often does not.

Starting a project is also a valid path — but it has different economics. The recognition from a widely-used open source project is significant; the investment required to build something to that point is also significant. Start a project if you have a genuine problem you want to solve, not because visibility is the goal.

Speaking: The High-Trust Signal

Speaking at a meetup or conference creates a different type of recognition than writing. It is synchronous and embodied — the audience experiences your thinking in real time, which creates a stronger personal impression than text on a screen. It also signals willingness to be evaluated publicly, which many engineers avoid.

Starting: local meetups are the right starting point. The audience is small, the stakes are low, the feedback is fast, and the bar for submission is much lower than at major conferences. Giving five meetup talks builds the skill to give a conference talk well.

What to talk about: the same principle as writing. Talk about the thing you figured out that others have not yet. The production incident postmortem you can share. The architecture trade-off that was more nuanced than it looked. The tool you built and the unexpected lessons from building it.

A single well-delivered talk is typically more memorable to the people in the room than a blog post to the same number of readers. But writing reaches more people over time.

The Compound Effect

Writing, open source contributions, and speaking all compound. An engineer who writes one useful post per month for two years has twenty-four pieces of findable, attributable work. An engineer who gives one talk per quarter has built a visible track record of sharing knowledge. An engineer whose open source contributions are in tools others use has a reputation that precedes them in job searches and collaboration.

None of these require being an expert beyond what you already are. They require documenting and sharing work you are doing anyway.

The Practical Move This Week

Write down three things you have figured out in the last six months that you have not written about. Pick the one that would have been most useful to find when you were struggling with it. Start a draft — not a finished post, just the outline and the key insight. Finishing is a separate step.

---

Next: how to build genuine professional relationships without the networking behaviors that feel forced and transactional — especially for engineers who would rather work than network.