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.
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 I dive into a product until I find its limits. I hunt for the diamonds in the rough and the hidden strengths just as much as the sharp edges and the workarounds. This produces guides that don't just follow the README. They provide a real-world map based on the technical truth of the tool.
- Break The interesting info lives at the edges. I’m hunting for 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. I find the path through the wall. 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.
I work with companies, not just for them.
I am interested in fractional developer advocacy for products that genuinely engage me. I don't provide enthusiasm on instruction. I provide communication based on technical understanding. If I work with a product, I am truly engaged by and interested in it.
The Distinction Matters:
- Independent Credibility: An advocate who chooses your product is worth more than one who has no choice.
- Technical Depth: A genuine instinct for where friction lives.
- Reliable Channel: When developers raise a concern, they know it reaches the right people internally.
If you are looking for technical depth over marketing performance, let's talk.