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.

The interesting thing about dev rel is that people end up in it both from the developer side and from the marketing side. Today I'm talking to Suze Shardlow, who started off as a marketer and is now a coder. Not only is she a coder, she is a speaker, an event MC, and a published tech author.

In this podcast, Suze offers a really good insight into the relationship between sales and dev rel and how you have to be really careful in your organization not to position dev rel as just another part of the sales funnel. Because nothing turns off developers or damages a community of developers, than trying to sell to them directly. We just don't work that way. We also talk a little about how Suze got into speaking and how being an event MC is not quite the same as doing a talk. So, without further ado, let's get started. [0:01:18]

Main Interview

Suze Shardlow

Richard Rodger:  [0:01:19] Suze, it is great to have you here today on the Fireside with Voxgig podcast. Welcome. [0:01:25]

Suze Shardlow:  [0:01:27] Richard, thank you so much for inviting me; it's really exciting. [0:01:30]

Richard Rodger:  [0:01:31] Awesome. Let's get straight into it with I think one of the most critical questions the developer relations world is trying to figure out at the moment. Lots and lots of opinions on this one. Where does developer relations live in the organization? [0:01:46]

Suze Shardlow:  [0:01:47] That is definitely the age-old question, and I don’t think we – I think if we were here for 50 years, we still wouldn't have the answer. But – and this might sound like a bit of a cop out, but I think it depends. What we are seeing now is a lot of companies are saying, "We want developer relations. We need a dev rel department. We're going to hire somebody to do this thing." And I think a lot of the time these folks don't really know why they need developer relations.

I think what's clear is that every company wants to make more sales, and a lot of companies, they want developer relations to cut speak to that, which is, everybody's got to work towards the high-level company objectives. And where developer relations sits depends whereabouts on the continuum or how involved you want dev rel to be involved in that piece.

Dev rel's a multidisciplinary thing. We do a lot of different things; we overlap with a lot of different functions or tasks. And in some companies, I would argue, small startups that are quite new, if you're going to hire dev rel you probably want them to contribute to the sales process a lot more than if you've got a mature product. You've been operating for a long time, and maybe you've already IPOed. Probably not so much, you're probably more on the education side, and the awareness side, and maybe product development type thing.

So, it depends, but personally, if I was going for a job in dev rel, I don't think I'd want to be in one of those. Even though I'm a dyed in the wool marketer and that's where I started off, I don't think I'd want to work in a dev rel department that reported into marketing. I'd prefer to work in one that reported into engineering or product. So, yeah, it depends; here's no right or wrong answer., but the job is definitely different depending on where dev rel sits. [0:03:48]

Richard Rodger:  [0:03:50] You're getting at an interesting point. This discussion – I'm sure other –if you've listened to other podcasts or whatever, you've heard this discussion before. But I think you're raising a point that I have not heard before, which is really interesting. Which is whether the organization sees dev rel as part of the sales funnel or part of the brand awareness community building. And that's the underlying decision or strategy which drives how you position dev rel, right? [0:04:24]

Suze Shardlow:  [0:04:25] Yeah, it does. And that's not necessarily what people are signed up for when they decided to go in developer relations. So, you've got to be really careful when you look at job adverts to see exactly what's expected of you. But every company wants to sell more. A lot of dev rel teams, even if they don't sit in marketing, that's one of their metrics. They've got a code that they can give out at talks and things like that, so they can measure sign-ups and stuff. So, it might only be the free tier, but we know that the free tier is part of the funnel, isn't it? [0:05:00]

Richard Rodger:  [0:05:01] Absolutely, yeah. [0:05:01]

Suze Shardlow:  [0:05:01] So, there's no getting away with it. No getting away from it, yeah. [0:05:04]

Richard Rodger:  [0:05:04] Would that come out? If you're doing a job interview for a dev rel position, what questions do you ask to tease that out? Are you – do you have sales metrics, or how would you find that out? [0:05:14]

Suze Shardlow:  [0:05:15] If I was going for a job? [0:05:16]

Richard Rodger:  [0:05:16] Yeah.

Suze Shardlow:  [0:05:20] I'd just go in there and say – I have done this. Because I haven't got anyone in dev rel at the moment. I'd just say to them, "Why do you need dev rel now? What problem is dev rel going to be solving for you?" and then listen to the answer. Silence is quite a good tool in these situations. [0:05:39]

Richard Rodger:  [0:05:39] Great negotiating (inaudible, 0:05:40), absolutely. [0:05:41]

Suze Shardlow:  [0:05:45] Yeah. Just asking somebody why they want dev rel, and then that just gives you the answer as to where they think it sits. Because if they want dev rel because they want more sales, then you might not sit in marketing, but you're going to be aligned to that.

If they want dev rel because they want to raise more awareness or they want to get feedback from community, then that gives you an idea of what's expected from you as well. So, that is my main question that I would ask. Also, the general questions that I would always ask, like where am I – who are my main relationships going to be with if I get this job? That's quite telling as well. [0:06:19]

Richard Rodger:  [0:06:20] Yeah. That would tell you. I think you're right to identify the fact that in a smaller startup at an earlier stage, everything is really about sales or the company's dead, so you know what you're getting. But in a more mature, in a larger organization, you end up working in a dev rel team, right? So, what's that- [0:06:42]

Suze Shardlow:  [0:06:42] Yeah.

Richard Rodger:  -[ 0:06:42] experience like? Have you had both of these experiences, where you were the only dev rel person perhaps, or one where you're in a team? And how does that differ? [0:06:50]

Suze Shardlow:  [0:06:53] Okay, so at the moment, I'm the only community person in the dev rel team, which is kind of similar. And in the past, I've been the only marketing person in the company, which again is quite similar. So, to be that first hire is really hard, because if I haven't got anybody doing any of that activity and they want – naturally, they're going to want everything, because they're so excited to have somebody on board.

You've got to manage their expectations as to what exactly you can do and what they should be doing. And what you find is, a lot of people hire you and they say, "I hired you because of your expertise," and then they don't go on to use the said expertise or ask you for your opinion. Or they ask you for your opinion and then they just ignore it. And that happens to everybody.

But when you're in a bigger team, it's easier, especially if you've got a good manager, to play to your strengths and have those opportunities to build up knowledge and experience in the areas that you're not so strong at and you want to develop in so you can help each other. But there's definitely more – there's more scope to play to everybody's strengths and make sure that things are being covered that way rather than stretching yourself thinly over things that it's not necessarily what you want to do or what you can do.

And also, there's all different ways of dividing things up. Some people do things geographically, don't they? We don't do that; we do things by language. So, we don't say, "Right, you're going to be the MBA JavaScript dev rel." You're the JavaScript dev rel and you cover every geography as far as you can." I know some companies have had massive teams, haven't they? And- [0:08:36]

Richard Rodger:  [0:08:36] Yeah, absolutely. I know. 100 people- [0:08:39]

Suze Shardlow:  [0:08:39] Yeah, 40-plus people. [0:08:39]

Richard Rodger:  [0:08:40] -even. I'm going to pick up on a little thing you said. No need to name names. Let's frame this question a little way, a little differently. What are common dev rel mistakes that people make, where your expertise perhaps might have taken them in a different, more successful direction? [0:09:03]

Suze Shardlow:  [0:09:10] Not listening to dev rel when they say, "This is how developers want to communicate" or "This is how they want to hear from us." Not looking at the bigger picture, thinking strategically, but this is something that I've noticed in every job that I've had. People tend to focus on the tactics and then – because they're the things that you see, right? That's the end product of what you're trying to do. That's the visible piece of work.

Nobody goes back and says, "Can I see your strategy (inaudible, 0:09:41), because I'm really interested in that?" They'll see your presence. People tend to look and see what other people are doing and are like, "Yeah, we need to do that." And my question – the question that I've been asking everybody since I first got my first job is why. Why? Like you said at the beginning, why do you need dev rel? Why do you need to go on TikTok? Why? Just because somebody else did it.

Those are the two big things. And a mistake that new people coming into dev rel make is that they do look at the tactics and they see it as a sort of influencer role, when actually, yes, there are influencers in dev rel, but there are loads of people working in dev rel who you've never ben head of. So, that is a bit of a misconception amongst a lot of people, but again it comes back to that whole – what is dev rel? And if nobody can really answer that question convincingly in a way that's the universally accepted answer, then you can't blame them. [0:10:52]

Richard Rodger:  [0:10:56] And the question of how developers like to receive communication is one that's close to my heart actually, speaking as someone who also does development and tends to have to integrate with a lot of APIs and different systems. You'd have wonderful experiences, things like Stripe, that type of stuff. Redis has pretty cool documentation, pretty much always has, which has always helped.

But I – from my perspective, the – on the communications side, one of the things that I don't feel a lot of companies solve is addressing the adoption risk issue. If my boss – I'm a developer and my boss tells me, "Integrate x, y, z," or I have a client and they say, "Estimate the integration cost of a, b, c service, and here's three services and compare them." I find a lot of companies fall down, even if they've great reference documentation, on helping me ascertain what that actually – what integration actually looks like.

That's why companies that have speakers that go out and write sample applications and all that sort of stuff, I really like that, because you can see. Show me the code, right? What's your take on that in terms of the communication? What have you seen that works? Is – maybe that's my – just my little obsession, seeing sample code, but in your broader experience, what works and what doesn't? [0:12:37]

Suze Shardlow:  [0:12:40] I think sample code and showing people how actually works in practice and demos are definitely what people want to see. Because there's no point telling them in a conceptual way. Like you say, they need to know how they're going to actually be able to use it, and the best way of showing them that is by showing them that. And that's the argument for having developer relations, because if you have a marketing team, they're probably going to be marketers.

And I say this as somebody who worked in marketing for a long time. The companies that I worked at in marketing – I worked for an engineering company; I wasn't an engineer. You work for a retail company; you're not a retailer. Although that's probably a little bit easier to understand, because you use retail. But if you're trying to market something that you don't use and you've never used and it's not your expertise, you're never going to be able to produce that demo.

So, that's the gap that developer relations fills in there for marketing. Yes, some marketing departments do have technical marketing people, but again, that's different from dev rel. Because in developer relations, we want to be that trusted voice, that authentic voice that will always tell you what' s best for you as a developer, not trying to make that sale or trying to get you into the funnel, but just being that honest voice reflecting the developer feeling back.

But it's definitely to do with that, and people love them. When you go to conferences or you go to meetups, they love to see it in action, and they're like, "Wow, that's a great way of using it." And the great thing about Redis is, it's a database, so you can put it with anything, so that's really handy. I can imagine for other folks it can be quite hard.

But you're right, that whole thing about how does this work for me if I was going to bring this into my stack and have it part of my – as part of my day-to-day work? There probably is a bit of a gap there, but I suppose that comes in with the – possibly a bit the sales piece. The engineers working in sales would be able to give you a really good answer on that. We focus more on how to use it rather than how to integrate it, but you make a really interesting point. [0:15:06]

Richard Rodger:  [0:15:08] Yeah, and there's all sorts of questions around integration, because you don't just adopt a specific platform. And does it – how does it then run in Google versus Amazon, whatever, or bare method? That's as important. Some of the best developer relations interactions I've had are with companies that I decided not to use in the end, where there was some interaction with their engineers on the dev rel side. And we came to a mutual understanding that it was not an appropriate solution for whatever project I was working on. [0:15:45]

Suze Shardlow:  [0:15:49] I think that's brilliant, because that's – yeah. That's what developer relations is supposed to be; it's not supposed to be – this is the best thing for you. Don’t use any of these other competitors. This is why we're better than them. It's all about what are you trying to do. Maybe sometimes we are the best solutions. Other times, probably, we're not going to do what you need. [0:16:09]

Richard Rodger:  [0:16:10] And my impression of those companies – and it's not the majority; it's still only a few, but – is, when it is right, I will totally go back to those guys, because they've established a huge amount of trust. Another challenge that I've come across is the difference in developer relations – well, I'm not going to call it strategy, because as you pointed out, the strategy is something that people need to work on. Just in terms of execution, there's different – seems to be a different – different layers of companies.

There's very heavily developer focused tools – Redis, Mongo, Stripe, that sort of thing – where they clearly understand they're going to be dealing with lots of developers. And then you have companies like Salesforce where, and Amazon, where it's just developers are part of their bread and butter. And there's mountains and mountains of information. And they do a relatively good job, but it's a little bit take it or leave it, and usually, you just have to take it.

But then the third category, which I find the most frustrating, are specialist service providers, in ecommerce or communications or various things like that, where they are an API-led company; it's the way that you interact with their service, but the actual execution is awful. And you spend days trying to figure out how to authenticate with service, this type of thing. And is it just lack of resourcing around documentation or is it fundamental lack of understanding? I don't know. I've seen very few of those types of companies do it well. It's always a frustrating experience. [0:18:04]

Suze Shardlow:  [0:18:05] Yeah. I think that in programming, in software engineering, for some reason, engineers are really quick to forget what it's like to be a beginner. So, if you – like you say, if you look at any quick start guide, a lot of the time they're assuming a level of knowledge which is not necessarily standard across the – all of them either. So, it's like starting on step three; okay, where was step one and two?

And I feel like even people who are experienced software developers – so they're not newbie coders – they're always going to be newbie at something. So, like you say, you want to pick up this new tool; you want to use their API. You've never used it before, but you've probably got quite a lot of experience in programming and you still can't do it.

So, even though we're in developer relations, sometimes we do find it hard to go right back to the beginning and think, right, who is actually – because audience is key here. That's the whole – the part of marketing that is important in developer relations, is the audience piece. I don't think we think about the various audiences that we have, and it's not just one audience. You can't just say our audience is developers.

So, you – for example, you might be looking at people in different verticals, and the type of companies they work at and the type of software they've got. Where are they starting from? Probably a little bit higher. And then you might think, we've got a database, so who's going to use the database? Probably quite a lot of engineers at all different stages. We might have people that are learning to code that want to use our database, so we need to produce some stuff that speaks to them.

I think it's because we don't think enough about where the developer is coming from and we choose this arbitrary – not even persona – I don't think – I know a lot of people do have personas, but a lot of people don't as well. We just choose this arbitrary point at which we think this is where you're going to start; this is your start point. [0:20:26]

Richard Rodger:  [0:20:30] I don't – well, I don't have the answer for those. I don't want to call them third tier companies, but perhaps resource constrained. But perhaps we just need to develop more community knowledge and more – maybe not standards, but just ideas of what it means for there to be excellence in developer relations. It's so new and so young; can anybody do that?

I know people have written books and all that sort of stuff, but it doesn't feel like there is an objective standard that people can be held to, to say this is really good. You can point at Stripe and say they did it really well, but what exactly did they do? I couldn't tell you; it's hard to know. [0:21:19]

Suze Shardlow:  [0:21:20] Yeah, but again, it depends on their audience, doesn't it? It's – you could go back to first principles of marketing and model it that way. Why did we do this and why did we do it the way that we did it? Because this is the sort of person we wanted to talk to, and this is what we wanted to do – them to do as a result. The problem comes is when you're thinking about your tactic and not thinking about why you're doing it and what outcome you want. [0:21:52]

Richard Rodger:  [0:21:54] And you keep coming back to this – I think it's a really interesting point – where you're saying you need to ask why. There needs to be a why; there needs to be an answer. Engineers have this problem with why, because it's just fun to code; it's just fun to do engineering. There doesn't need to be a why.

I remember working with a colleague; he's CEO of quite a successful consulting company now. But I remember very clearly having coffee with him one day in 2009, I think it was. And he told me with a straight face that he would code for free, he liked it so much, even if nobody was willing to pay him, as a job. [0:22:39]

Suze Shardlow:  [0:22:40] How's he going to eat? [0:22:40]

Richard Rodger:  [0:22:42] It doesn't matter; he liked coding so much that – at the time, he was like, "Well, what about the mortgage?" But that guy, he's a good friend of mine and everything and he does great developer relations in his own stuff. But there's definitely an issue in the engineering mindset where why is not a factor. You know? [0:23:10]

Suze Shardlow:  [0:23:12] Yeah, and that's why. If dev rel is made up of engineers, then it follows, doesn't it? But that's where you get – then get into issues, because if your business can't – if your organization can't see the value of dev rel, or they're always asking you to justify your existence, you need to have some why to tell them.

Whether or not it's part of your fun realm in software engineering, you do have to bend to that corporate piece unfortunately, even if your users don't have to. Then you're a business unit, aren't you? And you do have to think about it. I personally find it more satisfying if I've got a bit of a North Star. [0:24:05]

Richard Rodger:  [0:24:05] Yeah. Doesn't it – isn't it true that if there is no clearly defined strategy, the why questions are very hard to answer. [0:24:15]

Richard Rodger:  [0:24:17] If there is a strategy, it's- [0:24:18]

Suze Shardlow:  [0:24:18] Yeah, totally.

Richard Rodger:  [0:24:18] If there is a strategy, it's actually clear. Whether the answers are right or wrong is separate. Just defining a strategy lets you answer those why questions. [0:24:26]

Suze Shardlow:  [0:24:29] Yeah, the two things go hand in hand. [0:24:31]

Richard Rodger:  [0:24:32] Why are we trying to reach developers on TikTok? [0:24:33]

Suze Shardlow:  [0:24:35] Yeah.

Richard Rodger:  [0:24:40] Let's talk about conferences and speaking and MCing, because you do all that stuff as well. Is that something that you found you had an actual talent for or was it a skill that you had to develop? Did you have a fear of public speaking? [0:24:54]

Suze Shardlow:  [0:24:59] I'm just trying to think about the first MC gig that I did; I can't remember which one it was. But no, it's something that I really love to do. And I was thinking about it, and I think the reason is because when I was a child, I really wanted to be a radio presenter. [0:25:18]

Richard Rodger:  [0:25:19] There you go, right. [0:25:20]

Suze Shardlow:  [0:25:20] Yeah. So, I think that's the reason. And I've always loved explaining things to people and I remember as a child acting out that I was presenting stuff. But I never made it, because as a brown woman in the 1990s, there's no real – there's no visible path for you to take into that role.

As for the public speaking piece and did I have a fear of public speaking, no, I didn't.  Because the school that I went to, it was a private school. And there were – when you're 11 and you get sent to this school that none of your other friends are going to, you don't really know what to expect until you get there. And then you get there and then they tell you, "Right, you're going to have an exam at the end of every single year." And I'm like, "Hang on a minute. I've heard about this thing called GCSEs that I'm going to take in five years. What are you talking about?"

And the other thing that they said was, "We're going to do a speech in front of the whole class every single year." From the age of 11, and it was a girls' school, so you can imagine how brutal that was. So, that pretty quickly beat any fear out of me; you learned to survive. And I remember once doing a talk about – I never told anyone this actually. I remember doing a talk about time and how now doesn't exist. Because when you think of now, it's already gone; isn't it? [0:26:48]

Richard Rodger:  [0:26:48] It is, yes, absolutely.  I 100% agree. [0:26:50]

Suze Shardlow:  [0:26:51] Yeah. As an 11-year-old, it was – I think that was quite deep. And I remember doing this speech in front of my – practicing it to my adad. And my dad was a huge perfectionist and he said, "No, I don't think so. I think you need to change it to this and that." So, I changed it, changed it completely, and I didn't like it. So, at the last minute, when I went up, I changed my mind and did my original speech. [0:27:16]

Richard Rodger:  [0:27:17] Well done, brilliant. [0:27:17]

Suze Shardlow:  [0:27:18] Yeah. And the teacher at the end, she was – yeah. It was funny; everybody was laughing and stuff, and I got the laughs at the bits that I wanted. And the teacher actually said, "You got genuine laughs." And that to me was like, – well, not a lot of people can do that. So, every year, I had to do this speech, and then when I went to university, they made us do a presentation on a new product.  And this is really going to age my out, but we chose Dyson vacuum cleaners, because they were really new at the time. And- [0:27:56]

Richard Rodger:  [0:27:56] They were (fabulous) Time: 0:27:56].

Suze Shardlow:  [0:27:58] Yeah. And Virgin Mobile as well, because that was a new thing at the time. So, I've been presenting for 30-somehting years. So, by now – I always still get nervous; always still get nervous, but it doesn't scare me. So, if anyone said to me, "Do you want to do a talk?" I'll always put my hand up, and then I – regretful. My – yeah, now I've got to write this talk. But I'm really accustomed to it. And this MCing thing for me is a natural extension and lets me get to do something a little bit different as well. [0:28:39]

Richard Rodger:  [0:28:40] I don't think people appreciate how – for me anyway, I find the MC job to be way more difficult than giving a talk. [0:28:50]

Suze Shardlow:  [0:28:52] Yeah. It is. [0:28:53]

Richard Rodger:  [0:28:53] A talk you can prep in advance and you have your slides, but with the MC role, you're expected to be a little bit funny. You're expected to have all these random facts, people's names, companies. I just – for my – I go blank. Very stressful. I have to have notes. I don't know; maybe you're more of a natural, given your goal to be a radio presenter. Do you find it stressful or is it something that comes naturally? [0:29:22]

Suze Shardlow:  [0:29:24] No. I find it just comes naturally. And also, I've always had a- [0:29:27]

Richard Rodger:  [0:29:26] Yeah, lucky you. Wow. [0:29:27]

Suze Shardlow:  [0:29:28] I've always had a really good memory, so please don't test me. I tend to remember details about people that they told me, so I don't tend to need notes that much. And I think it's – it makes the person feel valued that you've remembered this stuff. [0:29:49]

Richard Rodger:  [0:29:49] Yeah, good thing. [0:29:49]

Suze Shardlow:  -[0:29:49] and you haven't had to refer back and you're not just going through the motions. But like you say, the role of MC means that there's a lot more unknown. For example, somebody might have submitted their talk. I wasn't necessarily on the selection committee, so I don't know what their talk is going to be about, other than what it says on the website.

And then we've all had this; you go to a talk and it's totally not what you were expecting it to be. The speaker, when they wrote their abstract, they had a thing in mind as to what they meant. And when you read it, you interpreted it in a different way.

So, the talk that comes out of them isn't necessarily what you were expecting.  And so you've got to listen and you've got to formulate your own questions as well, because you may not get any questions from the audience. So, you've got to be able to ask a question. And so, that can be quite hard if what they're talking about isn't necessarily the area that you know about. [0:30:44]

Richard Rodger:  [0:30:46] Yeah, you've always got to trigger the questions, because there's always that awkward pause at the end. The speaker goes end and then there's silence. [0:30:53]

Suze Shardlow:  [0:30:54] Yeah. And they might be talking about some technology that I've never used or I know nothing about. But I've got to be able to talk to them about it in a – not a knowledgeable way but in a convincing way. So, I have to listen probably a lot more than your average attendee. [0:31:13]

Richard Rodger:  [0:31:14] I know. You're not off when the speaker's speaking. You're still --[0:31:17]

Suze Shardlow:  [0:31:17] No. You're still very much on, yeah. [0:31:20]

Richard Rodger:  [0:31:22] Yeah, I know. Well, you have my admiration. I'm not sure I would sign up for too many more. I like doing talks, but the MC thing – it wasn't nerves, but it was super stressful, because you don't want to put your foot in it. It's like you said; you see a talk and then you introduce it completely incorrectly. And then the speaker has to correct you when they start, which is what happened to me. So, (inaudible, 0:31:53)

Suze Shardlow:  [0:31:53] Yeah. Or some people, what they do is because they don't really know what they want to say, they do an intro of the speaker, which I try not to do. Because you don't know if that speaker has dedicated two or three minutes at the beginning of their talk to introduce themselves, so then you've just duplicated what they're going to say. So, there's a few different things that you need to bear in mind if you're going to do that role. But I really enjoy it, because I like doing talks, but it's a different type of public speaking. [0:32:23]

Richard Rodger:  [0:32:24] Have you done the MC thing for virtual events? [0:32:25]

Suze Shardlow:  [0:32:27] Yeah.

Richard Rodger:  [0:32:28] And how is that? How does that go? [0:32:29]

Suze Shardlow:  [0:32:37] It's good. It did – it was nearly two years ago now; it's gone really fast. I did a six-hour event where I was the producer and the MC. That was quite interesting, because I had to rely on my speakers to turn up, because I didn't have anyone behind the scenes making sure it was – so, they did turn up and it was all good. But I was fully prepared that if somebody didn't turn up, I would be like, "I need to fill this 20 minutes with something," which is fine.

I feel like online events are good, because yes, you don’t get feedback from the audience, but also you don't get any of that nervousness of, these people aren't looking at me; they're looking at their phones, or whatever. You are very much there and you don't have to try and get anybody's attention, if that makes sense. So, it is very different, but it's still good; I still enjoy doing that. [0:33:39]

Richard Rodger:  [0:33:40] Yeah. I was a sceptic to begin with, because I'd done so many in-person ones and needed that audience energy. And I had done virtual ones before COVID and really didn’t enjoy them. But I've come around to it now, I've – yeah. Short and sweet, don't try to replicate the whole conference experience. And it's not so much about the networking; it is much more about the content. So, I think you just have to focus on the – what it's suitable for as opposed to trying to replicate the in-person thing, which is very different. [0:34:15]

Suze Shardlow:  [0:34:16] That's the thing, isn't it? You've got to – again, you've got to think, well, what am I trying to achieve here, and understand the limitations of the medium that you've got available to you. Like you say, you didn't like the virtual events, but then lockdown came along and you didn't have a choice. So, you have to adapt, and then you have to realize that you can't do everything that you would normally do.

But it's like anything; isn't it? It's like, right, I'm going to make a cake. I've only got these ingredients; what can I do with that? I haven't got any chocolate, so if I'm going to have chocolate cake today, how much you want it. So, you've just got to make do with what you've got. And sometimes, some really good things can come out of it.

I started running a Sunday session in April 2020, around the time of the first lockdowns, which was an online session for people who needed a bit of mutual motivation and accountability to get stuff done. And from there, we've got a core team of people who come every week, and they still come every week.

So, in that respect, it's built up the community a lot. Because a lot of people prefer online stuff, and they're more themselves with online stuff. And they don't really want to go and do things in person. Or they can't do things in person, because there's too high of a risk still for them with this illness that's going around. So, it's different, and it had its advantages, definitely, and it's given us a lot of opportunities that we didn't previously have. [0:34:16]

Richard Rodger:  [0:35:55] Yeah. And I think it should continue; it should be part of the event mix. I find it's really good for including a wider range of people, especially with neurodiversity. Because going to an in-person event is pretty stressful for some people. And if you can do it remotely, you can still get access to the thinking and all that sort of stuff without having to deal with people, which sometimes I prefer. [0:36:36]

Suze Shardlow:  [0:36:38] Yeah. I feel a bit disappointed in events that have now gone – sorry, they've gone back in person and not providing online. Because it does feel a bit like, we had the online piece when all the abled people needed it. But now they don't need it anymore, we're not going to do it. So- [0:36:57]

Richard Rodger:  [0:36:58] No. You have to be hybrid. [0:37:00]

Suze Shardlow:  [0:37:02] Yeah. I think you do.  I think you do, but a lot of people are not embracing that, because it's gone into the too difficult box. [0:37:11]

Richard Rodger:  [0:37:12] But no, there's so many solutions for it now. It's not – it used to be difficult. It's not – maybe it's a little bit more operational stuff, but- [0:37:25]

Suze Shardlow:  [0:37:27] It's work, isn't it? [0:37:27]

Richard Rodger:  [0:37:28] Yeah, it's --

Suze Shardlow:  [0:37:30] People don't like – it's just easier for them to do it the way that they wanted to do it. Not everybody, but there are definitely some that have just gone back in person. [0:37:43]

Richard Rodger:  [0:37:43] Well, maybe that's just revealing that those particular conferences were mostly about drinking, as opposed to- [0:37:49]

Suze Shardlow:  [0:37:49] Yeah. Which again is not very inclusive, is it? But with meetups as well. That's a shame, when a meetup goes back to in person only. Because a lot of meetups were locally based but attracted people from everywhere during the lockdowns because they were online. And now those people who might be living in different countries lose that community because it's no longer online for them anymore. [0:38:22]

Richard Rodger:  [0:38:24] Yeah. Absolutely. I definitely experienced that with some of the meetups that I went to online, that it was – it became more international, much more interesting. And it was easier to get speakers. It's so funny; I remember one of the meetups that we used to run – and this would be 2012 now, oh my goodness. We didn't know what we were doing because it was – we were – it was the first time running a meetup. And we actually got speakers from California to talk to the meetup via Skype. [0:39:02]

Suze Shardlow:  Whoa! [0:39:03]

Richard Rodger:  [0:39:04] We projected the Skype video. It was a total disaster; it was awful. You could barely hear the speaker; the attendee experience was dreadful. But they did get to talk to really cool devs from California; they were doing interesting stuff. [0:39:26]

Suze Shardlow:  [0:39:28] This is the – it did make me laugh when you said, "We didn't know what we were doing." Because I think as an event organizer, there's always a bit of a learning curve when you try something new, isn't there? And it is always a little bit scary and it's always this – is it going to work and what's it going to be like? But definitely, once you've done it once or twice, it's like, why was I even worried? Because actually, that's second nature to me now. It's just getting over that initial – just try it, which is a little bit difficult for me. Because I mentioned my dad was a perfectionist; he definitely passed that down to me.

So, when the pandemic came along and lockdowns came along, and we were like, "Right, we've got a choice. Do we just stop doing meetups or do we go online?" I was like, "Okay, we can try online, but it's not necessarily something I would have thought of doing and I don't know how to do it." And did that a couple of times, and now I can run an online event really quickly and without thinking about it. But it's definitely that whole, how is this going to go, is a bit stressful. [0:40:37]

Richard Rodger:  [0:40:37] Yeah. I remember – yeah. And then you're trusting technology, which is – a lot of it was quite rough at the beginning and – yeah. [0:40:44]]

Suze Shardlow:  [0:40:45] You were trusting Skype, so yeah. [0:40:46]

Richard Rodger:  [0:40:46] Yeah. I was. [0:40:46]

Suze Shardlow:  [0:40:48] Brave.

Richard Rodger:  [0:40:50] God help us. We were using Skype, oh my God. [0:40:52]

Suze Shardlow:  [0:40:53] That is a good story; I like that one. [0:40:55[

Richard Rodger:  [0:40:56] You're projecting it. And then the guy was incomprehensible because the sound quality was so awful, but anyway. [0:41:05]

Suze Shardlow:  [0:41:05] Yeah. What you said about a projector just reminded me. I went and did an in person workshop a few weeks before everything got locked down. And I got there, and this is like – if you had a list of things that speakers need to – a checklist of things speakers should have to go and do a talk. So, I got there and their projector, the resolution was so low. It was like something – it was probably from 2012. It was probably the same one you used for your Skype event. And I was like, "What is this?" And luckily, I had an adapter in my bag, just in case, because you – so things you don't expect as a public speaker, part 350. [0:41:54]

Richard Rodger:  [0:41:55] A little bag of every adapter ever made. That's what I want. [0:41:59]

Suze Shardlow:  [0:41:59] Yeah. Exactly. [0:42:00]

Richard Rodger:  [0:42:01] Suze, this has been wonderful. Thank you so much. Lots of interesting insights on dev rel. And that core issue of most businesses and human activities, what on earth is the strategy? Can't just be random stuff. It's so hard, part is actual thinking. I still struggle with it myself, but it's good to highlight it, I think. A lot of people just worry about tactics and how you should run newsletters or whatever, but why. [0:42:34]

Suze Shardlow:  [0:42:36] Yeah, and what are you going to- [0:42:37]

Richard Rodger:  [0:42:37] Doing on this one.

Suze Shardlow:  [0:42:39] And what are you going to do after the first one? I've seen so many people launch things because they want this thing. And they haven't thought about, what does this thing look like in three issues' time? It's – you need a bigger- [0:42:51]

Richard Rodger:  [0:42:51] Yeah, that is tough. And it's hard-won experience, that just doing the first one is not good enough. [0:42:59]

Suze Shardlow:  [0:43:00] No.

Richard Rodger:  [0:43:01] The actual doing of things, podcasts, newsletters, is relatively straightforward. It's doing it consistently, every week, every month, and setting yourself – and do it that way. That's the hard work. [0:43:14]

Suze Shardlow:  [0:43:15] And making sure it still meets the purpose that you originally set out. IF you did set out a purpose because you had a strategy. [0:43:22]

Richard Rodger:  [0:43:23] Yes. On that note, I'll give a shout-out to Sinead Quealy, our organizer for all these things, who makes sure these podcasts go out and does all that operational stuff for me. So, thanks, Sinead. You wouldn't be hearing from us without her. All right, thank you very much, Suze. This has been wonderful. Thank you so much. [0:43:45]

Suze Shardlow:  [0:43:46] Thank you for inviting me. It's been fun. It's gone really quick. [0:43:48]

Richard Rodger:  [0:43:49] Yeah, absolutely. We shall talk again, I'm sure. I'll hope to – perhaps I'll see you virtually at a conference, perhaps in real life; you never know. [0:43:58]

Suze Shardlow:  [0:43:59] Definitely. See you soon. [0:44:00]

Richard Rodger:  [0:44:00] Take care. Bye-bye. [0:44:01]

Suze Shardlow:  [0:44:02] Bye.

Endnote

Richard Rodger:  [0:44:03] 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:44:31]

‍