Transcript
What were you doing before DevRel?
I was a freelance developer and I actually got into tech through going to hackathons. My very first hackathon was also my first time writing code and I was interacting with developer advocates. I kept going back to those events to learn new skills and then I was also spending a lot of time volunteering at these hackathons. Eventually, I ended up working for a company that ran most of the hackathons I'd been to and that turned into their developer relations role.
What did you previously think about DevRel that you now know is wrong?
That businesses care about the act of DevRel. That they particularly care about the community building nature of it and the act of creating content and educational materials.
That is not what businesses care about at all. Businesses care about generating revenue and they care about our work in DevRel only so far as it help generate revenue. That means everything we do has to generate revenue and therefore a lot of the stuff that you see that looks fun is only sustained if it also fulfils a need for the business. It's being done because there is some motive to the business now or later around revenue generation.
What did you think about DevRel that turned out to be right?
DevRel professionals interact with developers in two ways. There's one to one support and there's also one to many interactions that reach developers at scale.
At the very beginning, I saw a lot of the one-to-one interactions because I was afforded the time of developer advocates and that was hugely impactful to me. But I did also see early on that a lot of what DevRel people do is about reaching or impacting as many people as possible. And I think this is a really important distinction which remains true when you're starting to compare DevRel and other functions like sales engineers or customer success. A lot of these roles will very much deal on the one-to-one level. In DevRel, everyone may do some of that but what really powers the work we do is the ability to impact many people with just one artefact.
When did you start to learn about DevRel?
Like many people, I got into DevRel through a very narrow lens through my time doing community work. I wouldn't necessarily frame it as DevRel but I was enacting parts of the role and getting good at parts of the role.
That very first role I did was about building a network of developers to do service delivery. And then the second role was very much focused on events. So it wasn't even so much that I was learning about DevRel. I was learning about the act of maintaining relationships with professional developers and then delivering events. I was learning how to do certain parts of DevRel and then, over time, I've come to realize that what I was doing was building this set of skills that comprises the discipline of DevRel.
I've been to a lot of DevRelCon events and, so, I've been fortunate in being part of that community of people who have trodden that path before. And they've been willing to give me time. In the the same way, I'm willing to give time to others now.
Also, I've seen it just go wrong too many times when I've been an individual contributor. Each one of those failures is a lesson on how things can be done better.
Were there any individuals or communities that were particularly influential?
That very first DevRel role that I did, where it was an internship that turned into a DevRel role, had a component around youth tech. The point where I really started to be plugged into this community was through doing student work with Major League Hacking.
I'd already been doing developer relations for a couple of years but completely on my own island. I wasn't plugged into anything. That very first HackCon EU that I went to in 2015 introduced me to a group of people who were delivering at a really high standard. Even though it was a student group, they had a real mix of ages and experience and that really levelled things up. And through that I met another group of hackathon organisers called Geeks of London.
There's also the community around DevRelCon and the DevRel Collective, which acts a peer support group for people in DevRel.
How did you find out about DevRel job opportunities?
For my first role, I volunteered and that turned into an internship which turned into a DevRel job. The next couple of jobs were a continuation. For example, one company wanted to hire the entire team at the place I was working originally.
But it was when I got plugged into the DevRelCon, Major League Hacking, and Geeks of London communities that I started becoming aware of job opportunities. Unfortunately, this is very much a space where it matters who you know not just what you know. And as I think about hiring DevRel people for my current team, I get why that is. There are a lot of people coming into DevRel who say they have a lot of experience but, when it comes to it, they don't really. And it's hard to get past that. So, recommendations go a long way in DevRel.
My advice would be to become engaged in communities that also include well connected DevRel people. Participate because you want to bring value to that community, not just to make connections. But the social capital you build will then help you to get introductions and referrals.
What skills gaps did you identify and how did you address them?
DevRel means everything and it means nothing. Developer relations varies a huge amount between different businesses.
So, it's not so much about what skills you lack but what skills you can offer. Identify the roles that demand the skills you have. If you're great at running events, there are DevRel roles that will focus more on running events. If you're a community builder, you'll find opportunities for people with that skill. And so on.
What advice would you share about the DevRel recruitment process?
I think most companies seem to asses candidates for a whole slew of responsibilities, even if they won't be a major part of the role. So, even if you're not going into an engineering role you may have a tech test. So, you're going to need to be prepared to provide materials and answer questions on things that might not be the core part of the role that interests you.
Last time I was interviewing, I found that each company had a different set of requirements for the recruitment process. And I was applying to many companies at the same time, so I had to minimise the amount of time I spent on each individual one while also still demonstrating why I was a strong candidate.
I recommend putting together a portfolio that shows the impact your work had on the company's strategic needs and not just one that says you did something and then leaves it at that. Having a portfolio meant that when an interviewer asked for proof of my content creation skills then I could hand over a ready made set of materials. But crucially, I tied each piece of content to results. Results might mean readership numbers or conversions.
That might mean you don't have to complete every test set by a company. It's important to be respectful but you might be able to point to a part of your portfolio that demonstrates your technical skills or events skills, for example.
One thing I would encourage people to push back on, though, are interview tasks that could be used by the company. So, they might ask you to create a strategy for the coming months or a video about their product. Even if they don't mean to, they're giving you unpaid work that they can then make use of.
What advice would you give to DevRel hopefuls?
I fear I sound like a broken record but understand that no business is hiring you just to do good for the community. They are hiring you because you need to make more money than your salary costs. And you do that by impacting the company's revenue positively.
Therefore, every decision you make has to have this in mind. DevRel is not a jolly. Your job is to warm developers up so they give the company money. You can have fun, help communities, and do other good things along the way, but it always comes back to impacting revenue.