Personal branding for developers: Why Writing Public RFCs Wins
Master personal branding for developers by writing public RFCs. Learn how technical writing builds career growth, visibility, and long-term professional equity.
I spent my first five years as an engineer believing that my GitHub contribution graph was the only resume I needed. If the code worked and the tests passed, I was doing my job. But when I eventually looked into Software engineering career growth: Breaking the Seniority Plateau, I realized that invisible work—no matter how high-quality—rarely translates into career mobility or leverage.
The most effective tool I’ve found for personal branding for developers isn't a flashy portfolio site or a high-frequency Twitter account. It’s the public RFC (Request for Comments). By documenting how I solve complex architectural problems before I write the first line of code, I’ve turned my internal engineering process into a public-facing asset.
Why Public RFCs Drive Career Growth
When you work in a vacuum, your value is limited to your current manager’s perception. When you write a public RFC, you’re broadcasting your problem-solving process to the entire industry. You aren't just showing that you can write a React component or configure a Kubernetes cluster; you’re showing that you understand trade-offs, edge cases, and business constraints.
I remember struggling to explain a major database migration plan to my team. We were stuck in a loop of "should we use Postgres or Mongo?" for about three days. I finally sat down and wrote a formal RFC. I outlined the latency requirements, the cost of data consistency, and the migration strategy. Because I had the document, the decision-making process became transparent, and the team aligned in hours rather than days.
That document didn't just solve a technical problem; it established me as a leader who could steer consensus. When you do this publicly—on a blog or a dedicated repository—you’re doing high-leverage technical writing that separates you from the crowd of developers who only respond to tickets.
The Anatomy of an Effective RFC
If you’re ready to start, keep it simple. You don’t need a fancy platform. A GitHub Gist or a Markdown file in a public repo works perfectly. Here’s the structure I use:
| Section | Purpose |
|---|---|
| Context | What problem are we solving and why now? |
| Trade-offs | What are the alternatives we discarded? |
| Implementation | The technical approach and tools involved. |
| Risks | Where will this likely break in production? |
When you treat your career growth as a system to be architected, you stop being a commodity. If you’re interested in how this mindset shifts your financial trajectory, I’ve written before about Money basics for developers: A guide to financial architecture. Your technical output is your primary currency; don’t let it lose value in private Jira tickets.
Building Professional Visibility Through Documentation
The hardest part of software engineering leadership is proving you can see around corners. Anyone can fix a bug. A leader explains why the bug occurred, how the system design allowed it, and how the new design prevents it.
Flow diagram: Identify Problem → Draft RFC; Draft RFC → Public Feedback; Public Feedback → Refine Strategy; Refine Strategy → Implementation; Implementation → Post-Mortem/Result
By documenting the process, you create a "paper trail" of your expertise. When a recruiter or a potential client looks at your history, they aren't guessing at your capabilities. They’re reading your thoughts on distributed systems, team dynamics, or language migration. This is the ultimate form of career insurance. Even if your current company goes through a round of layoffs, your public body of work remains.
A Few Caveats
Don't treat this like a blog post. An RFC is not a "how-to" tutorial; it’s a rigorous argument. If you’re writing about a tool, cite versions (e.g., "Why we moved from Terraform 0.12 to 1.5") and be honest about the pain points.
I once wrote an RFC for a migration that ended up failing in production because I underestimated the downtime for a specific legacy shard. I published a follow-up document detailing exactly where I went wrong. That level of transparency—owning the failure—did more for my reputation than any "perfect" project ever could.
If you’re still in the "order-taking" phase of your career, consider how Freelancing as a Strategic Consultant: Moving Beyond Order Taking requires this exact same skill set. You have to write to persuade, not just to inform.
I’m still refining my own process for this. Sometimes I spend too much time polishing the document when I should be shipping the code. It’s a balance, and I haven't quite mastered the timing yet. But I know this: the time spent writing is never wasted. It’s the only way to ensure your skills are as visible as your code.