Decrypt with Evervault: Richard Rodger from Voxgig

Listen on:

• Spotify
• Apple Podcasts
• Amazon
• iHeartRadio
  

This episode of Decrypt is a conversation between Liz and Richard Rodger, Founder and CEO of Voxgig, a Developer Relations (DevRel) company offering tools and services for software companies looking to connect with developers, build communities, and measure the success of their efforts. Voxgig has evolved in its focus over the years, but the one thing that has remained constant is the company’s dedication to helping developer advocates, conference organizers, and other professionals working in the space to maximize impact and achieve their goals. Additionally, Richard hosts a podcast where he talks to the developer community about developer relations, public speaking, and community events. Before founding Voxgig, Richard co-founded nearForm, one of the world’s leading providers of large-scale Node.js and microservices solutions for enterprises.

A few highlights from their conversation include:

• 07:32: How being an active part of a community can lead to professional fulfillment and opportunities
• 21:00: Why mixing products and services can work well when it comes to DevRel
• 27:11: The ideas around the four pillars of DevRel
• 36:30: The importance of technical leadership being involved and continuing to write code
• 38:11: How to learn more about DevRel by attending the monthly meetup at devrelmeetup.com

Listen to the full episode on YouTube or wherever you get podcasts. You can find Richard on Twitter @rjrodger and on LinkedIn.

Liz (00:26):

Hey, Richard, it's great to see you today.

Richard (00:28):

Hey, Liz, thank you very much for having me on. Happy to talk about all things developery, technical.

Liz (00:37):

Yeah, I've been really excited to speak with you because you've had such an interesting career path and now are focused on running a company that's all about developer relations. So super excited to pick your brain and just hear more about you. So can you tell me a little bit about your career in tech and how you got started?

Richard (01:00):

I studied philosophy and mathematics because I didn't know what to do. It wasn't even my first choice. I think my first choice was theoretical physics. Thank goodness I didn't get that one because I would've failed. Not very good at maths, but the mathematics department had their own free BSD Unix servers and they had VT 100 terminals. This is sort of mid-nineties. Green screen VT 100 terminals. So I learned original Vi, not Vim, actual vi. And amazingly enough, they let you have your own home directory and they let you run CGI scripts. And if you're new to this game, go look it up. CGI scripts, the way we used to do things. Back in the old days, they let you run your own CGI Pearl Scripts. I had been doing summer jobs in warehouses, which it was good money, but it was hard work,

Liz (02:14):

I can imagine.

Richard (02:18):

And a classmate ended up working for RTE, which is the national broadcaster in Ireland, doing their teletext system, coding. And I thought, oh great, that's indoor work with no heavy lifting, which is great. I wrote a little demo application. I think I wrote a little, I used the internet as it was, as then was to find about 70, I suppose they were web agencies or companies that did anything technical in Dublin in Ireland. And I wrote a little spam script that sent them an email to say, please give me a summer job, CGI scripts in Pearl.

(03:08):

And one of them took a chance on me and I just ended up working for them all the way through final year. And then for a couple of years afterwards, late nineties, building websites in Pearl and Java, real old school stuff. And then I moved to, well, my wife is a translator, so she got a job in SAP in Germany. So we moved to Germany for a couple of years and then we came back and I set up, I suppose it was my first startup, it was a company selling software components in Java. So developers from the start, and I did my own developer relations. I wrote my own forum and all sorts of stuff and had very good documentation and all that sort of fun stuff. But the thing that I missed in all those years, so that maybe takes us up to sort of 2007 maybe, in all those years, I never went to one meetup or attended a single conference or joined any sort of mailing lists or any of that sort of stuff. I was the proverbial hoodie wearing developer in their bedroom, not speaking to people.

(04:32):

And then through other jobs later on, startups and then companies that I co-founded and particularly the Node JS wave when that started around 2010, 2011, discovered community, massive revelation that you can actually have a shared interest group, you could talk to people about this stuff, and they were nerdier than you were about stuff. I realized I'd been missing out for years and years. I'm an introvert by nature, so it never sort of occurred to me that going out and speaking to people would be fun. And through that ended up in, I guess as CTO of company, as a developer in a developer relations role.

(05:30):

I used to describe, because I used to do all the conference calls, about in the early days of adopting all that type of stuff. And I used to say I was a performing monkey because that was what my job became was get another slide deck, get another plane trip, yet another conference. It's funny because you start off with this sort of fear of public speaking and then you get used to it and then you get very, very casual and you start doing your slides while the other speaker is finishing their talk, which I don't recommend.

Liz (06:07):

I can definitely relate to that because I remember when I first started out in DevRel, I would be so nervous I'd prepare things so far ahead of time, I'd practice for loads of people. And then after you do it enough times, you kind of get a little in your ego about it. You're like, ah, no, I got this. And then maybe you get away. Personally, I would get away with that for a couple of times and then I'd have a demo totally fail, and then I was like, all right, I need to go back to fully practicing.

Richard (06:39):

No, you don't need that stress. Do prepare your talks. If you learn one thing from this interview, preparing your talks is generally a good idea. Yeah, I think for me, that was the biggest change in my career and the most wonderful thing to discover was the power of community. I got really into different coding, different languages, got really into extreme programming and agile, got really into entrepreneurship, all that sort of stuff. But none of them have the same transformative power in terms of, I suppose, success, personal satisfaction and happiness in the work, but actually joining, actually becoming part of community did.

(07:32):

And I think that's the biggest kind of takeaway. And I think nowadays it's a lot more known. It's a lot more obvious that being part of community is a good thing and companies actually pay for it and all that sort of stuff. And you can kind of find yourself a job just by joining communities. We recently hired a really, really cool developer advocate, a guy called Louis Meyers. He's based in the US. I've never met him in person, but we noticed his community engagement was awesome. Okay, well, we need to hire this guy. He's really, really good. So you can literally get yourself a job just by participating in community now, which is wonderful. So yeah, I mean, that's the thing I sort of envy, I guess, for people coming into the industry now is that it's a lot healthier that way.

Liz (08:36):

And there's, I guess more clear paths forward because I could imagine when you started out it was really probably very new. And even I will get, I'll tell people my job title or what I do, even other people that work in tech, and they'll be like, what is that? So it's definitely still not totally ubiquitous, but I do think there are more defined paths and wondering what that was like for you organically shifting into that in just what you were already doing?

Richard (09:15):

Yeah, so I'm definitely one of the, oh, people who sort of go, oh, actually it's called developer relations and a lot of people my age, so I've been coding since I got that first job in 96, a while, but a lot of people at my level, so if you haven't gone off to do pure management or whatever, if you still code, you were doing developer relations for a long time. It was kind of like an adjunct to the job. You still had to do all your normal work and then try and prepare a conference to talk or try to persuade your boss to pay for you to go to a conference to present it. But then what happened is the people that you met at those conferences turned out, they became customers.

Liz (10:11):

Right.

Richard (10:12):

Anybody with any sense paying attention suddenly realized that this is a massively successful sales channel and has only become more so over time in terms of just generating really easy inbound wins on the sales side of things. The trouble is, and this is the challenge that developer relations has always had, is that you could speak to somebody after giving a talk. They might come up to you and ask a question or two. So this literally happened to me. I had a guy come up to me at a conference in 2013 and asked me a little bit about microservices that I was talking about at the time. Turned out he worked for McKinsey. And days later, McKinsey was a big client.

Liz (11:04):

Wow, that's a big one.

Richard (11:07):

And there was a lot of other stuff that happened, and I didn't do the sales side of things. A great co-founder is really good at sales who kind of moved to the next level, but you can say that that developer relations activity had a payoff. And there's other examples where you can see that, you can see that just by meeting people at a conference, you eventually end up with good business revenue. The problem is it takes two years or a year or three years.

Liz (11:38):

Yeah. The cycle is so long and it can be hard to, I guess, quantitatively tie the two actions together. I mean, there's a lot more tooling around that now, and I think you all do that a little bit yourselves, right, but yeah, it can be very hard. It's such a great story. It's funny because when I met Shane, who's the founder of Evervault, we were at a conference and I was working for Twilio at the time, and he was like, oh, we love Twilio. We use it for a lot of our demos and quick starts. And he said, I think I found out about Twilio because I was at a hacker space and I just picked up a sticker because I thought it looked cool, and then I looked into what it was, and then I started playing around with it. And there's so many stories like that where it's this very clear DevRel activity that ends up leading, as you mentioned, to a customer or engagement of some type.

Richard (12:36):

Absolutely. You worked as a DevRel for Twilio?

Liz (12:40):

I did, yeah.

Richard (12:41):

I'm flipping it out, asking you questions, sorry. But that's kind awesome because Twilio is kind of famous for having this awesome DevRel execution.

Liz (12:51):

I stumbled into it, to be honest. I was working as a software engineer, and I had a background in more content marketing and journalism, and I really loved coding. I mean, I still really do enjoy it, but I also kind of missed my old work. And I was a part of this women in tech group, and I met somebody else who worked at Twilio, and when she was talking about her job, I was like, that sounds like a job I would love to do. I just got super lucky that it ended up being this amazing team of people who were so willing to mentor me and show me the ropes.

Richard (13:27):

It's great that it's a job now, we were talking about that earlier. It now is a rope. You can aim for it as a career goal and be valued for what you do.

Liz (13:42):

So you were heading up a Node JS shop, and then you decided to go and found Fox Gig. I guess what was the decision factor there? What made you decide, okay, I'm ready to do this?

Richard (13:56):

So it turns out companies have kind of a DNA, and when you work in a consultancy, that company was founded, I think the original idea, we tried to build a whole bunch of products, but I think the original idea was something like Firebase for mobile apps. And the problem is we made too much money building Node JS systems because Node took off at the same time that it got founded. And it's just really hard to say no when people are waving money at you.

Liz (13:56):

Oh yeah,

Richard (14:34):

Please build us another node-based system or whatever. And eventually the hiring and all that sort of stuff ends up generating, people are really good at working with clients and working to schedules and managing client expectations and selling to companies that need staff augmentation, all that sort of stuff. And I had always wanted to do a proper B2B SaaS product that scales and has nice gross margins and all that sort of stuff. And yeah, I told you I started coding in 96, so you can see that sometimes it's easy to get comfortable, and if you're going to do something, you kind of have to decide to do it. So I decided it was kind of time. I had got a bunch of experience speaking at conferences and internally managing that experience, deciding where to speak, where to travel. I ended up speaking at all sorts of places, but you'd end up at a meetup that only had five people at it, and you'd flown there, and that's great fun, but it's not really aligned with the business's goals, let's say. So I didn't find that there was any real tooling for speakers as such,

(16:17):

And there still isn't. I still haven't found anything that really meets those needs. So I decided now or never, it kind of exited that business. And then with the money from that exit, set up Fox Gig as a SaaS B2B startup and built enterprise tooling, B2B tooling around the speaker role more than developer relations itself and helping in-person event organizers do things like run call for papers, helping people run booths, all that sort of stuff. So going great. That was a really cool business. We were helping people like Disney plus at the time run, because they were hiring loads of developers to build their systems. It was all going wonderfully until March 30th, 2020.

Liz (17:24):

Oh, Richard, do I relate to that, yes.

Richard (17:34):

Yeah. I mean, you plan and God laughs. So I spent the whole month taking calls from customers saying, yeah, we're going to cancel, and revenue was zero. So by March 30th, the revenue went to zero, and we built up a team in the UK. That was kind of the primary focus. So we kind of had to let them go and wind that down, figure out what to do. I was extremely lucky with the board and investors that I had, whose advice really was just go into hibernation, stop spending money, watch, wait, and listen, see what goes on. We experimented with a bunch of pivots around virtual events, that type of thing. We even thought of a pivot into no code, because we had built this platform.

Liz (18:34):

Oh yeah.

Richard (18:35):

So if you think about events, right? Events have tickets, they have attendees, they have organizers, they have speakers, they have vendors, they have venues. On the day of the event, you might be broadcasting stuff live. Events and event software is incredibly complicated. There's loads and loads and loads of different things. We built a whole bunch of functionality that's actually super useful for a whole load of different use cases that are not related to events at all. So we ended up thinking about how do we leverage what we have into something that's actually useful for people? And the one thing that survived Covid was developer relations activities. So that's where we ended up with the pivot. It took about two years to figure out.

Liz (19:46):

It makes sense, right? Because it seems like based on the ecosystem before Covid hit, I remember when I joined, I was so excited because I was doing a lot of, I was meant to do a lot of in-person hackathons, in-person conferences, and yeah, I think I had two months of that before then we were like, all right, we got to figure out how to do all of this virtually. And I think we kind of lucked out because a lot of the partners that we were working with and companies we were working with were really trying to figure out how do we keep morale up? How do we keep people engaged and excited?

(20:23):

So there was this sort of demand for actually having hackathons and events even virtually. But then there has been quite interesting shift, I think then back into, okay, now things are opening up again. How do we get back to this world? What does it look like now? And I think that as much as having that very narrow focus initially probably worked very well for you, I can imagine how broadening it, and especially because you have so much experience and know what to look for in the people that you're hiring. That seems like it makes a lot of sense.

Richard (21:00):

We have to give up the idea of being a pure B2B SaaS company because the developer relations space is a bit broader. So there's tooling around developer relations, which is similar to the tooling that speakers would need to organize their talks and that sort of stuff. But a lot of developer relations activity, especially for startups, involves rolling out an API, rolling out SDKs, managing Bose, helping clients do integration work, that type of stuff. Some of my business advisors are tearing their hair out because you should never mix product and services. But that's kind of what we're deliberately doing because there's a core developer relations product, we're going to relaunch that later in the year, but then a lot of the work that we do is very consultative in nature. I just put in a proposal to a company earlier a couple of days ago that they hadn't figured out how to engage with open source.

(22:21):

So they're looking at, their GitHub is kind of not a wasteland, but there's nothing happening. They didn't really understand how they would go out and find the sort of natural ambassadors, people who were just randomly interested in what they were doing and had built little versions of their APIs or SDKs. So they had SDKs for the major languages, but someone had gone and just built a rust one because they needed a rust one, I guess. So there's obvious advice like buy that person a T-shirt at least, but also bring them to the next conference, pay for their fare or whatever.

(23:04):

And a lot of companies are set up around the traditional sales model where you have SDRs and funnels and all that sort of stuff. But I just keep going back to, I met a McKinsey consultant at a conference and two years later ended up with some very big deals. So I think developer relations, if you do it right, enables that kind of, enables a sales process where you create all this sort of natural inbound interest and it's very, very strong. Because if I'm using an encryption product now, and obviously I have built against Evervault.

(23:55):

But if I have a client that has a need for encryption now, I've already invested as a developer in learning your APIs. So unless it's a terrible fit, Evervault is the first protocol. So if you have an API or an SDK and a service and you've built a community of open source developers and developers that have attached themselves to you, now they're generating a huge amount of inbound because they recommend stuff. So if I'm building a website for somebody, oh yeah, we don't do this too much, but if I'm building a website for somebody who's completely non-technical and they say, oh, I need encryption, they're not going to decide. That's part of my technical service is saying, oh yeah, these guys are the guys to use. I think there's a huge challenge in developer relations to integrate that into the sales process and measure it effectively. One of the themes this year that's going around the developer relations community spaces is companies cutting developer relations staff, part of general cost-cutting and layoffs, which is crazy.

(25:23):

It's super crazy. I don't think they realize how much developer relations, how much business that actually generates by that mechanism. It blows the mind. I can't understand cutting developer relations at all, especially when you're trying to increase sales. Doesn't make any sense. But we do have a job to figure out how we demonstrate value, unsolved problem.

Liz (25:53):

Yeah, I totally agree with that. I think one observation I've made as well is that because so many folks that work in DevRel tend to wear a lot of hats that sort of cross different areas of the business. I think sometimes there's this perception that, well, they're doing a little product stuff, they're doing some community stuff, they're doing some marketing stuff. Well, we can just have, they're doing some engineering. Maybe we can just have people that already work in those areas cover it. But the problem is that I think people that do work in DevRel are able to see the connections that exist across all of those different areas. And when you don't have people that can look at the big picture and say, oh, we should be doing this tactic to cover X, Y, and Z, then it just doesn't get done. It's just not happening.

(26:44):

And I think community is something that I am figuring out a lot right now, personally, and I think that you have to nurture it. It has to be an active ongoing thing. And so if you kind of just let it sit or you have this open source project that you're just kind of like it's out there, but we don't really know how to engage, then it's like you're not going to get any of the value that you were hoping to get from that particular idea.

Richard (27:11):

Yeah, it's a good insight. So I had a guest recently on our podcast, a guy called Jason Sincere. He works for a company called sitecore.com, and he was saying you have this kind of cliche that the three pillars of DevRel are code, content and community, he was saying maybe there's a fourth one, which is to be cross-functional.

Liz (27:35):

Yeah, absolutely.

Richard (27:36):

See the big picture, just because of your position, and also when you're out going to even small meetups or whatever, participating on Discords, by osmosis, sort of picking up the vibe of your community, even if it's sometimes hard to articulate, you just get a feeling about that feature is going to resonate, but the other one probably not. So for product people, you need to be listening to your DevRels. They can smell stuff.

Liz (28:15):

The power of the vibe is real. And I do think, yeah, and there's just so many little casual hallway conversations that I think you have this idea that, oh, that doesn't really matter, but it actually does, because I think your McKinsey story is a really powerful one. And there's so many other stories that I've heard or experiences that I've had that speak to the impact of just connecting with someone even in maybe what seems like a very small encounter.

Richard (28:47):

And I think especially if you haven't done it before, it feels intimidating to try to set up community or try to engage. And people can do it in a very ham fisted sort of way as well. You can't just stomp into a meetup and start buying all the pizza or whatever, because sometimes if it's a community meetup, they don't want a company to do that, but somebody has to have the job to go out there and just keep their mouth shut and just listen in a very intentional way to start understanding the culture that they want to be part of. And it's very, very different from traditional sales and traditional marketing. That's why I think there's another decade to go before it's fully integrated into the structure of software organizations.

Liz (29:59):

Yeah, I absolutely agree.

Richard (30:01):

It's a great time to be involved.

Liz (30:05):

I really want to ask you this because this is a question that I've been chewing on, and I would love to get your insight. So Evervault is very much an encryption API and platform that's meant for developers. We focus a lot on developer experience, but we also kind of have this weird crossover into the security space and the data privacy space. And I think it's been a big challenge to figure out how to straddle that or even integrate it. And I'm wondering if you've seen this type of company or product before where it's kind of part of a couple of different spaces and how to effectively serve that.

Richard (30:55):

Yeah, so Evervault has a little challenge there because there are a lot of SaaS companies like Twilio that are very much, you focus on the developers and then you can orientate a lot of stuff around that. And then you have other types of companies that the service is more of a business service, like the security anti-fraud stuff. Yes, developers are involved, but they're not. Their influence is less, and they're definitely not decision makers. And what we've found interacting with our clients is those are two modes of developer relations and they aren't, and the one that's more developer focused. In that case, you're putting a lot more effort into open source and the community and smaller meetups, and you're trying to make sure that your developer brand is credible.

(32:09):

You're behaving according to the sensibilities of developers. But on the other side where your primary clients are more business focused, leaders are the ones actually making the decisions. Then your developer relations, because you'd often get assessed by a CTO or VP of Eng who's not coding themselves. At their point in their career they've kind of moved beyond that. So then you're in a situation where the professionalism of the documentation, the case studies, the tutorials, the ability to have partners that you can pull in to help with implementation, or maybe you have a services team yourself, that type of credibility is important.

(33:03):

So yeah, there's a little bit of a challenge I think for Evervault on that because you're in both worlds and you kind of have to serve both, but startups are fun. Nobody said it was going to be easy. So yes, a lot of companies only have to do one or the other, right? Have to do one or the other. We did an integration with a Tango cards, so they do rewards, recently. That's very much in the sort of business category. So I don't think Evervault can skimp on developer relations on either side. I think given the nature of your business, there's a significant payoff to investing in both. But that means in terms of the marketing cost mix, it has to be a higher proportion for Evervault because you want to serve both of those markets.

(34:10):

And I mean, unless at a higher strategic level, you decide to refocus on one or the other, I think they support each other. They definitely support each other. But your work is definitely harder than the average DevRel organization. There's no silver bullet. It's just hard work.

Liz (34:36):

Yeah, honestly, that's such a good soundbite. It's true. There is no silver bullet. It's just hard work. And I think something you said earlier just about listening is so true as well, kind of listening and adapting, not necessarily, because I did that too when I started. I wrote up this whole plan and I was like, we're going to do this and this and this, and then a month and a half in, I was like, oh, actually, a couple of these ideas just don't make sense at all now that I know the things that I know. So yeah, I think being adaptable, whether it's due to a major world crisis or just some idea that you had not really turning out to fit with the actual goals of the business is a really important skill. And I do think it's a skill. I think adaptability is something you can cultivate.

Richard (35:27):

Yeah. Yeah. There is no, that's definitely true, right? There is no one true way to do developer relations. Definitely not. And as the volume and quality of content gets higher and higher, if you look at a company like Intercom, this is not quite developer relations, but it's similar. If you look at a company like Intercom, back in the day, they just said a whole bunch of blog posts about a customer engagement and that type of stuff, and it worked. Happy days. They've got a unicorn out of it. Des Trainer, I think he wrote all those, but that wouldn't work today. That wouldn't work. Now I see a former colleague of mine, a guy called Mateo Kalina, he has a new startup called Platformatic. He's a CTO, but once a week he's on Twitch doing live coding.

Liz (36:26):

Nice. Yeah.

Richard (36:30):

So I think you can't just say, oh, there's a playbook. We're just going to execute that. And the other thing I think Mateo's activities demonstrate, and of course Eoin and Evervault has done a bit of this himself, is you can't delegate developer relations completely. The technical leadership has to be involved. And you know what? If you look at Amazon, if you look at Verner Fogels or Jeff Barr or people like that, the very senior leadership. They're out there doing developer relations.

Liz (37:12):

They are. Yeah.

Richard (37:13):

You can't just say, oh, there's a DevRel team. That's it, right? They go write blog posts and go to meetups, but the C-suite needs to be doing developer relations as well. I think you don't get credibility if that's not happening.

Liz (37:32):

Absolutely. It's such a good point that it is very necessary for credibility for folks at all levels to really be able to speak technically on behalf of the company.

Richard (37:45):

And the CTO should code. That's just a personal, a little bug there. CTO should never stop coding. But yeah. Well, we'll let that one pass.

Liz (38:00):

Richard, it's been so great speaking to you. I've really enjoyed this conversation and gotten so much from it. Is there anything else that you want to share before we wrap up?

Richard (38:11):

Yeah, just a little pitch. We run a monthly developer relations meetup. It's completely virtual. So the reason we went online is to make it more inclusive. And so we have an audience from all over the world, and we try to get a very wide range of people practicing DevRel from people just starting to people who have exited companies and all that sort of stuff. And it is meant to be a community of learning and a community of practice. So I personally believe that we've got another 10 years of figuring stuff out before we really know how we're supposed to do DevRel. If the Node JS experiences has anything to go by, it took us 10 years to figure out promises. So it'll take 10 years before there's really a well-defined understanding of how to do DevRel in all sorts of different circumstances. So it's a great journey. It's a great time to be involved in this particular business activity. Yeah, so we're just helping each other learn. So devrelmeetup.com.

Liz (39:28):

Amazing. Yes, I have been to one, and I can vouch that they are incredibly useful and a very, very nice community, very open. So I'll be attending more in the future, and I hope that some of our listeners will as well.

Richard (39:41):

Fabulous. Thank you so much Liz. Thank you.