Tell us a bit about yourself.

Hi, I’m Lorna. I’d describe myself as mostly software engineer, with a side helping of writing words. I learned most of what I know in the open source communities, for a long time my main stack was PHP and so I’m best known as a blogger and user group speaker/organiser in that space. I’ve also been speaking at conferences for a long time; I began because I had no other way of funding any conference tickets or travel, and then I realised that I could explain things to other people in a way they could understand. I’m still a conference speaker and an open source maintainer and contributor now, those things are an important part of how I see myself in the tech industry, and I hope that both activities are things that spread knowledge and good tools around.

I started a blog very early on (it was cool then!) and I’ve found that an incredible tool all the way through my software career and now into Developer Relations. I just write down the things I don’t want to have to look up again, then Google can find them for me when I need them and if they help someone else as well, then great! From the blogging, I started writing for other outlets like magazines, and later I was invited to write books. I’ve always loved to write words and the “developers won’t write” stereotype made me doubt myself as a developer. Now I know that being able to communicate well in written form is a key skill for senior developers of all kinds as well as for DevRel. As for me, when I was 6 years old I had a teacher who told my parents I would write a book some day. I am pretty sure she was thinking bestselling novel but I couldn’t be prouder of the O’Reilly “animal” book with my name on it!

How did you get into Developer Relations?

As a software developer, I spoke at conferences because that was the only way I could afford to go to the events where I would learn all the things I wanted to know. At the conferences, I hung out with the maintainers, the influencers, the “Evangelists” as they were called back then. It took me a long time to realise I had found my tribe! Having a lot of good tech knowledge but also a great network that could rescue me quickly from difficult situations was really useful. In the open source world, it usually doesn’t hurt if your username is familiar to the person whose project you’re opening a pull request against. I already mentioned the written word as a big part of my identity as well - and taken all together, that’s a really strange bundle of skills and I’m pretty serious about doing each one well. It turns out, coding, speaking and writing are the three base skills for a role as a Developer Advocate so eventually I gave up insisting that I was an engineer and found a role that relied on that strange combination, plus other skills I didn’t know I had, in a way I could never have imagined.

What advice would you give people looking to join you?

Understand that it takes all sorts of people to make a Developer Relations team successful! I’m a pretty traditional Developer Advocate, with a very strong coding/technical background and a great deal of open source experience - I had also written for lots of outlets and given hundreds of talks before I was officially employed into a DevRel role. That’s definitely not the only skillset or the only route in, so if you love technology and people, then we need you too. When I interview for Developer Relations roles, I’m looking for evidence that you are going to live and breathe the community as well as just the code. So write some blog posts, contribute to some open source projects, give a talk at a local user group. It doesn’t need to take a lot of your time, but if you have never spoken in public before, how do you know you want to do it regularly? If you’ve never written a blog post, how can I hire you and ask you to put together a content schedule? By trying out some of the extra skills, you can help any community WAY before a company pays you to do it. That’s how I learned my skills and I think it can be a great thing for others interested in a similar career as well.

How has your role changed in the past year?

I never imagined I’d be a Twitch streamer, or deliver a keynote talk from the comfort of my home office! I’ve got more audio/video kit than before and I have learned to read a chat window while delivering a talk, which is something I used to find quite difficult. My role hasn’t changed much beyond the lack of travel but I feel like the industry has come closer to my point of view that digital developer relations scales much better than all the running around between airports and conference venues.

How do you see the future of DevRel?

As the profession of Developer Relations grows, both in the number of people doing it, and in the types of roles in encompasses, I see a wider range of people coming into the space and I’m excited about that. For the future I expect and hope for two things. Firstly, that everything we’ve learned this year about digital communities stays with us as we go back on the road in the next year or two. I’ve met and interacted with people in situations and locations that I would never have been able to cross paths with before, and it’s a good thing. I already mentioned my open source background and I feel strongly that we can do great things with online tools, source control, IRC/discord/slack, and so on. Let’s keep on being digital as well as picking up some of the in-person experiences as they become available to us. The second thing I’m hoping for is for more specialisms to be recognised under this DevRel umbrella. Personally, I consider myself to be at the engineering end of the DevRel spectrum (pretty sure it’s a spectrum that has more than two ends but you know what I mean!). I am all about Developer Experience and I’m excited to see Developer Experience Engineering and SDK/CLI engineering and also the API description related roles all getting more traction. Developer Relations does need to include the very technical roles to support the very technical audiences, and I hope to see that becoming more formalised in its own right.