Interview Intro

‍

Richard Rodger:  [0:00:00] Welcome to the Voxgig Podcast. We talk to people in the developer community about developer relations, public speaking and community events. For more details, visit voxgig.com/podcast. All right, let's get started. 

‍

In this podcast we talk to everybody involved in the developer relations industry. Today, we're talking to Louise Ogilvy, who runs Develocity.io, a specialist recruiter for dev tools startups. And in particular, Louise helps developer advocates find jobs. We talk about a whole bunch of issues facing the industry, including the old favorite of measurement, and that discussion generates some insights that I haven't heard anywhere else. Finally, we talk a little bit about developer advocate pay and whether it should be the same as developer pay. Alrighty, let's talk to Louise. [0:00:56] 

‍

Main Interview

Louse Ogilvy

‍

Richard Rodger:  [0:00:57] Hello, Louise, it is so nice to have you on the Fireside with Voxgig Podcast talking about developer relations. How are you today? [0:01:03]

‍

Louise Ogilvy:  [0:01:05] I'm very good, thank you, and very pleased to have been asked to come on and talk about all things dev rel. [0:01:11]

‍

Richard Rodger:  [0:01:13] I'm delighted to have you on. We try to have as many different people in this space as possible, everybody from CTOs to interns. You do something called Develocity; that's your company. So, I'm just going to let you introduce it and talk about it. [0:01:30]

‍

Louise Ogilvy:  [0:01:31] Perfect, thank you. I work in recruitment and have done now for over 20 years. And I've spent probably the last seven or eight years of my career working with startups, so very much advising founders, technical startups predominantly. And a couple of years ago, I got introduced to very wonderful founders of a dev tools company, and I was introduced to them at quite a critical stage when they were looking to grow and expand and to go through a series A raise. And I've helped them to increase their headcount by 42% and they've been through their series A. 

‍

And it was my first introduction to the concept of dev tools, and did a lot of research around it. So here, very much talking about companies that are building products specifically for developers or engineers, and something that contributes along the software development life cycle. 

‍

So, it was a whole new sector to me. And I worked with this company and a couple of others and then decided to break away and form a completely new, separate second company called Develocity, which is developer velocity, so putting those two words together, Develocity. And- [0:03:10] 

‍

Richard Rodger:  [0:03:11] It's great. I love it. [0:03:12]

‍

Louise Ogilvy:  [00:03:13] It's a great name; I know. I actually quite love the name. And so, Develocity now is very much dedicated and focused to working with startups in the dev tools space worldwide. And I very much define the areas that we focus on in terms of design, so product designers, product managers, UI/UX. 

‍

Then onto the build, so software developers who are building the product or the platform. And then go to market, which is very much focused on developer relations, advocacy, community managers. So, I do the whole cycle of taking a product or a platform from zero to then taking it out to the market. So, very much dedicated to the dev tools space. [0:04:08] 

‍

Richard Rodger:  [0:04:09] The first question that comes to my mind is, you have a – you must have a really interesting perspective on how the industry has evolved in the last couple of years, because you've been there almost from the start, right? So, you're seeing growth in the dev tools space; you're seeing growth in the amount of developer relations roles. What are you seeing in the market? [0:04:35] 

‍

Louise Ogilvy:  [0:04:37] Yeah, absolutely. There's been a number of changes in the market that have definitely resulted in an increase in these dev tools startups. If we look, for example, at some of the companies that are having to make layoffs. All of a sudden, these companies are asking their software developer teams to do more with less. And if there's any way to help with those teams becoming more productive without asking developers to work 20 hours a week more. So, where can they save time; where can they automate processes. 

‍

As we know, software is taking over the world, and so, there are more and more companies looking to build code, release code much quicker. There's been an increase in interest in how do we make these developer teams more productive. I also feel that off the back of that, there's more awareness now of developer burnout, based on those and other factors. 

‍

COVID, I know that software engineering has always been an advocate for remote working, but that's been expedited considerably with COVID. So now, you've got pockets of developers that are perhaps now working more remote than they did before, and so, there's an awareness within organizations of mental health around developers and development teams. 

‍

We've seen a huge movement in terms of companies now looking at that whole dev ex, the developer experience, internally. Over the last two years, I have seen a huge increase in the number of startups that are dedicated to dev tools. And also, a huge increase in the amount of investment that's going into them; there are now dedicated VCs to dev tools, for example. [0:07:04]

‍

Richard Rodger:  [0:07:05] Are you able to name them? [0:07:07]

‍

Louise Ogilvy:  [0:07:08] I am indeed, yes. There's quite a few, but there's one over in US called Basis Set, and they have a dev tools community group. They have a group of founders of dev tools who share experiences, who share resources. In fact, I'm over in San Francisco in September because I'm sponsoring or hosting one of their community meetups. That will be a whole group of dev tools founders. 

‍

And I can share some others. There's also Tapestry VC, so they are also dedicated to investing in companies that are building products for technical audiences. So, we've seen an increase in companies starting, coupled with an increase in investors now starting to understand and appreciate the value that those tools can add in the software world. [0:08:23]

‍

Richard Rodger:  [0:08:23] That is – it is really encouraging. I think there's – I think you'd agree; there seems to be a long-term trend which is upward. This is this – the whole idea of dev tools, developer relations, feels like it's establishing itself as a core activity in a lot of SaaS businesses. There's been a bit of a blip this year with some of the layoffs. Should we be worried? [0:08:48]

‍

Louise Ogilvy:  [0:08:50] We've obviously – it's been disappointing to see on a daily basis in our – I'm on LinkedIn all day and it's been very disheartening to see the number of individuals that are posting that they have been laid off. The vast majority, as I'm sure we can all see, are ion those bigger organizations. So, it's – there's been less of an impact on those small to medium-sized companies. But that in itself comes back to my point earlier, which is those big companies that are laying off. 

‍

And it's not all within engineering; of course, it's not. But the issue therein lies is that they're still expecting their dev teams to produce, but with – in some cases, the number of team prior to what they had prior to those layoffs. So, it's cyclical, and I'm tending to see it's dropping off a little bit. 

‍

Last year was the worst. I follow a tracker, if anybody's interested, called layoffs.fyi, and that lists a huge number of the companies that are going through layoffs. So, it's definitely slowed down, I would think, but I'm – unfortunately, I don't have that crystal ball to say what's going to happen for the rest of the year. [0:10:29] 

‍

Richard Rodger:  [0:10:30] I read an article recently, just to get nerdy and macroeconomic on it, that interest rates are zero, so there was tons of free money, so there was no downside to hiring, hiring and hiring. So, there was a bit of over-hiring. [0:10:44]

‍

Louise Ogilvy:  [0:10:45] Absolutely. A lot of companies came out of – we came off the back of COVID and hiring spiked; it really did. And then when the later impacts of COVID etc. started to filter through in 2022, that's why I feel that last year was at that pinnacle of layoffs. And I'm hoping now that this year, we're starting to see a little bit of a flattening of that curve. [0:11:22]

‍

Richard Rodger:  [0:11:23] Let's turn to the bigger trend in developer relations, which is – we're at the start of this journey. We were just chatting before we came on about how so many companies have no clue that developer relations is even a thing. One of my previous guests, a chap called Ado Devander, was talking about the types of companies that he engages with. The dev tools companies would be developer first in terms of their marketing, because the developers are the buyers, the decision makers collectively. 

‍

But then you also have developer enabled companies, where the product is not a dev tool, but there's a significant system integration or APIs or whatever, so they're significant influencers. Now I know your focus is on dev tools, but a rising tide raises all boats. In our experience,  – so we do developer relations services. We help people build APIs and SDKs and set up communities. 

‍

What I'm seeing in some of the pitches that I'm doing is, I'm talking to companies that have only sold through traditional business style sales where people go on golf courses and salespeople talking to the C-suite. And it's interesting for me, because I know the effectiveness of developer relations; I've used it very effectively in my last company. But then you hit a brick wall with some companies, where they look at you like you have four eyes. I don't know; have you ever seen that or- [0:13:09]

‍

Louise Ogilvy:  [0:13:11] Yeah. Amongst – within the dev tools world, we're fortunate, because you're absolutely right. They are developer first; they are building products for developers. So, they understand that in order to drive sales and revenue long term, the aim is to drive adoption by developers for your product, whether that is through community or content or blogs or going to conferences etc. 

‍

There's an awareness of what the role is within the developer tools world, so to speak, although that does still present, I feel, some observations around having that function within that business. Because it's easy to say, "We're a dev tools company. We need to drive adoption. Let's bring in somebody in a dev rel role. But ultimately, you've still got to have an understanding of what your expectation is on that person. How do you measure the effectiveness of that person or that function? 

‍

And also, for example, where do they sit? Do they sit aligned with marketing or sales, which is where they don't want to be? They don't want to be aligned with sales, because that's not how they necessarily view their role. Although ultimately, the activities that they do will have an impact on that. Within the dev tools world, yes, it's understood what that function is, but I've had lots of dev rel people approach me after we wrote some blogs saying, "You've just hit the nail on the head. This is exactly what I do. But it's really hard trying to describe to people what I do." 

‍

I do think there is a huge knowledge gap overall in terms of what the dev rel function is there to do. I think a big part of that is, sometimes, if people don't understand it, they don't embrace it. So, it's very much looking at how – it's one of those things. If you don't understand something, it's easy to pull it under the – push it under the carpet. 

‍

But how do we educate enterprise customers or anybody outside of dev tools of exactly the benefit of a dev rel individual team function overall. Because you're right; there's a huge advantage to enterprise customers who don't have a developer first product, but who would like developers to utilize their APIs etc. So, there is definitely an advantage to having a dev rel team or function even if you're not a developer first product. [0:16:26]

‍

Richard Rodger:  [0:16:28] Absolutely. In a personal experience recently, I was – a salesperson got hold of my mobile number and I answered it by mistake. It was for a marketing tool and they're pushing me into – we could just do a 20-mnute demo, 20-minute demo. I say, "Well, look, I'm technical. I want to see your docs. Send me some links by email. Show me the code." And it was vacuum cleaner salesmanship. The guy was like, "No, gotta hit my metrics. Gotta get a demo." 

‍

And I had to be straight with him; I said – I had to say, "Have you seen Glengarry Glenross?  This is not working on me. I'm a prospect. Give me what I want."  And then they promised to send docs, but since that time, I've had three calls, all of which I've had to reject, from the same chap, trying to get me onto a demo again. 

‍

But if they had some developer relations. Go into their website; have an API. But I have to fill out a form, and then I'm on some newsletter. I worry about people who end up in dev rel roles in companies that don't, as you say, understand the role. I've heard there's a lot of burnout as well, right? [0:17:57]

‍

Louise Ogilvy:  [0:17:57] Yes. 

‍

Richard Rodger:  [0:17:58] Are you – do you see that in people that you help? [0:17:59]

‍

Louise Ogilvy:  [0:18:00] Yeah, absolutely. I've got a couple of dev rel roles that I'm working on at the moment, so, and it's part of my role, I guess, is that I do lots of headhunting. It's how I manage to maintain a network of dev tools specialists. And a couple of people that I've reached out to recently who had been in the role said, "No, I'm done. I'm done with it. It's – I had burnout." Because it is non-stop. It' s a very difficult role to fill, because my view – and I apologize if this is not a shared view – but my view is that you really need to have that deep technical expertise. 

‍

We see lots of developers who have then moved into dev rel. Because you've just given a great example there. [Inaudible 0:18:59] to that perhaps – not that a dev rel person would have picked up the phone to make a sales call, so it's not the same. But if we look at that scenario you were in in a slightly different way, had that been someone that was deeply technical, you probably would have had a conversation about various different pain points etc. And they would talk about their experience of having been through a similar thing. 

‍

The difficulty with filling the role is, you need that deep technical expertise, but also, you've got to have somebody who loves communicating, loves building communities, is happy to go to conferences etc. And it's not the easiest persona to find, so when you do, it's how do you then look after that person? 

‍

Because if they are – I know; I'm in recruitment. I talk to people all day. I get to the end of the day; my children want to talk to me. And sometimes I have to say, "Can you just give me half an hour?" Because I've been talking all day; I've been giving people my attention all day long. 

And dev rel is no different. 

‍

Whether that's because you're on Slack channels talking to people, answering technical questions, or whether you're recording YouTube videos or whatever it might be. There are – and this is another point actually, is that dev rel can sometimes – in a startup in a very small company, that dev rel person quite often has the additional responsibility of a solutions engineer. 

‍

So, they can be talking technically to customers on the phone as part of that early process, or maybe looking at the onboarding and the integration, if a company isn't big enough to have multiple people in multiple roles. So, I know from personal experience that you're talking to people, giving of yourself all the time; it becomes tiring. [0:21:05]

‍

Richard Rodger:  [0:21:07] Very draining. 

‍

Louise Ogilvy:  [0:21:07] And there – yes, it's very draining; it is. It's very draining. And so, it's – and particularly if you then look at – looking at that person in the context of an organization that doesn't understand what they're doing; doesn't know how to measure what they're doing. Doesn't really know where they should sit. So, it's how are they then looking at that person as an individual to make sure that they are being looked after, that they are being supported. And also, looking to make sure that they've got somebody that they can go to. 

‍

Because quite often in these smaller companies, they don't have a manager as such; they're just assigned to marketing or technical documentation or, as I said in some cases, sales. So, they don't always have a manager who understands what their role is. So, there's definitely burnout within dev rel, without a question. [0:22:17]

‍

Louise Ogilvy:  [0:22:17] Yeah, and there's a misconception developing in some companies that developer relations people are like social media influencers. There was some discussion about it recently; somebody'd seen an ad for – it was for a dev role, but candidates must have a minimum of 5,000 Twitter followers. Just head in hands, it's like, oh dear, you're just not getting it. [0:22:43]

‍

Louise Ogilvy:  [0:22:44] No, because there's so many – you will know this – so many different elements to the role. You've got have the technical expertise; you've got to be able to write blogs and write content. You've got to be comfortable talking to people. You’ve got to be able to participate- [0:23:06]

‍

Richard Rodger:  [0:23:06] Public speaking, right? It's- [0:23:07]

‍

Louise Ogilvy:  [0:23:07] Yeah, public speaking. [0:23:08]

‍

Richard Rodger:  [Inaudible, 0:23:10], right? 

‍

Louise Ogilvy:  [0:23:12] Yeah, absolutely, public speaking. Being comfortable to go to a conference and be on a stand and talk to people when they come up to you. And the difficulty we have at the moment overall is that it's not that new; it's been around for a couple of years, but it's gaining traction. 

‍

But I'm not sure whether there are enough parameters, let's say, around expectations, career progression for individuals in the role. I have seen quite a few people where – that I've been talking to, who have been a developer, gone into dev rel, gone back to being a developer again. 

Because where do you take that career and who's there to help you manage your career moving forward, if dev rel is the path that you want to take? 

‍

So, it's quite an insular role, and in order for it to expand, there needs to be more talk about it; there needs to be more awareness of what it is. More talk about how these individuals are managed, looked after, and how do we look at their career trajectory as well. [0:24:38]

‍

Richard Rodger:  [0:24:40] It feels like we're only at the beginning of defining industry best practices. I have to thank you on behalf of the community, because you're a great sponsor of the various conferences like DevRelCon and that sort of thing. And that's how it starts, with the community coming together for that. The bad news is, as developers, we've been at this since the 1950s; we still don't know what we're doing. Maybe because dev rel is broader, there may be an easier time of coming to some basic best practices. The measurement- [0:25:15]

‍

Louise Ogilvy:  [0:25:15] That's it. 

‍

Richard Rodger:  [0:25:17] -such a challenge. 

‍

Louise Ogilvy:  [0:25:21] It is; it really is a challenge. Because when they're working across so many different channels, and it's how do you – let's just say you get 10 new customers in one month. It's quite difficult to be able to say, "That customer signed up because they watched a conference that you gave," or you answered a question in Slack channel that showed as a business that you understood the pain point and that the product you've got is a true solution. 

‍

There's so many amazing blogs and people that right about metrics within dev rel. But truthfully, I don't think it's ever – I don’t think we're ever going to have a definitive answer. In sales, it's – you made 100 cold calls. You spoke to 20 decision makers; you booked five demos, you made one sale. It's very quantifiable. But within any marketing – because ultimately, it's an element of marketing. With any marketing awareness function, it's not as easy to be able to say you did this and it resulted in that. So, companies- [0:26:47]

‍

Richard Rodger:  [0:26:48] I tell you, Louise it's – speaking as a developer who's made purchasing decisions from tools companies, sometimes it's something as ephemeral as the vibe that they give off. Is it a developer friendly brand? And it's not related to the number of blog posts or the number of sample apps or the documentation. It's just the general feeling that you get that developers are valued by that organization. [0:27:20] 

‍

Louise Ogilvy:  [0:27:21] Absolutely. There was a post on LinkedIn a couple of weeks ago now, talking about a very popular internal developer portal, which I shall not name. And there was talk about – part of the reason why companies – and I've had this conversation as well. Part of the reason why companies are using that specific product, if you like, is because it comes with a community of users. 

‍

That was a big thing for a lot of organizations, which is, not only are they interested in the product or the platform that they're purchasing, but what came – what comes alongside that was a whole community of other users. So, they felt that there is an open source. They felt that there was a whole community there that they could dip into and ask questions. 

‍

And I don't – we can't underestimate the importance that developers put on a community. I spoke to a wonderful dev rel candidate a few months ago, whose job it was to manage an open-source – I can't quite remember what it was specifically, but anyway. And what she said was, a big part of her role – every time somebody new joined that community, they got a welcome. 

‍

It was very important to her that each and every new community member was welcomed into the group. That in itself isn't necessarily going to result in an increase in revenue, but if people talk about the feeling that that community gives them, then further down the line, people talk about it. It's a very interesting area. [0:29:24]

‍

Richard Rodger:  [0:29:26] Yeah, we need to move beyond these very simplistic metrics of impressions or views or whatever it is, stars on GitHub. It's – we collectively, as a community, need to talk about this more. I haven't – I've read every blog post about it from everybody, and we have people new to the industry; we've people who have been around for ages. 

‍

My own experiences in a previous company were just that the founders – I was one – we intrinsically valued the activity. We were a consulting company, but we ended up with something like eight speakers and open-source people, whose job it was to just do open source and talk about it. And that was just a services company; we didn't have any tooling. And we never – we were developers, so we didn't know what we were doing. We never considered the idea of measuring what those people were doing, but that would have been crazy. [0:30:37]

‍

Louise Ogilvy:  [0:30:40] You talk about measuring, and there are definitely some companies for whom it's not important. They understand that the dev rel function is contributing overall, so they're not worried so much about being able to justify having a dev rel function. However, my concern for that is, what about the individuals themselves? Because we all know, we're all human beings, and we like to know that we're doing a good job. If you want to look at rewarding – when it gets to end of year performance reviews and all those type of things. 

‍

So, it's great in one respect to say as a business, "We're not worried about measuring how successful our dev rel person is." But from a personal point of view, I actually think those individuals might like to know how they're doing. So, it's not just for the benefit of the organization, but it is also for the benefit of the individual who's in that role to be able to somehow get to the end of the year and say, "You've done a great job." So, I do think there needs to be some form of looking at how you attribute what they're doing to the success of the company, if not for anything else but from a personal career point of view. [0:32:14]

‍

Richard Rodger:  [0:32:14] I feel like that's an important insight. Because you're asking us to separate measurement of the developer relations activity for the business versus the personal performance measurement for individual people, which as you rightly say is necessary. One needs to know one is doing a good job. I wonder is part of the problem that those two are being conflated? [0:32:42]

‍

Louise Ogilvy:  [0:32:44] Yeah, very possibly. And maybe there's just – maybe it's just that it's not being discussed potentially. There's an argument to say if you're not being measured, then you can't be judged. And maybe not everybody is concerned with that, but if you think about it, my job on the recruitment side is very much talking to candidates generally about why do they leave roles, what's important to them. 

‍

And whatever role it is, some of the common themes that come up is not being supported, not feeling part of the business. And so, my worry, I suppose, is how many people in that dev rel function are feeling that way in these smaller organizations, and how do you overcome that to make sure that they stay and they flourish? [0:33:45]

‍

Richard Rodger:  [0:33:47] It is a significant open question, because if you think about the structure of these companies, once you're successful like GitHub, you have many developer advocates. And they have their own team and they're – and the business doesn't need to measure them as such. Because it's obvious that they're an essential part of marketing, and anyway, the business is making millions, so it doesn't – the pressure isn't there. 

‍

And then you have startups, even series A startups, which are maybe 20-30 people. And there's a developer team, maybe a front-end team and a back-end team or whatever. And then an individual developer advocate, who isn't in any team, but is the subject of jealousy, because they're all swanning around the world going to- [0:34:35]

‍

Louise Ogilvy:  [0:34:35] Travelling around the world, yeah. [0:34:36]

‍

Richard Rodger:  [0:34:38] Not half as much fun as-

‍

Louise Ogilvy:  [0:34:40] It's not, no. 

‍

Richard Rodger:  [0:34:42] So, they – yeah, they're on their own. [0:34:45]

‍

Louise Ogilvy:  [0:34:46] Yeah. Quite often they are; quite often, they are on their own. And a lot of it comes back down to that very early stage before you hire. So, if you're at a point where you are thinking about bringing somebody into the dev rel role, then my advice to founders or hiring managers is, you need to have an idea of what you're expecting that person to do; how you're going to onboard them into the business. Where is the best – which is the best team for them to be assigned to; how do you include them in everyday business functions. 

‍

And also, I read a blog post the other day about – that a dev rel person had written, and said that on a regular basis, they do talk to the rest of the company, the developers etc. about what they're doing, so that there is a – within a business, there's an understanding of what that individual does. Because I imagine there's very many cases where you've got the dev team over here; you've got product over here and then you've got the dev rel person. 

‍

And it's assumed that everybody knows what they're doing because they're dev rel. But as you and I have said, I firmly believe that there are people within those companies who don't know what their colleague is doing. So, it needs to be talked about openly; incorporate that into discussions about what's going on within the business, and make part of that talk about what dev rel is doing. So, that hopefully reduces that feeling of isolation. [0:36:44]

‍

Richard Rodger:  [0:36:46] We have nearly run out of time, Louise, but I have got a question. I've got a final question, which might be a bit awkward. In the market, are you seeing companies paying dev rel people more or less or the same than normal developer staff? [0:37:04]

‍

Louise Ogilvy:  Interesting. I still – there's a difficulty sometimes, when I'm talking to companies, to get them to talk about what's the budget for the role. Because sometimes I don't necessarily feel that they know what that is. So, it's not as easy as – we can benchmark software developer salaries. We can look at what does a software developer get paid in the US; what do they get paid in Europe; what do they get paid in the UK. So, it's much easier to be able to come up with a salary budget for those roles. 

‍

Whereas, because as we've said, dev rel is still, compared to software developer, extremely new, there isn't much published out there about salary levels in developer relations. I would say from my experience that they're probably on a par; I wouldn't say they're more or less. Because a lot of the time we are looking at software developers going into dev rel. 

‍

So, I would say from my experience – we talk about salary levels. There is a – I'd say they're being paid or budgets we're talking about is very similar, because ultimately, a lot of them come from software development roles. So, at the moment, I don't – at the moment, I'm not seeing – software developers' salaries have increased dramatically as we know, but I would say that at the moment, they're on a par. [0:38:49]

‍

Richard Rodger:  [0:38:51] Interesting. I've seen cases where they're less because less code is being written, and community work and all that is seen as less special, even though it's a very hard skill. And other times, I've seen people being paid more because they're seen as – they've written a book, so they're higher levels than the ordinary dev. It's going to be interesting to watch that one and see how that washes out. [0:39:19]

‍

Louise Ogilvy:  [0:39:20] It will, absolutely. 

‍

Richard Rodger:  [0:39:21] Louise, thank you so much, very interesting perspective, and great to get that perspective on the developer advocate role itself. That's – this is the first time we've had someone on who's had this insight into the industry. Thank you so much. [0:39:39] 

‍

Louise Ogilvy:  [0:39:40] No, thank you. Thank you very much indeed for the invite. [0:39:43]

‍

Richard Rodger:  [0:39:44] Awesome. I'm sure we'll talk again. Take care. [0:39:46]

‍

Louise Ogilvy:  [0:39:47] Yes. Thank you so much. Thank you. [0:39:49]

‍

Richard Rodger:  [0:39:50] Bye-bye. 

‍

Louise Ogilvy:  [0:39:50] Take care. 

‍

Endnote

‍

Richard Rodger:  [0:39:52] You can find the transcript of this podcast and any links mentioned on our podcast page at Voxgig.com/podcast. Subscribe for weekly editions, where we talk to the people who make the developer community work. For even more, read our newsletter. You can subscribe at voxgig.com/newsletter, or follow our Twitter @voxgig. Thanks for listening. Catch you next time. [0:40:19]

‍