Developer Relations isn’t new, but it’s also broad, ill-defined, and constantly evolving. It’s difficult to keep your own skills up to date, never mind coping with a whole team full of people and constantly creeping industry scope. The required combination of specialist and generalist skills to be successful is any of the Developer Relations and allied roles is extensive, and it’s easy to feel overwhelmed and end up coasting being just-good-enough at things but never feeling mastery.

As an individual contributor, manager and general DevRel presence over the years, I’ve developed some tactics both for myself and my team, and I’d like to share them in case they’re useful to others. Also since I’m moving to a less DevRel role, writing this down while I can still think about it!

The Monumental Skillset

When I was in my first ever round of interviews for a Developer Advocate role, I asked the interviewer “What is this role on the way to? I love Software Engineering, but if I become a Developer Advocate next, where does that lead me?”. He thought for a while and then said “CTO. I’ve seen a couple of very good DevRel people do that and the only skillset this weird belongs to a founder”.

That phrase stayed with me “skillset this weird”; it’s funny because it’s true. Developer Relations professionals need to understand or maybe even perform the job of their target audience. We need to communicate in writing as well as the documentarians, operate social accounts like the PR specialists, deliver technical content like a lecturer or keynote speaker – and probably video stream as well. We need to be able to juggle multiple competing projects, and often complex travel arrangements, and be publicly available, polite and positive, online and IRL, at all times. That’s three separate career categories right there, so how do you gain all those skills, and develop them in meaningful ways? And when you change jobs and need to switch out to a new tech stack and a different subset of communication and workplace skills, then what?

The first thing to recognise is that many roles need some selection of these skills, but not all of them are equally important in each role. Your team may already do a skills matrix to help you understand what skills are most important in your role, or how the skills are spread across the team members, and this can be useful. If you’re doing this with a team for the first time, keep it simple. Mine usually look something like this (I’m resisting the urge to go on a tangent but let me know if a post about this would be useful):

The desired skills and level of those skills will change between organisations, between roles, maybe even within one role over time – that’s expected. What you need to do is identify something that you could get better at. Then it’s time to make a plan.

Self Help for Developer Relations Professionals

This career isn’t well-defined. There aren’t many well-recognised certifications or exams to take, and in many ways as an industry we’re still working out what would be considered good practice in any particular situation. By picking one skill to work on, you’re essentially putting a better tool in the toolbox that you take with you and open when you need to tackle any challenge.

In the absence of a single source of documentation or other truth, we become our own teachers, but luckily there are so many good resources out there that the real challenge might be choosing where to start! Some topics can be studied in an afternoon; if you need to prepare to host the regular webinar on StreamYard then their own docs, a well-presented example webinar and some time spent pressing all the buttons and checking the output is probably all you need.

Other skills or topics may take a little longer, especially where the scope is large; for example public speaking is an apprenticeship that takes a lifetime! Along the way I have: read about ten books and many online articles about various aspects of the craft, given a few hundred talks with a few thousand hours of private rehearsal, watched those talks on video where they were recorded, received a lot of talk feedback, watched a thousand talks by other speakers, helped a few dozen other speakers to prepare and deliver their talks, become quite a connoiseur of talk abstracts for different types of event, spent two years as a regular Toastmaster attendee – and come away with the impression that there really is a lot still to learn.

What’s common to both of those learning journeys is the mix of study, activity, and advice that brings improvement in each area. Taking input from different people, in different formats, and crucially practising those skills and reflecting on your progress, is what drives you forward and also consolidates what you learn.

Identifying resources that can give you what you need next can be difficult, the Internet is a big place. Set up a feed reader and follow the writings of people you admire in your area of interest (I started putting some suggestions here, but frankly it got out of hand and should be a separate post). You can also look at the archives for curated resources lists such as DevRel Weekly to find things on specific topics or get to know some individuals to follow.

When it comes to the hands-on element, there’s an idea called “deliberate practice” that expands on research showing that the quality of someone’s practice is what dictates their skill improvements. Be intentional with learning, with looking for opportunities to use those skills, preparing well for the opportunities, and in reflecting on how things went afterwards.

Multiply the growth

So far, so personal and professional development. What about the next generation? Well, in DevRel, we are all the next generation. There are people just joining, leaving, transitioning in sideways, and others doing the same role with a different title – and all of them are an important part of your story, just as you are of theirs. There is no “still doing it the old way” here, all of us keep on learning, evolving, adapting, improving.

If you have experience in the field, then you can raise the next generation by sharing your skills and knowledge with the individuals behind you. This is super valuable and could have been a blog post by itself – but this is a different post.

The real scaling of the DevRel skill standards comes from us being intentional in the way that we lean on one another to learn. You are probably familiar with all the techniques here, but consider how you might apply them to the next thing you want to learn, with the people you have around you. Here are some ideas and when to use them:

• A study group or book club: This is really effective when there’s a well-defined knowledge need (rather than a skills one), and you’re all at a similiar level to start with, so it’s a group with a shared mission. An example of when this could be useful: working through the onboarding guide to a new reporting tool that you’re going to be adopting at your organisation.

• Shadow an expert: Borrowed from medical teaching practices, where famously they “See one, do one, teach one” to learn a procedure. This approach is ideal when you have an expert who is prepared to work with you to hand over the activity or skill. I’ve used this before when chairing meetings, and wanting to be able to rotate the chair. First, I explain my chairing process, what I’m looking for, how the mechanics work. Then, I chair a meeting, with my protege in attendance. At the next meeting, they chair, and get some feedback (realistically, we might repeat this step a few times – and I’m sure doctors do too!). Finally, and after some practice, they will take on the responsibility of teaching this to someone else one day.

• Feedback loops: Most developer relations teams practice this one already, using the rest of the team or company as talk rehearsal audiences or blog post reviewers is a great way to improve at speaking or writing. Note that the purpose of the feedback loop in this instance isn’t to make a great talk/post, but to help the author to reflect themselves on what is already great, and what can be better – and pick that up themselves next time. Getting better at delivering great feedback is also a skill worth working on, try Lara Hogan’s Feedback Equation and take your responsibilities as a feedback giver seriously. To be really meta, take a leaf out of the Toastmasters’ book and give feedback on how the feedback was for those looking to improve their feedback skills. This approach works really well for improving skills like speaking or giving feedback, and can also work in a team of peers – it doesn’t necessarily need an expert to offer feedback that you wouldn’t have thought of yourself.

• Formal study: Formal study is still pretty effective, actually, especially for individuals with good study skills. Although if you prefer video, then do that too, of course. The hard part about this sort of thing is making time to study solo. An online course with deadlines can help ~force~ encourage you to keep up with your studies and invest the time in this approach. I’ve written about this before (wow that’s an old post!), but it’s just as effective today as ever. This approach works best for fairly quantifiable skills, so learning a new tech stack or a particular technique makes this a good option.

• Write the docs: Docs-driven study is one of my favourite ways to get to know a tool or technology. Take responsibility for one piece of documentation or a tutorial on a topic that’s a little outside of your zone. By working through the details yourself, to a level where another person can come along and use what you produce, you will unavoidably learn something! This is especially good for getting to know the tools that you haven’t tried yet, or that cool third party integration you’ve been reading about.

None of these are difficult to adopt, but it’s unlikely any of us will improve if we keep doing the same things, over and over. Go out of your way to pick one thing to improve, focus on, or intentionally practice. It’s hard to feel like the other things can wait – but they can. Honestly.

Be Curious, and Generous

The truth is, there’s a lot to learn, and there always will be. Good learning habits, and intentional drive to improve are the best things you can teach yourself. There is a lot of research, plenty of good “this worked for me” content, and other resources around us. Go hunting for the best bits, and devour them. Share the links with others in your network, or curate collections so we all keep learning and building.

Crucially, remember that someone is always you on the path, and you have something to teach them. Write what you’ve learned and how others can use it too. I hope this post helped you to reflect on the resources we have available to teach ourselves, our teams, and our industry – but I would never have written it until one day I looked at the team I had grown, and saw them grow one another, and thought we were on to something that we should share.