I’ve worked in Developer Relations in numerous forms and across three companies (Microsoft, Oracle, and AWS) since 2010. In those roles I was in multiple departments: Marketing, engineering, and business development to name a few. I have had a diverse set of managers and numerous metrics and goals each with very different priorities and expectations.

When you boil all of those roles down, there are more similarities than differences, and it’s on synthesising my experiences that I bring you my following tips for surviving and thriving in DevRel.

1. Always Think about Scale – Every Question Can be Turned into a Blog Post

In developer relations, you get a lot of questions. Sometimes about the company, you represent sometimes about your set-up. If one person has bothered to ask you a question, there is a good chance there are a thousand others that would also like to know the answer: this is my main source of content for my personal blog. If you get an email or a DM asking you a question, write a blog post that answers the question, copy the link and then paste it back to them as a response.

You have just converted a 1:1 engagement into a 1:many engagement. This is the key to scale. It’s not doing more, but making everything that you create count. This concept was one of the first things I learned when I started in Developer Relations at Microsoft and was popularised internally by a blog from Jon Udell.

2. Every Technical Blog Post can be Turned into Another Asset

On a regular cadence review your most popular blogs and think of ways that you could reuse the content in other mediums. Could you present this as a video? Could you create a series around this? Could you create an abstract and submit it to a conference? Could you approach a podcaster and ask to talk about it on their show?

I call everything I create an asset. I call anything I do, an activity. So the creation of a talk is the creation of an asset; the delivery of that talk at an event would be an activity. 

The main ones are:

  • Written (Blogs, Whitepapers, Docs, Tutorials, Product Feedback, QnA)
  • Video (Live and Recorded)
  • Speaking (Talks, Webinars, Events)
  • Audio (1st and 3rd Party podcasts)
  • Code (Tutorials, Sample Apps)

In my workflow, blogs come first, you may find that video comes first for you, but the process should be the same. Take popular content that you have and find new ways to use it. I call blogs my seed content. Seed content should be something that you enjoy creating and something that can be published quickly and has little friction. My personal blog is often where I put seed content.

It may feel like you are being repetitive, this is a good sign. You are aware of your entire back catalog, but your audience rarely is. Most traffic nowadays is passing. Some of your audience will be loyal subscribers but the vast majority will have never heard you speak or read anything you have created before.

I was once told by a colleague that he aimed to have an asset published every day. It could be an answer to a question on stack-overflow, a video, a blog post a talk at a conference. The balance of what you focus on creating will be directed by what you want to achieve, but this basic rule is a good one to follow, a constant pulse of high-quality output shows the world you active and engaged, this will attract people and help you build a network.

Personally, I publish around 2-3 things a week. Sometimes this will be an asset that is part of a bigger program, a marketing campaign or just a post on my blog. Generally, things that feed into strategic and planned programs work better and scale better.

At the end of the year, when I look back, it is very often the case that only 10 assets actually created real impact.

You might think it would be better to just focus on creating those 10 things, that actually worked. However, I have found it doesn’t work like that, and I think there are three reasons why:

  • Often ideas that I think are going to resonate do not, and vice versa. There is no way to predict the hits. There is a lot of luck as well as skill.
  • Unsuccessful content assets are gateways to creating successful assets. You wouldn’t have created the hit if it wasn’t for the 10 failures.
  • Assets are never really a failure, you always learn something. Not every asset you create has to be viewed 50,000 times for it to be a success. Metrics in DevRel often relate to the scale of impact you have (and this is probably a good measure in most cases) but there are often times when a workshop attended by 10 people influences one person that then goes on to build something astonishing on your platform. 1:1, 1:Few, and 1:Many are all important and regardless of your metrics, you should do all three.

3. Write Your Talks at the Beginning of the Year

I write 4-5 talks in the first month of the year and will try not to write another one for the next 11 months.

The ideas for my talks come from 3 places:

  • Content that I have created which has been successful.
  • Whitespace analysis to identify content gaps. This is often driven by data that often comes through marketing, or from listening to customer.
  • Looking at my target conferences for the year and thinking what the organisers and the audience will want to hear about.

Over the year I then have the opportunity to refine, rewrite and rehearse my talks to the point that I am really good at delivering them.

Every-time you speak at a conference, customise your talk for that audience, I often do this the day before as I walk around the city where the conference takes place. I include pictures from the city I am speaking in to illustrate points that already exist in my talk. I use examples of customers and solutions that were built locally, I take photos at the conference and previous speakers and use them to reinforce and relate them to my own message.

This idea comes from one of my comedy idols Eddie Izzard. Every-time you watch him it appears that a concept or an idea just came to him at that moment. He is so well rehearsed and so well prepared that many people believe he hasn’t rehearsed at all.

4. Create a Speaker Page. Internally and Externally.

I have a speaker page. It lists all the talks I am giving at the moment and then has other stuff conferences and promoters will need. I include a selection of Biographies, examples of my work, some headshots, and even a pronunciation of my name.

The biographies are essential. I would recommend you work on an internal version too. This is because you will inevitably be asked what you do by co-workers. Trying to write 100 words about what you do is a great exercise; getting your boss to review it will help uncover their expectations of you as well.

5. Become a Better Writer

I’m dyslexic, but I have found myself in a world that requires a lot of written word. Over the years, I have worked hard to improve my writing, and I am still learning.

I take courses to improve, all the companies I have worked at have provided some level of training, but there are also excellent public resources, such as this course from Google.

6. Become a Better Speaker

Public Speaking is an area that I have improved drastically over the years. It’s a skill that I found had to be earned rather than learned. Others can help you on this journey, but it’s all about how much preparation you put in and how much practice you get.

My two favourite books on the subject are Confessions of a Public Speaker and The Presentation Coach – Bare Knuckle Brilliance For Every Presenter.

I also have some tips on my site:

7. Stay Technical

Write code as often as you can, get involved in projects. Even helping to get bugs into a reproducible state helps flex the technical muscle and keeps you current.

If you are trying to get better at writing and speaking, as I mentioned in my last two tips, read lots of other people’s tutorials and talks. Analyse what they are doing but also follow along with the code examples. You always learn something new by following other people’s tutorials, and it will help you become a better writer and speaker yourself.

8. You are Probably in Marketing – Embrace it

Even if you are not in the Marketing org, your function is most similar to marketing. Many people shudder when they hear this because they often conflate Marketing and Advertising to mean the same thing.

Good marketers are worth their weight in gold because they will have studied the product marketing loop and have a whole academic set of tools and processes designed to understand customers’ needs and internalise that to make products better.

Aligning with marketers and figuring out how you can build mechanisms that scale and creating feedback loops is critical. Developer Relations is where Product Development and Marketing Strategy meet customers. I have found that a good partnership and relationship with marketing leads to high impact results.

9. Know your Stakeholders

This job can feel isolating, and you will most likely be one of the smallest teams in your company. It can feel like no one knows what you do, and frankly, no one cares.

I have found it useful to look outside of your direct peers and map out who your stakeholders are. Spend some time thinking about who in the company needs to know what you do and who has the time and resources to help you achieve your goals.

Your most valuable assets to other stakeholders are Technical Content Creation and representing the voice of the customer. These are services that you can offer to internal teams, and in turn, they will often help you with things like budget, support, and resources.

10. Organise and Stay Consistent

I am not a naturally organised person, but this job does demand it.

Networking internally and externally takes planning and time. Creating assets requires discipline and self-direction.

Building asset plans and writing down what you want to achieve over a year are two processes that I go through at the beginning of each year. I try to get stakeholders and managers to review my plans, and I continuously course correct.

On a day-to-day level, I use Todoist to keep track of the things I need to do. I like it because I can create both tasks and Kanban boards which suits the kind of work I do.

I might write ten blog posts over a week, but I will probably delay their publication, so I have 1 or 2 things going live each week. This gives the external and internal impression that I am always busy. This works better than having short sharp bursts of activity and then months of silence.

Spend time reviewing old content, update it, check it, and re-write it. Google never stops recommending articles I wrote nearly ten years ago.

And Finally

Enjoy what you create and try to align your personal goals with that of your companies. If you genuinely enjoy your job, you will never have to work another day in your life.

A-a-ay, I’m on vacation. Every single day ’cause I love my occupation

If you are interested in a career in Developer Relations. We have a number of career opportunities. Check them out on the Amazon Job site. Get in contact if you have any questions or would like a referral.