Home
I say the same thing to both sides of the room.
Most advocacy is a one-way broadcast. I think that is the whole problem. A developer advocate worth trusting speaks the same technical truth to the developers using a product and to the team building it. That is not a compromise. That is the job.
I have been doing this for over a decade. I scaled a global developer community from 36,000 to more than 50,000 active members, delivered $2.1M per year in support cost deflection through self-service, and built the content, tooling, and feedback loops that made both of those things possible. The About page has the full story.
Advocacy is a feedback loop, not a megaphone.
Most companies hire a developer advocate to amplify their message. That is marketing and marketing is useful...but it is only half the function.
Developers are not passive recipients; they are investigators. Once an advocate is seen as a mouthpiece rather than a trusted voice, credibility is gone...and it doesn't come back.
The Dual Value Stream
| Product → Developer (The Truth) | Developer → Product (The Signal) |
|---|---|
| Honest Communication: Tutorials that reflect how the product actually behaves, flaws and all. | Structured Signal: Identifying friction, missing abstractions, and "sharp edges." |
| Documented Workarounds: If there is a wall, I find it and document the way through it before the user hits it. | Quantified Feedback: Delivering evidence-based advocacy to the team that can actually fix the code. |
| Outcome: A community that trusts you because you were right. | Outcome: A product that improves because you were vocal. |
Build first. Break it. Then write about both.
I do not write about code I have not run. This is a precondition for producing anything worth reading.
The Four-Step Workflow
- Build Dive into a product until I find its limits, hunting for hidden strengths just as much as sharp edges. The output is a real-world map, not a retelling of the README.
- Break The interesting information lives at the edges, at the moment where features don't play nice or the error message is "technically correct...but completely useless".
- Fix Finding the flaw is only half the work. The product team gets a fix strategy; the developers get a workaround. That is a complete feedback loop, not just a bug report.
- Write The content that gets shared isn't "how to do the thing". It's "here is the thing they didn't tell you, and how I got through it anyway".
"A developer advocate who tells developers what they want to hear is not
an advocate. They are a brochure."
The trust that makes this work is built on technical accuracy. Developers are an audience that is impossible to fool for long. Honesty about limitations isn't a risk to your company...it is the key thing that makes the developer advocacy function valuable.
If you are looking for technical depth over marketing performance
I am open to full-time roles, contracts, and fractional engagements, provided the product is one I can genuinely get behind. I do not provide enthusiasm on instruction. I provide communication built on technical understanding.
If that sounds like what you need, let's talk.