Richard Rodger:  [0:00:01] 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.

Let's talk to Alvin Bryan, who is a developer advocate at Contentful. Contentful is a classic SaaS startup, and Alvin's role is a classic developer relations role. He's new to the game, has only been doing it for six months so far, and is eager to tell us how it's going. The interesting thing is that Alvin has made a deliberate choice to move from front-end development into developer relations. And for anyone else thinking of making that career change, this will be a particularly interesting podcast.

In particular, we talk about the importance of having a connection and an understanding for the product that your company is selling. You can't advocate for something that you don't feel any real passion or interest in. We also talk about thinking where to position yourself in the three Cs of developer relations: code, content or community. You don't necessarily have to do all three. You can certainly focus on one, where you can provide more value to your employer.

Finally, we touch on the subject of whether developer advocates and those in the developer relations team should be involved to some extent in product development, for example, helping to build the SDK. This is an open question, and I've seen lots of different companies take lots of different approaches. Of course, in the very early days of a startup, everybody has to do everything, but once you're more established and you've built out your teams, what relations does the developer advocate have to the core product in terms of actual software development? All right, let's talk to Alvin. [0:02:07]

Main Interview

Alvin Bryan

Richard Rodger:  [0:02:08] Alvin, welcome to the Fireside with Voxgig Podcast. It is great to have you on here today, this very cold day. How are you doing?  [0:02:16]

Alvin Bryan:  [0:02:18] I'm good. It's good to be inside and not be outside. It's raining right now and it's just bad. [0:02:24]

Richard Rodger:  [0:02:25] We've just identified ourselves as being in the northern hemisphere. Hello to the southern hemisphere, you lucky guys, and your lovely weather. [0:02:31]

Alvin Bryan:  [0:02:32] It's a good time for a fireside chat. [0:02:35]

Richard Rodger:  [0:02:35] Absolutely. I was speaking to  some Brazilian developers yesterday and 23 degrees Celsius, whatever that is in Fahrenheit, 60s, 70s, something like that. [0:02:45]

Alvin Bryan:  [0:02:46] T-shirt weather. [0:02:46]

Richard Rodger:  [0:02:47] Very comfortable weather. Okay, let's get started. You are a developer advocate; you've moved into the developer relations career track. [0:02:56]

Alvin Bryan:  [0:02:57] Yes.

Richard Rodger:  [0:02:57] It's something new for you; you started off as a front-end developer. So, let's go through the story, because a lot of people are thinking of – maybe that's – maybe it's an interesting career change. So, how did you go from a traditional developer career path into dev rel? [0:03:15]

Alvin Bryan:  [0:03:18] I did a lot of dev rel stuff on the side. It's a thing when you're a developer team that you do talks and like to write articles and all of that. So, I do that for – a few things. I did local meetup groups, I spoke in small conference, nothing notable. But I did that for a while, but on top of a fulltime job, as you said, as a regular front-end person.

It was a lot, because preparing a talk is lots of work and rehearing and everything, plus travelling, and even if I was using local meetups to practice, like a lot of people are. But it got a lot. And even just maintaining a website and writing regularly, all of this is a lot of work. And so, I did that for a bit and then I stopped because it got too much.

And then two things happened around 2021 – I guess three things. Number one was, I was feeling – I was working at the Wall Street Journal; I was working on design systems and charts. And it was – for someone who loves front end, and interactions and data vis, it was a great gig. But I was feeling a little bit like the – again, this was 2021, so the last year, the previous year and a half, the news cycle and everything, it was a lot.

So, I started feeling the first signs of a burnout or – yeah, I guess it was burnout. I don't even know, but yeah, just this jadedness around the work that I didn't like. And I knew that I had done a lot of the dev rel stuff before and that I liked it. And at the same time, I stated teaching at codebar, which [Loss of Audio] Time: 0:05:19] me to talk about more, but it's a meetup; it was virtual at the time. It helps people who are learning to code.

So, people come to you with a problem, which could be anything. So, you – so the idea is, for every meetup, they try to have the same number of students and the same number of experienced coaches or tutors. People come in with a problem, which could be anything. It could be – I'm doing JavaScript basic. What's an array? What's this four-loop thing? I don't understand what's going on. Or I'm building this recipe app for my portfolio, because I'm more – I'm interviewing for jobs. And have – I have a book somewhere. I'm not really sure what's going on. Can you help me?

So, as a coach at codebar, this is what you do, This was a lot more on the teaching side of things, and I realized that I really liked it. And also, it was really nice to be very close to users and actual people. Because for my job at the Wall Street Journal, I was working on editorial tools. My audience was internal graphics reporters. If you consider the distance that there is my codes and an actual user of the Wall Street Journal, it was a lot.

Because my code goes to the graphics reporter, which then makes something which then goes onto the website, which then goes onto a user. Which – it's – there's nothing wrong with that, but the – with codebar, I had this immediate one-to-one relationship with someone in the context of teaching or them being an actual user of what I was doing. It was really nice.

And all of these things combined. And the third thing was that – again, the end of 2021, the market was crazy. Nothing like what we have right now. The – there was – every company, left and right, was struggling to hire. We had tons and tons of investment being poured in on lots of companies. There were tons of companies that had just raised millions in seed rounds and series A and B and whatever. And it just felt like the right time to try something new, so that's it. [0:07:44]

Richard Rodger:  [0:07:48] And it's – it sounds like you were born to be a developer advocate. [0:07:52]

Alvin Bryan:  [0:07:53] Nah!

Richard Rodger:  [0:07:55] What's interesting to me is, before you made this career choice, and before you worked at the Wall Street Journal, you were doing developer advocate stuff for your employer. And did your company support that? Did they fund travel or was it something that they tolerated? [0:08:15]

Alvin Bryan:  [0:08:17] Tolerated is the right word. And I think – no, they were supportive in the philosophical sense, in that if I needed to take an afternoon off to work on slides or whatever, that was good. It wouldn't be – I would never be able to take a week off, for example. But yes, so, they were supportive in that sense. But they never funded travel. When I was at the Wall Street Journal, this was during pandemic years, so there was no travel. [0:08:47]

Richard Rodger:  [0:08:48]Yes. No, that [inaudible] Time: 0:08:49.

Alvin Bryan:  [0:08:50] Between 2021 to 2022. Sorry, 2020-2022. So, this was – so – but even in previous employers because there were more than one, it was the same thing. People were happy that you did it, but they were not necessarily giving you that time or money to do that. I know there are tons of employers that do it; don't get me wrong. So, it's – I know for example in London there's a lot of companies that would open their offices to host meetups.

So, there's lots of employers who are really into that. I just never happened to work for them. The dev rel things were separate from my employment. And most of the time, I would also talk about things that were quite different to what I was doing on the day-to-day basis. It was mostly experiments I did on the side and stuff like that that I was more excited to talk about. [0:09:53]

Richard Rodger:  [0:09:55] Yeah, it's fascinating to me, because I worked with so many companies and founded a few. And the developer relations activity was really important to our success, to selling and to hiring. And even if people were doing talks and there was just a tiny little logo on the last slide, or there wasn't even a logo but they just said the name of the company, it paid off. The result – the return from that investment was huge.

I just find it really hard to understand a company that doesn't – when they have somebody like yourself who's willing to go out there and torture themselves producing content – that they don't – that they're not hugely supportive. It's – if – you have to gravitate towards the companies that do understand the value of what you do. [0:10:55]

Alvin Bryan:  [0:10:56] Yes, and it varies. It's just like there's loads of employers that recognize it. To me, it – as you said, one of the biggest points is hiring. There's companies that do understand the value of hiring and talent in general. And that's broadly where it sits, because some companies will be like, "We'll go – we'll be crazy with benefits," and they try hard to attract and retain people. And that's not all of them.

The Dow Jones – so Dow Jones/Wall Street Journal was one of them. It just it happened that it was 2020-2022, so nothing happened. I mean, a lot happened in the news but not in the conference spaces, not much happened. So, the – there is – looking at employers in general, that's where – to me, that's where the divide leads, where they're like, "For sure, we need to have a good image with developers because we want people to apply to us. We want people – we want to be an attractive employer for people to work at." And to me, that's where that divide is, for – between employers who understand that and those that don't. [0:12:21]

Richard Rodger:  [0:12:23] Yeah. That said, it seems – it feels like the understanding that there's a need for developer relations and the developer advocate role has certainly become well-recognized. I certainly hope so. [0:12:37]

Alvin Bryan:  [0:12:38] For sure. You saw that; you saw that in 2021 with all that startup investment that happened. For me, it was never at the right place to apply because I was new to the field, but there were tons. There were tons of people who had just raised – just went through a seed round. And they were like, "Right, we need a – we have a product. We have something. Let's get some – let's get a dev rel function going." And sometimes, even before actual marketing, they would hire dev rel before they'd hire even content writers. So, I agree with you. [0:13:22]

Richard Rodger:  [0:13:20] Yeah, that's not a bad strategy. So, you were doing dev rel style activities long before it was your official job. But now that it has become your official job and you've been doing it for six months, a year? [0:13:36]

Alvin Bryan:  [0:13:37] Six months, yeah. [0:13:37]

Richard Rodger:  [0:13:38] Six months. So, here's the cliché question. What was surprising in the role, given that you had done this type of stuff before, but when you're doing it for real, for money? What's different? What was stuff that surprised you about the orle that you hadn't thought of before? [0:13:58]

Alvin Bryan:  [0:14:01] There's two things. The first one is that you really have to work on the right product. It's something I had read online. It was one of the – because you read these generic advice type posts, which is, pick the right product; make sure you have a great team. And that one was a throwaway thing for me, but no, it's super important. Because you're – as a dev rel, you're talking about your product all the time.

But it's not just that; it's – you're immersed in your product. You're always in it; you're always using it. You're always talking about it. But what's most important is, you're thinking about all the problems that are around the product. For example, for me, at Contentful, it's all about the – I can relate to developers building websites, doing front-end stuff. And thinking about front end as a domain, I guess, as a problem in general, is what I like.

But for example, if I was – if I worked for Kubernetes, for example, which is this cloud dev ops thing that I have no clue about, it would be hard for me to relate to the actual – this whole domain of doing cloud scaling and managing servers and everything. Because a) I've never done it and b) I don't know what the – I don't know the audience.

So, it would be – it's not – it could be a great thing to learn, if you're willing to get in – I think it's a great way to get into a problem space if you want to dive deep into it. But if you happen to start your first dev rel job in a company that's not really your thing, you'll struggle. and that was a surprise, how much you're thinking about the surrounding – your product itself and your – the surrounding – all the surrounding ideas. And it's a lot of – it's an emerging; that's what I said.

And the second thing that surprised me – and it reinforces what I just said – at least at Contentful we get a lot of autonomy. There's no-one behind my back saying that – or with a plan that says, "You have to have 12 blog posts this year, two events – I don't know – four podcasts, whatever."

It's more like – we have goals; we have targets. It's not just a free for all thing. But how we achieve the goals and how – and even your day to day is pretty open. Sometimes we have concrete things, like we have – we know that there are certain blog posts we need to write. We know that there is certain features of the product that are coming up, that we are going to  need to talk about.

But the day to day is quite flexible and that's part of the nature of the job. Because it can involve so many things. It could be doing – organising an event one day and then writing a blog post another day. Then we've got a podcast, like I am right now. So, it's – and that's where this autonomy comes from. It's because you know there's such a – it's such a flexible, free-flowing stream of activities that happen all the time. It's just – it would be very hard to have this very task-based style of management. [0:17:39]

Richard Rodger:  [0:17:41] Yeah. Now, that's interesting. There is a wide range of dev rel structures. Certainly, some people that we talk to have a lot more formal measurement of their work. Do you guys do that at all in terms of measuring inaudible [0:18:00]

Alvin Bryan:  [0:18:01] Yes. Yes, maybe I didn't emphasize that. [0:18:04]

Richard Rodger:  Is that- [0:18:04]

Alvin Bryan:  [0:18:05] Yes. We definitely do. Maybe I didn't emphasize that enough. But yeah, we have goals and targets, and they're very clear. And we meet up; we have strategies, we have ways of achieving those goals. And we have these metrics that we're accountable for. But whether – would I need to do four or five podcasts? It's that type of thing. You know what I mean? Is it – no, it's definitely the sixth podcast that's going to get me there. It's very hard to make that correlation. So, I think that- [0:18:39]

Richard Rodger:  [0:18:39] Yeah, so that's what – that's where the autonomy lies for Contentful, which is the – they're relying on your expertise to understand the channels where you have to talk – where the developers are, or what content they're looking for. [0:18:51]

Alvin Bryan:  [0:18:53] Yes. And the great thing that we do – and that was such a brilliant idea from my boss, Jen. When we started, she did an exercise – and it's great – that she calls the Love, Like, Hate. We list; we go with a brainstorm. We list all the activities we can think of. And everyone in the team can put a card and say they either love it, like it or hate it. And that's a great way to assess what people want to do and their strength. [0:19:28]

Richard Rodger:  [0:19:29] Okay, this is developer advocate activities now, not like surfing or something. [0:19:34]

Alvin Bryan:  [0:19:35] No, yes. [0:19:37]

Richard Rodger:  [0:19:37] Yes. It's not – okay, it's slightly more focused.

Alvin Bryan:  [0:19:41] Yes. Not like eating. [0:19:42]

Richard Rodger:  [0:19:44] Barbecues. Staff barbecues. [0:19:46]

Alvin Bryan:  [0:19:47] Yes. Trying restaurants, yes, I like that; I love that. [0:19:51]

Richard Rodger:  [0:19:52] Dev rel activities if you look sideways. [0:19:54]

Alvin Bryan:  [0:19:55] Yes.

Richard Rodger:  [0:19:57] Yeah, that's – okay. [0:19:58]

Alvin Bryan:  [0:19:58] So, it's a great exercise, and that also helps determine. Maybe Alvin should be on a podcast because he likes it. Maybe – we have a new community person who just started – not just started, who started recently. And she's all over all the community stuff, for – obviously, she's all over being in online communities and talking to people and all of that, when a lot of us weren't. We were more about, yeah, let's go to meetups; let's write blog posts. And again, this is why it works; this is – it just means playing to your strengths really. [0:20:37]

Richard Rodger:  [0:20:38] Yeah, because the community engagement activity is different. I would – I'd say that it's a part of developer relations, but it is a specific skillset. And if you're not – if it's not something you're good at, it can be very difficult to do well. [0:20:56]

Alvin Bryan:  [0:20:57] Yeah. And it's part of the three Cs of dev rel, which I'm sure you've heard about. Yes, it's [0:21:05]-

Richard Rodger:  [0:21:06] Let's go through those for those who are learning. [0:21:08]

Alvin Bryan:  [0:21:08] Sure, yeah. So, that was – I think that was – that came out in 2014 from the SendGrid team and Brandan West. The idea is – we're talking about dev rel activities, and the idea is to divide them into three Cs, so the letter C, so you got code, content and community. Code is more like your SDKs; it's more like the dev ex side of things, but it can be product feedback and all that stuff. Content is – it makes sense now; we're in the age of content now, so it's that. It's podcasts; it's blog posts; it's YouTube videos, whatever we can think of.

And the last C is community, and that's more like meetups; it's online, discord groups. It's the Stack overflow and everything. So, that's – these are the three Cs. And usually – it's also a great way also to think about dev rel in terms of where do I see. And there are people who like doing all three and are good at all three that exists. But often, it's – often people tend to be stronger in one or two. [0:22:25]

Richard Rodger:  [0:22:27] That's – it's an interesting way of looking at it, because on the surface, I would have said that doing all three is essential to the developer advocate role. But building up a team, you can ask people to play to their strengths, as you say. And I'm just guessing from what you're saying, you're more on the code and content side, or do you do all- [0:22:53]

Alvin Bryan:  [0:22:53] Exactly, yeah. [0:22:54]

Richard Rodger:  [0:22:56] That said, you have launched a meetup, which we'll talk about. [0:22:58]

Alvin Bryan:  [0:23:00] Yeah. I like it. It's about strength. Some people are excellent at three, but in my experience, at least with interacting with dev rel people, both in and out of the job, I can tell people are usually very strong at two and have a third one that they do, but that are not as strong. Which doesn't mean they're terrible, it's just not as strong. [0:23:24]

Richard Rodger:  [0:23:25] Community covers – I don't know. Doing talks at conference, is that content or is that community? [0:23:30]

Alvin Bryan:  [0:23:31] I don't know. I think it's- [0:23:34]

Richard Rodger:  [0:23:34] You could say either one, right? [0:23:36]

Alvin Bryan:  [0:23:36] It depends. It depends on the format. It's very different to do a keynote with 10,000 people versus- [0:23:41]

Richard Rodger:  [0:23:41] Yeah, that's definitely content; that's definitely content. [0:23:43]

Alvin Bryan:  [0:23:44] Right. Versus doing a small talk where it's 20 people in a beer garden somewhere. [0:23:49]

Richard Rodger:  [0:23:51] And you talk to them afterwards, right? [0:23:52]

Alvin Bryan:  [0:23:53] Yeah, right.

Richard Rodger:  [0:23:55] Well, here's a – just focusing on code for a minute, here's an interesting question for you. And I don't know if you're free to talk about this with respect to Contentful, but I'm interested. You guys have an SDK, I'm sure. [0:24:07]

Alvin Bryan:  [0:24:07] Yes.

Richard Rodger:  [0:24:09] So, who writes the SDK? Is it the developer advocates or is it a separate team? And which one should it be? [0:24:17]

Alvin Bryan:  [0:24:19] That's also a nebulous thing. In my experience, applying to dev rel roles, sometimes there isn't a hard line between that. The whole SDK and APIs and making sure this is good and integrated, that usually falls into more like what people call dev ex, so developer experience.

People doing that are generally called developer experience engineers. But it depends. In my job search, I found job descriptions that were developer experience engineers and that were developer advocates, that were content – the threes I just talked about and no SDKs at all. But generally, the people who do SDKs and more on the code side of things are on – are developer experience, which are different from developer advocates. But that varies between companies a lot.

At Contentful, we don't. At Contentful, dev rel is purely focused on the three Cs, but more – we don't touch SDKs. We have SDKs on a lot of languages, for example. We have JavaScript, Python, Go; I believe we might have Java as well, .NET. Covering that as a dev rel team would be harder, for example. [0:25:52]

Richard Rodger:  [0:25:54] And you then feed back to the Dx guys or girls about what you're hearing form the community and what people are telling you? [0:26:03]

Alvin Bryan:  [0:26:04] Yes. And the smaller the company, the quicker that feedback loop is in general. And this is where also it gets nebulous. Because when you're – if you're a smaller company, if your entire company is 15 people, you're doing everything as well; it's a lot. Even if you're mostly doing content and community, it's very easy for you to open a quick PR over there and change some things. I- [0:26:31]

Richard Rodger:  [0:26:31] I'm just going to go – I just want to go deeper on the SDK; I want to get your opinion on something. In my other life, we do consulting for startups mostly, helping them take their MVPs to production. And one of the things that we're always doing is integrating with many third-party services. And for any project, it could easily be up to 10-15 third party services. These days, there's a lot of stuff. [0:27:04]

Alvin Bryan:  [0:27:05] Yeah, there is a report from OCTA that came out, which is insane to me. I think it was – the average company uses something like 80 tools. It's just nuts. [0:27:18]

Richard Rodger:  [0:27:20] From a developer experience point of view, the industry has a bit of work to do. Because every single time, for every single SDK or API, you've got to sit down; you got to read the docs. And they all do authentication in a different way and they all do [inaudible] Time: 0:27:39] in a different way, and they all have different constraints. And some of them have wonderful docs and example code, and others are oh my God, crazy.

There's – it was – they hired – they outsourced documentation or something. They're – the industry still seems to have – does not seem to have focused on a standard way of doing things. When I as a developer want to use an SDK, I want to go on a standard pathway. I want to do all of the authentication, in pretty much the same way for every tool. And that isn't there yet. From a Dx perspective, it's chaos, total chaos. [0:28:33]

Alvin Bryan:  [0:28:33] It's total chaos. [0:28:35]

Richard Rodger:  [0:28:37] I don't know if you had any thoughts on that or what we should do as an industry. Maybe there should be standards or something; I don't know. [0:28:41]

Alvin Bryan:  [0:28:45] Yeah. It's a tricky one. I think it's getting better. I tend to agree with you, but it's getting better, especially in the last, I would say, four years or so. We went from, as you said, here's the docs, good luck, to – now we have these turnkey scripts. You see tones of companies that just have a one-command thing, which is just get started. And it's npx, when you're looking – just say npx, Contentful, Creator or whatever, or npx Svelte, whatever. This has improved a lot.

But I think the – we're getting better at it. And there – one part of that is people are starting to treat things like terminals as part of the developer experience, which wasn't the case before. Which is good, because now if you want to – with Svelte for example, if you run their installer, you have a bunch of options.

It's all color coded; it will install your dependencies for you. Stuff like that was very rare five years ago. It still existed, but it's becoming more of a standard, like you said. It's not an official standard, but more of a table stake feature in a way, that you could just run a terminal command and get started. And then- [0:30:17]

Richard Rodger:  [0:30:19] I would agree, table stakes. It's just from the practical on-the-ground experience, I'd say only half of the companies have any sort of – reach any sort of standard, acceptable standard. [0:30:37]

Alvin Bryan:  [0:30:38] Yeah. I think even half is probably generous. [0:30:40]

Richard Rodger:  [0:30:41] Probably is Okay, let's stop our ranting about APIs and SDKs. And I'm sure Contentful's one is wonderful. I hope to use it at some point. Let's talk about – you – let's talk about one last thing. You recently set up a meetup, which is something- [0:31:01]

Alvin Bryan:  [0:31:01] Yes.

Richard Rodger:  [0:31:04] As the developer advocate role grows within companies and as people do more developer relations, a lot of companies are realizing that they have to engage with meetups, either sponsor them or help to run them or start them up. And that's something you recently did. So, take us through that whole process. [0:31:24]

Alvin Bryan:  [0:31:27] It was not easy. So, for – so, we had an event. It was the first in-person event for Contentful in London since 2019, that we ran in October, and it was good. I was in the UK, so it was easier for me to call venues, to – and also, I knew London as well, so it was easier to say, "This place is really hard to get to. No-one will go." So, I had this knowledge which was helpful, because sometimes it's hard. You can- [0:32:03]

Richard Rodger:  [0:32:05] Yeah, I've done meetups in remote – in cities where we were just – stuff; it's crazy. [0:32:10]

Alvin Bryan:  [0:32:11] Yeah. It was a lot of work, and part of – one thing we do differently, which sounds obvious, but – is to think of these things in advance. And it might be – especially if you're starting from scratch. Because when you have a meetup that already exists, that has a cadence, it has two or three regular venues, it's a lot easier to not think of things that far ahead, because there's already a system in place.

But we had nothing, and it was a one-off thing as well, even though we want to do more. But it wasn't going into a venue and say, "Hey, we're going to be there every second Thursday for a year." It was more, "Okay, we need to figure this out. We didn't even know how many people were going to show up," even if…

That was from the speakers. We were really lucky that we managed to get some really good speakers. And even a good crowd. People stayed afterwards for at least an hour after all the talks were done, which to me was a really good sign. So, yeah, I think it's- [0:33:31]

Richard Rodger:  [0:33:31] Do you find with – do you find that the – that it's finding a venue? How did you find that? Because before COVID, there were lots of companies that would give you space, very easy to find venues. Is that different now for an in-person meetup? Have the companies opened up again, or is it more difficult? [0:33:53]

Alvin Bryan:  [0:33:57] I think some companies have – are definitely back to their 2019 self. And these ones are still there and there are still some that are willing to sponsor stuff in terms of opening their offices, so these companies still exist. I'm not sure if there are as many; it would be had for me because I don't have a point of comparison. And I can't tell you I did that in 2019 and I did that in 2022 and these things were different.

But I still think there are – at least I would assume in big cities, there are companies willing to open their offices and support communities. It's probably in – similar to what we said earlier. Probably in the things that are similar to what they work on. But yeah, there are companies willing, but also, you can still find regular venues. And they're still pretty happy to host.

Venues in general are quite happy to have a meetup, because it's easy for them. They don't have to cook anything if their place offers food, or they have all the pre-orders in advance. They don't have to deal with customers. You could just say, "Give me 30 meals tonight," and it's all they have to do. So, they're generally pretty happy and – because it's a much more predictable evening for them. [0:35:21]

Richard Rodger:  [0:35:22] Trust me; that's a lot easier than phoning up the pizza place that hasn't turned up with your eight large pizzas, 30 hungry guests. The speaker that has to leave because the babysitter's – it means they don't want to stay much longer. Meetups are super fun. Are you going to do more? Will you do it again? Will you make it regular? [0:35:43]

Alvin Bryan:  [0:35:45] We're not sure. One thing we want to do more for the upcoming year is more sponsoring of existing meetups. As you said, it was – one of the things you raised earlier was either doing meetups – either sponsoring by giving away a venue or just sponsoring food or whatever, so we want to do the latter more. So, we'll – again in an effort to meet developers where they are. We want to go into local user groups and see if we can help. [0:36:23]

Richard Rodger:  [0:36:22] Will it be- [0:36:23]

Alvin Bryan:  [0:36:23] And we're drafting that strategy right now. [0:36:25]

Richard Rodger:  [0:36:26] Will it be London again or are you going to do it- [0:36:27]

Alvin Bryan:  [0:36:29] Ideally more places, yeah. I don't have anything yet, but ideally more places. I would love to get involved in a meetup maybe even in Belfast or Dublin or something like that, for- [0:36:41]

Richard Rodger:  [0:36:41] Yeah. We have – our Guinness is much better. We get it straight from the factory. Alvin, with that, I look forward to having a pint of Guinness with you next year at some point. [0:36:55]

Alvin Bryan:  [0:36:56] For sure. Yeah. [0:36:56]

Richard Rodger:  [0:36:57] Thank you so much. Super interesting, and great to provide people with almost a role model pathway into the developer advocate career. Thank you so much. [0:37:07]

Alvin Bryan:  [0:37:08] No problem. Thank you so much. [0:37:09]

Alvin Rodger:  [0:37:10] Awesome.

Endnote

Richard Rodger:  [0:37:12] 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:37:39]

‍