---
title: Home
url: 'https://www.rilhia.com/'
markdown: 'https://www.rilhia.com/index.md'
date: '2026-07-29'
description: '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…'
---

[](#) [Home](https://www.rilhia.com/) 

# Home

# I say the same thing to both sides of the room.

![HomePageImage](https://www.rilhia.com/user/pages/02.home/HomePageImage.png "HomePageImage")

> **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](https://www.rilhia.com/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

1. **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.
2. **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".
3. **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.
4. **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.

[**Get in Touch**](https://www.rilhia.com/contact)

---

## Navigation

- Previous: [About](https://www.rilhia.com/about.md)
- Next: [Articles](https://www.rilhia.com/articles.md)