A developer advocate helps people make informed technical choices and build with a product. That means writing code, explaining decisions, teaching, and bringing developers’ experience into product work. My role connects those responsibilities across research, live workshops, technical writing, and conversations with practitioners.
At San José State University’s AI/ML Club, I spoke about inference through KV cache, continuous batching, quantization, and the balance between latency and throughput. In my CIO writing, I approached AI infrastructure through the cost questions a business leader needs to ask. Both are advocacy. The audience changes which part of the system I need to make clear.
Translate the decision, as well as the technology
My CIO opinion piece, The GPU bill is the new AWS bill, is an example of technical communication for decision-makers. It connects infrastructure choices with the economics of running AI. A developer integrating a model and a leader approving a deployment share an interest in cost, but they need different levels of explanation.
For an implementation discussion, I want to know the request volume, response-time target, and what a completed task looks like. For a budget discussion, I want to connect those same assumptions to a useful unit of work. A price per token becomes more meaningful when the team also understands how many calls the application makes to complete one task.
My perspective is that an advocate should help a person ask a better technical question. That question often outlasts the particular model or product release being discussed.
Choose the format that lets people act
A university talk creates room to explain a mechanism. A hackathon workshop gives people a chance to apply it immediately. At the AI Agents for Hire Hackathon at AWS Builder Loft, I ran a workshop and served on the judging panel. Those are different responsibilities within the same event: teaching provides a starting point, while judging asks a team to explain what its agent does and how it works.
I plan a technical session around the decision the audience should be able to make afterward. If the topic is inference, that might be choosing a deployment path. If it is an agent, it might be identifying the boundary between model output and application behavior. The demonstration earns its place when it makes that decision visible.
Build enough to explain the implementation
My academic-paper analysis project gives me a concrete way to explain retrieval-augmented generation. The project turns a defined collection of papers into a searchable resource and preserves source information for review. That lets me discuss document preparation, retrieval, and citation checking as separate engineering decisions.
When I share a project like this, I want another developer to see where a result came from. A demonstration can show the experience; a repository and a written explanation let them inspect the structure. I connect the two so the audience can move at its own pace.
Bring conversations back into the work
At an agents-in-production unconference, I led a breakout with practitioners working across several industries. The discussion surfaced questions about evaluation, context management, governance, and choosing tools. It gave me a different kind of input from a prepared talk: people described the decisions they were already making.
I see the advocate’s next step as turning those conversations into something a team can use. Capture the task and environment, identify the question, and connect it to the relevant product or documentation owner. My work has included documentation changes prompted by Discord questions. That is a practical connection between listening and improving the developer experience.
Give the work a useful measure
I choose evidence that matches the activity. A workshop can track whether participants completed the exercise. A guide can be tested by someone following it for the first time. A product-feedback conversation can track whether the team reproduced the issue and responded. Views and attendance describe reach; completed tasks and documented follow-up explain what happened after people arrived.
For someone considering this career, I suggest starting with one small integration. Build it, explain a decision, and help another person try it. Their questions will show you which part of advocacy you enjoy most.
Questions readers ask
Does a developer advocate write code?
Many technical advocacy roles involve building examples and integrations. The required depth depends on the product and position. In my work, engineering helps me explain the example with enough precision for someone else to explore it.
How is developer advocacy related to DevRel?
Developer advocacy is commonly part of a broader developer relations program. DevRel can also include community operations, documentation, partnerships, and program leadership. Companies organize these responsibilities differently.
What is a useful first advocacy project?
Choose a small task, build an example, explain how it works, and invite someone to try it. Record the questions they ask and use them to improve the resource.
