Thread by @HandNF

Returning home from a great day with my extended family, and during this trip I want to talk about Developer Relations, why it matters, and what I do.

"What do you do" comes up a lot. My main job is to ensure developers are successful. What exactly does that mean?

For context, I work at Google in DevRel for Google Assistant and IoT. While many things are the same anywhere, these are two nascent platforms that don't have a lot of established tools and a massive developer base.

There's not really a "normal day" for me, but there's definitely recurring themes over various periods.

Every morning I check the developer community for issues and questions. That's GitHub, Stack Overflow, Google+, and anywhere else.

People post issues on our GitHub samples and libraries. These can be bugs in our code, technical questions, platform bugs, feature requests, pull requests, and a lot of other stuff.

I answer questions, but some are legitimate issues. I create bugs internally for PMs to address.

Sometimes I can answer it, but developers are creative and will find lots of novel use cases. Being able to listen to devs and communicate questions is a key skill.

Sometimes they find issues in our documentation. We work closely with the tech writers, so fixes are quick.

Feature requests are sent to PMs. While one request may not be enough to build the feature, we can advocate internally for the developers if it's a good use case. PMs may not take on each feature, but it's important they have a wholistic view of the platform, including small devs

We have meetings once a week or so, syncing with the product teams. This can be where we discuss these issues in more detail, new things in the pipeline, and anything else on our minds.

For new features, a lot can be done: samples, docs, blogs, videos, social, etc.

Cool, there's a new API. How do developers use it? We build code samples, projects that use the API completely with best practices. This can't be spaghetti code. It needs to be readily legible for unfamiliar developers.

We also make sure our docs explain not just how, but what.

Depending on the importance, we can write blog posts. These go into more detail, with more specific guidance for our example use case. We may also create short videos to demonstrate it visually, as some devs like that style of content.

We also are the API 0th customer.

The 0th customer means that we try it out before anyone else with a 3p dev perspective. We try to use it. Sometimes we identity major issues or novel use cases that weren't considered. We work with the product teams, lending our experience as a 3p developer (through samples).

So after some time, these things launch, and we coordinate the launch of all of this developer content.

But that's not all. We regularly do things that are irregular.

Every few months I give a talk at a conference, though others do it more frequently.

Travel is fun, but it's also great to meet developers in person. They ask tough questions, and sometimes I don't have a good answer. I do know who to forward questions to though.

Workshops are great to see developers running into roadblocks that seemed obvious, which is helpful.

At the end of each event, we put together a trip report. This is a summary of key impressions, questions, and issues. This is shared with the team, PMs, product teams, and anyone else who might be interested.

From this we can create bugs, feature requests, and fixes to code/docs

I post a blog post about once a month. This can be a lot of stuff. I may be sharing something cool I built, or highlighting something obscure. Using my knowledge of the developer community, I try to create content that would be helpful like to answer questions preemptively.

I created a few videos over the year, trying to provide simple descriptions for platform features. These can be fun, and are more visual. Google's got a studio to help with production, but it's up to us to create the script and get approvals from various stakeholders.

A lot of my job is writing code, whether that is creating new samples, codelabs, or experimenting with novel ideas, I create a lot of code commits. We pass around these commits frequently for code review. These help ensure code quality and style, which is important for samples.

I also will work on docs if needed, if we need to do some work on generating pages or need to check code snippets. DevRel is pretty flexible in day-to-day work, so one needs to understand a big picture to be most effective.

Samples and codelabs work is fine. We take a bug, either one from GitHub or from PMs, write the code, review it, and publish it.

The experimental stuff is more fun, and also valuable. It can help highlight current platform issues by doing something real. Feedback docs are good.

Each quarter we plan our quarterly goals. Goals come from the product teams, if PMs have things to launch. They also come from the community, if there are things we should fix, or if there is something we want to build for a better developer experience.

Metrics aren't necessarily easy. We aren't responsible for making money directly, but ensuring a strong developer community.

GitHub stars, questions answered, projects created, developers reached, library downloads, blog reads, and others can correlate with a good community.

We try not to obsess over one metric, as that can lead to bad incentives to push one thing at the cost of other critical parts of a community.

Our community helps keep us straight, especially our developer experts, whom we meet with monthly. Lots of their candid thoughts help.

One thing to note is that we work with long-tail developers. Most people don't have large companies and won't partner directly with Google. There's folks for that, but try to help anyone.

Sometimes I get emails from these large partners given my aid in the broader community.

I am remiss to end this thread, as I'm sure I'll remember something after I submit this, but I hope this was a good overview of what DevRel is and it's importance in crafting good developer experiences.

I enjoy my job. It's challenging, as our work is flexible and self-driven.

Yet whenever I go to a hackathon or conference, I can see my work put into practice. People learn something, and that's not necessarily easy. It's non-trivial to explain voice apps in a way that's approachable for beginners. Sometimes I worry, but then I see people get it.

You need docs, and samples, and videos, and everything. That's table stakes, and the "work" part of our job.

But for a successful dev community you need to listen. Listen to dev issues and ideas. Even if you can't solve them, showing up will keep them invested.

Fin.

DevRel, at least at Google, is engineering. We write code and build systems that are easy to plug and play. You may start with samples, but you also build tools. These may incorporate a lot of subsystems in a useful way. Senior DevRel build complex but good tooling for devs.