A Guide to Developer Advocacy

I've been a developer advocate at .txt for 8-9 months. A short time, but enough to learn a lot. I've given talks, I've written demos, blog posts, been on podcasts, recorded YouTube videos, etc.

I wrote this guide as an internal guide for my successor at .txt, but I figured it was worth cleaning it up a little bit for external use.

Developer relations, or developer advocacy, is a weird industry. Your role as a "devrel" is to essentially get developers to use whatever technical product your company provides. Importantly, you want users to succeed with that product. It sits at the intersection of engineering, education, and evangelism.

In a lot of ways, there's very few formal pathways to developer advocacy. I'm an academic – I did my PhD in financial economics, postdoc in econ at Stanford, etc. None of that teaches you specific developer relations skills.

This guide contains a few of my observations about what tends to work, though note that there are many, many styles of advocacy that will work better for you or your particular product. I'll try to update it as I go along, since I expect to remain in the industry.

What is advocacy for?

Advocacy is about getting people to use your product, and getting them to use it well.

Your role is also to get your company to adapt the product to meet user needs. Good developer advocates serve as tech support, “thought leaders” (whatever the fuck that is), product managers, and educators.

You’re also the public face for your company. You need to present a personality to your community, as well as make sure you help your company look good. You set the tone — do it carefully.

A common misconception about developer relations is that it is a marketing or sales role. Certainly this is a part of it, but developer relations is targeted at asking for something more specific from developers than money: time.

Time is valuable. Lots of companies have a ton of money but little time. Good developer relations engineers demonstrate that an investment of a developer's time is well worth the effort. They need to know that you respect their time, and that the thing they get from that investment is a significant step up from whatever they're doing right now.

Marketing and sales are often more external roles – you're not necessarily a user. Developers are an often insular community. They respond to reputation, community engagement, and trust. You need to play that role – be a member of the developer community, not just someone who plays pretend.

Why do businesses have developer relations?

Because it is a critical part of the business for a growing number of technical organizations.

You are trying to sell another API, SDK, programming language, DSL, framework, or tool. The market is crowded. Your company has to fight for every inch of developer mindshare, and you aren't going to get that for free.

Nobody is going to buy your thing if nobody even uses it, unless it is the greatest thing since sliced bread (most things are not that great, you can't beat bread).

For most companies that sell a technical solution, developer relations is more of a necessity than a luxury.

Providing inspiration

My approach to advocacy ended up being one of inspiring the imagination of users.

Most engineers are often focused on how to solve existing problems, and they are often not aware of/seeking alternative solutions to their problems.

For these users, you need to either show them how to solve their exact problem your way, while convincing them that it is easier, more flexible, and more powerful.

If you have some tact, you can solve a general problem that is “similar” to many user’s problems that is recognizably similar to an engineer’s problem such that they handle the cognitive work of adapting it to their use case.

In addition, some users may not even know that they have a problem that can be solved. Here, you have to be imaginative. Find a problem that you think someone might be experiencing, and then solve that. You don’t have to solve it well, just enough to highlight that there is a solution to this issue that was not previously on anyone’s radar.

Communicating

Of course, you cannot do any of this without communicating with the community. You do not know everything, and cannot simply assert user problems and solutions. Go talk to people. Read industry news. Stay a part of the wider conversation.

A few ways to do this:

• Use your own shit. This is rule #1 of advocacy. If you are not regularly building hobby stuff or demos on your own products, you will fail. You will be screaming into a void that you do not understand. This is non-negotiable. Advocates are the first users.

• Help out on GitHub issues. It’s very easy as an advocate to just not observe people’s technical issues and to allow the engineers on your team to handle them. However, this doesn’t help you experience your user’s suffering. Engage in their suffering, and help them out in the process.

• Talk to people on the internet. X sadly remains the best place for most AI discussion, though Bluesky has seen quite an uptick lately. Respond to people regularly. Ask questions. Be a reply guy. Try to cultivate an expertise so that people know who you are. LinkedIn gives you a lot of engagement, but you don’t learn much.

• Use discord. I hate discord. Many of us do. However, it is the top place for technical support and user discussion, despite our best wishes. Try to post what you’ve done, support other people’s work. You should try to engage with almost every message or conversation in the discord. If you can find a way to get people off discord onto a sane communication platform (forums, preferably Discourse), you will be happier.

• Be loud. There are many developer advocates who are quiet. This is not your job — your job is broadcasting as much as it is listening. Take what you learn from your communications channels and help people understand what you’ve learned. You need to be a voice. Logan Kilpatrick is great at this. He’s an authoritative, loud voice in pretty much every space he’s involved in, which is why he’s popular.

• Figure out how you best communicate. Not everyone is a good YouTuber, speaker, blogger, poster, etc. Find what’s best for you. I found that my expertise was in presenting. I’m weakest at YouTube because I don’t actually watch YouTube, so I’m not involved in the community. I’m an alright blogger but I tend to have a scattered writing style. Focus on what works best for you and try to encourage others to fill the gaps — many users are more than happy to record their own videos, blog posts, etc. Boost these as best as you can. Obviously try to expand your other skills, but focus on core competencies. Deepfates is a good example of someone who’s figured out his communication style — he’s always involved in some kind of conversation, and everyone knows what kind of stuff they’re going to hear from him (spoiler: it’s all weird shit)

• Be opinionated. Good advocates set the stage for conversations. Don’t let others set it for you. I think of Charles Frye as being a very good advocate for this reason — Charles is first to a conversation, and you are along for the ride.

Events

If you are an advocate in San Francisco or another geographic location, go to meetups, hackathons, and other events. These force people to understand your personality. If you work in AI in San Francisco, this has huge leverage — most of the other voices in the industry are at those same events.

Some event tips:

• Meet everyone. Don’t try to spend a lot of time in deep conversation with everyone during the mingling phase until you’ve gauged the room and figured out roughly who’s there. Try to chat a little, introduce yourself, learn a bit about the people. Once you’ve figured it out, you’ll probably have a good sense of who you’ll want to talk to more.

• Learn to disengage. A huge skill of events is leaving a conversation in a way that isn’t rude. You’re there working. You need to go gladhand and say hi. I will typically interrupt at reasonably spots to go get a drink, the bathroom, throw something away, etc. Typically you’ll run into someone else and you can start another conversation. You can also politely say “Lovely meeting you, I want to go say hi to X, chat again later?”

• Listen. People mostly want to talk about themselves. You should fight that urge. You are there to understand how people are working in the industry, what’s happening, who’s doing what, etc. This helps you understand what your product should look like and why. If you have something to sell, try to determine what the person’s problem is and whether you can sell it to them without pitching them. You are there to gather information, not pitch. Read the Mom Test.

• Walk up to people. People are actually pretty reserved. When you are at an event, it is your job to initiate conversations. Walk up to people. Typically, groups of people will clump together in small circles to chat, and these are extraordinarily easy to join. Just walk up, stand in the circle until people acknowledge you, and then ask for a quick round of introductions. You’re now in the conversation and can either step back and listen by saying “I don’t mean to interrupt, what were you talking about?”. You can also focus on specific people by saying “Oh that’s cool, tell me more!”. Try to engage with each person’s introduction briefly by connecting to something you learned about them, like their work or interests.

• Take notes immediately afterwards. My preferred approach was to record a voice memo. This helps you consolidate your understanding while it’s fresh, summarize general themes and conversations, and gets the information out of your head so you can send it to your team if need be.

• Time spent at events is time not spent developing. You can easily spend all your time at events in San Francisco. This will cause your skills to atrophy, and you'll stop producing meaningful content. Be cautious and keep a balance.

Burnout

Developer relations is a social job. I am an introvert. It is costly to go to events in terms of social energy, and this can bleed into the rest of your life.

• Do not go to every event. You need to be judicious, or you will burn out, and you will not have time to do the rest of your job.

• Focus on important events. Find events that are popular or focused on your specific product.

• You don't have to stay all night. You can leave. You don't have to close out the event if you want to go home and relax a bit.

• Remember that events are work. Just because they happen at night does not mean that they aren't work. When I was active on the event scene, I would tend to start working later in the morning to keep myself from working too many hours.

Outside of the event landscape:

• Maintain other hobbies. There's a good chance you're a hobbiest builder if you are a developer relations engineer. Be careful not to use your work product all the time, though you should do some hobby work. Play elsewhere too.

• Find friends that are not in the industry. This is a big one, especially in San Francisco. Find "normal people" who could not give less of a shit what you do. It will keep you sane.

Virtual Engagement

Not all advocacy happens in person. Virtual events, webinars, and online workshops have become increasingly important. The skills differ slightly - you need to be more energetic on camera, create more interactive moments, and fight harder for engagement when you can't read the room physically.

My approach to virtual events was to try to be less "canned". A lot of webinars are tightly scripted, but I tend to tune out for these.

My years in academia helped me see virtual events as places where you can engage with people from a wide variety of backgrounds and perspectives. Try to make something engaging, organic, and flexible. Try to get audience interaction if you can.

If you're using a demo, ask them for suggestions! Show them how their ideas can be demonstrated in a virtual demo.

Virtual events have the benefit of being screen-first in a way that live events are not. You can show a lot of code very easily, so try to take advantage of that.

This is perhaps the most important thing about virtual events.

ZOOM

IN

FARTHER

THAN

YOU

THINK

Seriously, nobody can read your screen. If you think the text is far too big, it is not big enough.

Bridging Users and Product

One of the most valuable aspects of developer advocacy is serving as the bridge between your users and your product team. You're uniquely positioned to understand both sides of this equation.

Product management is the art of guiding your product to be the best one it can be. This requires listening, finding use cases for your product, and helping to focus the company towards specific goals for the product.

Often, you are one of the very few people at your company who use the product the way that your users do — that makes you valuable. Share that information with your company.

A good advocate has a sense of how the product “feels”. It’s their job to get the company to improve that “feel”. A good company builds channels to support product input from advocates.

Try to collect pain points that you experience from using the product, and from users when they mention it.

You can be opinionated as well. Try to communicate areas of focus that the company should take — once you say it, it is the company’s role to decide whether to engage with your feedback.

Messaging

Try to tailor your message to your audience. All your talks, demos, examples, posts, etc. are a funnel towards a particular product or ideology. Choose a specific goal before you give any talk and make sure you structure your output around that goal.

Regarding talks specifically: be interesting. Most talks are extraordinarily boring. Capture people’s interests. Do not fill your slides with bullet points, do not show them the same thing over and over. Present a single, novel idea well, and then demonstrate how it connects to your broader point.

If you have a reputation for being a good speaker in the meetup or conference scene, you will get better speaking spots and more attendees.

Documentation

For most things, documentation is the product.

Don’t ignore it. Stay on top of the documentation. Ideally, this is a company-wide practice. It should not fall solely on your developer relations person. All pull requests should come with either a statement of why no documentation update is needed, or an update to the documentation.

If you don’t do this, your product will rapidly become bad. People will not want to use it. The second your docs are perceived as bad is the second people start losing interest in your product.

Metrics

I'm not the biggest pro at metrics, despite being an econometrician. I'll defer to articles like this one.

Brief overview, though. Metrics differ by what your product is.

• Cloud services. Active users is probably the best.

• Open-source. Downloads, contributors, stars, and issues opened (hopefully you close these issues)

• Community engagement, like Discord or Slack. Membership count, active users, and total messages.

Ultimately this is up to you and your team. Just figure out what you actually want people to do and choose a few metrics.

There are many, many devrels. Go talk to them. Grab coffee. Chat over twitter. Whatever.

The advantage of this is that many events, talks, and collaborations can be found through the developer relations community.

A big benefit specifically is joint projects. For example, .txt works a lot with Modal, and it's been excellent to have demos and showcases that use both products.

Joint partnerships on products allow you to share audiences, get buy in from the respective companies, and explore use cases for both products.

AI-specific stuff

I work in AI, and there are some thing that are specific to AI that you should be aware of.

• The industry moves fast. Pay attention. Try not to form too many preconceived notions about how things should work. Update your priors regularly. Things that seem to be fads might end up being a huge deal, like MCP. I didn’t expect that and it snuck up on me, because I did not take it seriously.

• There is lots of stupid stuff to ignore. The flip side of this is that there is a ton of chaff you have to be well-informed enough to ignore. I won’t dig into this too much, but rest assured that you must cultivate an eye for AI bullshit.

• Embrace agents. I did not particularly understand or believe in agentic systems until very recently. They are not a fad. They are extremely powerful tools that you need to understand. Experiment with LangChain, CrewAI, Letta, OpenAI swarm, etc. Agents are becoming increasingly common and will not stop doing so. Pay attention and understand theirHands-on demos are essential for building trust and understanding. Experiment with LangChain, CrewAI, Letta, OpenAI swarm, etc. Agents are becoming increasingly common and will not stop doing so. Pay attention and understand their strengths and limitations.

strengths and limitations.

• Do hands-on demos. People need to see your tool used. AI stuff is (a) cool and (b) sometimes hard to visualize – make it obvious what's happening and walk them through what you're seeing step by step. Be clear.

• Avoid hype, but not too much. Hype is annoying, and there's a lot of it in AI. Being too hype-y about AI. Do not say AI is going to cure cancer and contracts in 6 months or whatever, because people do not believe you and will distrust you. However, hype is also good – it taps into a powerful social movement that can foster excitement in what you're showing people. Show something that is cool but don't overpromise.

AI Subcultures

Be aware of the AI subcultures. AI has many different subcultures.

There are:

• Enterprise users who just need to solve problems, like content moderation, customer support, or internal support agents. These are LinkedIn folks who just need solutions. They have money and problems and want to talk to adults who can help. Be a grownup, understand their problem, propose at least one solution. Follow up on linkedin to see if they need help, or provide other suggestions if they come to you.

• Machine god people are often very concerned with artificial general intelligence/super intelligence, either with building it or with managing it (the rationalists and others). The machine god people ship. They build gnarly stuff because they can and because they are motivated. They may not have a product or any meaningful path to revenue. They want bits and pieces of things they can use to build massive-scale AI systems purpose-built for plant scale intelligence. Show them how you can build these small subsystems and they will go to war for you. I tried to provide some inspiration with stuff like my self-expanding knowledge graph talk (GitHub). Is it obviously revenue building? No. Was it fascinating and highlight some feature of intelligence? Yes.

• The hobbyists. Hobbyists are a massive group. They are somewhere between enterprise users and machine god types. They simply love the act of building things. Adding UI frontends. Building experimental inference engines. Hobbyists “play”. Hobbyists are an extremely powerful group, because they often become professionals at companies. If you support them in their hobbies, they may support you in their professional work. This means focusing on your open source efforts, providing cookbooks, and contributing demo applications. Show them something they can expand.

It’s up to you how much you get involved in each of these. Know that going too far into any one group in particular can be costly in terms of your ability to build a reputation with other groups.

News resources

• AINews is probably the best one.

• TLDR AI gives you a few of the big stories.

• Platformer for a big picture overview of the industry. More general interest.

Conclusion

Developer advocacy is about connection, between people and products, problems and solutions, communities and companies. It's a role that demands curiosity, empathy, and genuine enthusiasm for the technology you represent.

The best advocates I know share a few traits: they build interesting things, they listen more than they talk, and they remember that their audience is people trying to solve a problem.

Developer relations is challenging but rewarding. You'll need to be comfortable with ambiguity, constant learning, and wearing many hats. But you'll also get to be at the forefront of technological progress, helping shape how developers interact with the tools that are building our future.

Above all, remember to play. The moment advocacy becomes just another marketing job is the moment you've lost the thread. Stay curious, stay engaged, and keep building cool shit.

– Cameron