Learn, Build, Share — How Developer Advocates Spend Their Time

I’ve been working as a developer advocate (or tech evangelist) for almost 2 years now. One of the topics that comes up in conversation with other advocates is how to allocate time. Depending on the team, advocates may be expected to interact with users (or customers), generate content like blogs and videos, or give your opinion to the product team on usability or feature priorities. Or for many of us, all of the above. So how should advocates determine how much time to spend on each of these activities?

The search for balance

I’ve gone through several periods where I felt my schedule and priorities slipping out of balance: “I’m not interacting enough with real live developers”, “It’s been a while since I posted to my blog”, and so on. I remember one conversation with a colleague where I shared my plan to work on blogs and videos each morning and code every afternoon. It didn’t take.

After wrestling with this for a while, I started using the framework “learn, build, share” to help me think about my tasks. I recently shared this with my advocate team, and maybe it can help others as well. I’m guessing I’m not the first to put these three words together, but I think this is a framework that can be really helpful to developer advocates.

Learn

This is probably not a surprise, but advocates probably don’t know everything about the technology they’re advocating. I’m open to hiring advocates who are not experts in our technology stack, but who have demonstrated that they are curious, great developers, and passionate about helping others. Certainly expertise is our goal, and we get there by learning.

Even those of us who think we are experts are slowly becoming obsolete if we don’t continually refresh our knowledge.

This is why I encourage my team to spend quite a bit of time learning our company’s technology by consuming our own training content, reading our documentation, tracking Jira tickets, and so on.

I also encourage them to spend time learning other technologies related to building cloud applications, maybe even an equal amount of time to learning our own tech. The landscape is continually changing, and knowing how our technology integrates with complementary technologies or competes with similar technologies is key to being able to help others.

Build

I originally was calling this category “code”, but that felt a bit too narrow. Building includes coding, but can also include tasks such as deploying and maintaining sample applications, and working to automate these tasks.

The point is that it is super important to get hands on with the tech you’re advocating, not only to cement your own understanding, but to experience it as your developer community experiences it.

Another benefit that is often overlooked — advocates are in the position to be the “0th user”. We have the opportunity to use new releases and features before others and can help sand down the rough edges of developer experience before they affect our community.

Additionally, you can shape the code that you write into real-world examples. My team has grown a lot of our own skills by maintaining the KillrVideo reference application and various other GitHub projects. In fact, example projects like these have been a great source of inspiration for content like videos and blog posts. Which brings me to the next topic…

Share

Yes, developer advocates should be generating a variety of content to help our communities learn — blog posts, how-to videos, presentations at conferences and meetups, and podcasts. My team is doing all of these, and we’re continually experimenting with new ways to connect with developers, even live coding on Twitch.

However, I’ve found it’s tempting to get wrapped up in the content generation machine and just generate content for it’s own sake. Another trap is to focus primarily on what I’m interested in personally. When my interests and those of my developer community’s interests coincide, then everything is great, but if not, I’m wasting time on things that aren’t helpful.

I’ve been thinking a lot lately on how to do better at listening to developer needs. It’s a definite growth area for me and my team, but here’s what I’m thinking so far:

Probably the best way to do this is through 1-on-1 conversations. Listen to the questions developers are asking about your technology. Ask them where they go for answers, and whether they’re finding what they need.

I also recommend using a data-driven approach to corroborate or supplement the anecdotal evidence you’re picking up in 1-on-1 conversations:

  • What questions are getting high traffic on forums?
  • What terms are visitors searching for on your website? Are they finding anything?
  • What content are developers engaging with? Especially interesting: “long tail” content that has been out for awhile but is still getting traffic.

Our developer communities are constantly telling us what they need. Are we listening?

The golden ratio?

I try to think of learn, build, share as a 1/3 — 1/3 — 1/3 balance. However, I don’t track my actual time against this ratio. Instead, the real point of my mental model is that I strive to do at least some of each activity each day. A constant inflow of learning, practical application through building and outflow through sharing makes each day unique and keeps me from getting stale.

Bonus for managers: Team

For those managing developer advocates, I’ll add one more area: “team”. This consists of everything necessary to gather an outstanding group of advocates and help them find fulfillment in their work, including:

  • Recruiting a distributed, diverse team with a wide range of experiences and skills that is passionate about helping developers succeed.
  • Providing air traffic control for the many requests coming into my team: “I need someone to give a talk at my meetup”, “we really need a blog post on this new feature”, etc.
  • Coaching advocates of various skill levels, helping them cultivate their technical interests, grow their brand, and make an impact on our community.

If this sounds like an environment that would fit your interests, I’d be interested in talking to you about joining our growing team. Check out the job list on our careers site for an up-to-date list of open advocate positions.