Getting your first job in DevRel

Rebecca Marshburn: Hello.

Suze Shardlow: Hi there. How are you?

Rebecca Marshburn: I'm well. You know what, Suze, I meant to say this earlier when we were backstage, but Happy United States. American Valentine's Day. Valentine's Day solo Times's Day. I love that. I'm here with you. Thank you for being here.

Suze Shardlow: Likewise. Yeah, thanks for joining me today. It's going to be really cool. I think it's really early in the morning for you, isn't it?

Rebecca Marshburn: It's not so early. It's like 8:30 AM PST, so been up for a couple hours doing some things and stuff, but also I can't sleep the night before these because I get super excited and I have been a co-host to Matthew, and now we get to be co-hosts together without the head hosts and we're just going to take it off the tracks. Sorry, Matthew.

Suze Shardlow: Oh, poor, Matthew. I think he's probably crying right now, but No, it's going to be really good. It's going to be really good. So anyone who's watching, feel free to add your questions in the chat and we'll get through as many of them as we can too.

Rebecca Marshburn: And speaking of which the questions you might be adding in the chat, add any questions that you want around developer relations, like developer relations.com. There's tonnes of resources through hoopy, but what is the topic that we are talking about today, Sue?

Suze Shardlow: So fall in love with your DevRel career, and we're going to be focusing more on how to get into DevRel because that is a big question. It's the age old question. There's two age old questions in DevRel I think, or three. One is how do you get into it? One is what is it? And the third one is how do you measure it? It's this big mysterious thing. So we're going to demystify how to build your career in DevRel today, because that is a question that we always get asked.

Rebecca Marshburn: I am super excited and I really appreciate when people can list things out in a very clear way. So the fact that you articulated those three main bullet points, I was like, what? You're right. That is what it is. Those are the three lifelong age old questions. Shall we hop into our panellists?

Suze Shardlow: Let's do that, yeah.

Rebecca Marshburn: Alright, so I'll kick us off. Our first panellist is Phil Leggetter and I realise that I always ask people, well obviously not always because I am not sure if I just said your name correctly. Phil Leggetter is the head of developer experience at Tigris Data. He's done it all from hands-on execution to c-suite budget justification, so everything he's been the janitor, the president, everything in between. He takes care of the entire house, top to bottom, all the foundation, and he's a proponent of the triple A, triple RP DevRel strategy framework, which I so deeply want to know more about, which helps numerous developer relations teams map company level goals to team activities that bring value to a business. So welcome Phil. Thanks for being here.

Phil Leggetter: Thank you very much. And that was a great intro. I dunno if you caught me just doing some revision before I came in. I've also got this one and I'm not paid for these either. No. So thank you ever so much for my intro. I really appreciate it. Let me name anything.

That's the other thing with the ARC framework. Again, I always worked on this thing called quicker, which wasn't spelled in any way. You'd expect it was K-W-W-I-K-A. Again, don't let me name anything but employ me. Please employ me and help me build your develop relations teams or developer experience teams. And I've had the good fortune of doing that. I do already have a job. Just to be clear, I've had the good fortune doing that a few times and I've really enjoyed building teams, growing teams, but a big part of that has been starting people off in their Devra career.

So I hope there's some useful information that I can provide during the stream. I should just say I work for Tigris Data, and you've pronounced it correctly. We're an open source developer data platform. The simplest way of putting that is with kind of like MongoDB Atlas, but open source. We're obviously not as big as MongoDB, but the slightly more complex way of looking at it is where we have a database product, a search product, we're open source, we have a cloud offering too, and in the future we will offer caching, pub sub event streaming and various things like that. So I've done my piece as someone in DevRel who also has marketing responsibilities.

Rebecca Marshburn: Well, welcome and I appreciate the analogies made between something that you might know more and then you can apply that to if you haven't heard of Tigris, but I think a lot of people have, so maybe give yourself a little more credit.

Phil Leggetter: Okay, thank you,

Rebecca Marshburn: Suze, who is up next

Suze Shardlow: Before I say who's up next? Whenever I hear about the framework that you just described, I always say it in a pirate voice in my head. I dunno if I'm the only one.

Phil Leggetter: Oh, you've got to, there's a video under dev operations.com of the introduction to the ARC framework and I actually attempt to say it all in the pirate accent. So by all means, people go and have a listen and they'll laugh that,

Suze Shardlow: Oh, it's not just me, then that's good. That's good. I thought it was just me. I read it and I was like, it's just so tempting. I'm going to do it. Cool. Okay, thanks for that. Thanks for validating me there.

Our next guest is Kelly Hillborn. Kelly is very senior in developer relations and community. Most recently at Elastic as global director of community and developer relations. Also is a community development advisor at Chainlink Labs and has previously worked at IBM. Welcome Kelly.

Kelly Hillborn: Thank you for having me. Not quite sure where I go. I'm no longer at Elastic, so I'm kind of between jobs, but I do take a lot of mentorship and advising anywhere I can for developers and people wanting to get into the space, so hopefully I can add a lot to the conversation.

Rebecca Marshburn: Next up is Bekah Hawrot Weigel. She's a developer, a community builder and a keynote speaker and a host of virtual coffee.io, which she started as a way to bring the developer community together for informal connections and then continued because the community finds so much value in it. I actually heard about Virtual coffee in 2021, maybe even 2021 I believe, before I met Bekah. And every time I get to be around her, I honestly feel like I'm with a celebrity welcome. So good to have you here. You've done so much in so many different aspects for building developer communities and bringing developers together and developer relations professionals together.

Bekah Hawrot Weigel: Oh, thanks so much for having me. I really appreciate that. It's been a really great journey. I'm the baby on the DevRel conversation here today. I've only been here a couple of years, but I'm really happy to have been doing DevRely things for a while with virtual coffee and then moving over as the technical community builder at Deepgram. So it's been a lot of fun. Thanks for having me.

Rebecca Marshburn: Yeah, I think mean with the amount of experience combined, right? Whether or not it's a spectrum or a circle or we have everything from grassroots community created communities to IBM, which is a fast enterprise. I don't have to describe IBM people know what it is. So pretty amazing what the journeys that all of you have been on and in the companies that you've been on them with. And so glad to have you all here and let's dive in. Does that sound good? Awesome. Okay.

So we're going to start off with practical or this idea here is for delivering practical advice for the next generation or current generation of folks who would like to enter into the developer relations space. And so we wanted to kick us off with a little bit of context. Bekah, we'll start with you. Can you describe a little bit of the path you took to DevRel? And then we'll have Phil and Kelly dive into, and then we'll get into the media topics where we get super controversial.

Bekah Hawrot Weigel: I think I don't really have a path. I just stumbled into it. I was walking a path and unexpectedly took the wrong way maybe I'm not really sure, but I taught college English for 10 years before doing a bootcamp and moving into tech. And then I was doing some consulting work as a front end developer, but my background is in teaching, and so as I went through bootcamp, somebody on Twitter said, you should be blogging about this experience. So well, okay, I guess so that makes sense, right? And then my husband is a second career developer as well, and he was speaking at conferences and I just thought that everybody was speaking at conferences. I just thought that's what developers do, because that's what I knew. So I think I actually spoke at my first, I was less than a month into my first job as a front end developer freelancing.

And so then when the pandemic hit, my kids were all home. I have four kids and I lost my job as a freelancer, which I didn't really even have an interview. It was a conversation. And so I found myself interviewing for the first time for a new role, and that's kind of how virtual coffee came about, because I thought, you know what? I'm not the only one that is feeling this terrible right now. I'm sure that there are other people out there that are really feeling isolated, they're feeling alone, and so we should get together because I know the worst place to be is by yourself when you're having those feelings. And so I put out there on Twitter, does anybody want to join for virtual coffee? And that's how I came up with that very original name.

But we started getting together and I found that there were days where I was doing double sessions because people kept wanting to join, and it was that sense of community and belonging.

And so I continued to do some freelance work and still do virtual coffee. We started adding things like podcasts and monthly challenges and events and stuff, and it just kept going. And at some point, it was our first hack, Tober Fest in 2020 where it really seemed to solidify into something new in that this wasn't just a pandemic thing. We all want to be part of a community at some point. It doesn't have to be during a pandemic. There are lots of reasons why people can't get together in person. And as a mom of four kids, that was me prior to the pandemic too. And so I just continued to build on that community and go with what everybody wanted and to be supported by so many amazing people and volunteers there and to really understand that this is bigger than what I initially had thought.

And then somewhere, I don't know, about a year and a half ago, the Deep Graham reached out to me and said, Hey, do you want to come build community for Deep Graham? We're a speech to text API company. And I said, I don't think so. But then Michael kept asking like, Hey, maybe we should have a conversation about this. And so I continued to think about it. And then finally, I don't know if he wore me down or if I was just ready to move into developer relations after doing a lot of dev rally things for so long. And so I've been at Deep Graham Building Community and working with the developer relations team for about a year and a month right now. So I've been kind of all over the place, but I'm really happy to have found such a great community as part of the DevRel community

Rebecca Marshburn: DevRelly. I love that. What's your DevRelly path Phil?

Phil Leggetter: Well, it's great to hear about Michael hiring people. I think his first job in DevRel was at Vonage, which was my team. So again, very, very proud and honoured to have helped more people get into DevRel. My path was I was a software engineer. I think the roles I've always had were always building SDKs, writing documentation, create sample codes. So I wasn't aware of it because I was straight out of uni, but I was always serving developers through enabling experiences for them, not really community. The interaction I got was through support, not really through any official forums or open source or anything like that, but I was always passionate about serving developers. And then eventually, I think, I mean there was lots of opportunities for companies.

I was out to do a lot more externally, but we never did. But I encourage eventually encouraged companies to start blogging about what we were doing and sharing knowledge.

And then that led me to quitting my job, wanting to become a real-time web evangelist, which I just made up on the spot. I enjoyed real time web technologies. And then that led me into, again, the idea there was that I liked building things, sharing what was possible and helping others. And that took me into my first developer evangelist job, a company called Pusher. Along the way, I came across a book, an online book by Christian Hellman called well developer evangelist. com. I think it was at the time. He's rewritten it to be developer advocate.

com or as a new version. So that's how I discovered it. But it was that I think a similar desire to help educate and support developers was the thing that took me in the direction. It wasn't chosen path as such. I just ended up there.

Rebecca Marshburn: I love that there's a thematic thing. It's not that everyone stumbled, but you're on one path and then we're like, oh, this path is quite interesting. Maybe I'll fork, right? But something that resonates across, I think both yours and Bekah's paths is that there's passion involved for what you're doing or curiosity about moving into a space. And then certainly idea about knowledge sharing. What do you know that someone else doesn't know or what does someone else know that might help you? And so there's certainly a collaborative aspect there. Kelly.

I'm wondering if the pattern holds true or if I'm making a line between two dots and calling it a pattern.

Kelly Hillborn: The pattern might hold true. I mean, some of it I could have come on by accident. Some of it was very intentional. I didn't start writing any code until fairly late in my technical career. I started out, I'm not going to age myself too badly, but a long time ago, answering phones on a help desk, reboot your computer, reset your password setting permissions, and graduated into networking and systems administration, windows and Linux. I went to work for a couple of companies that were, now, you would call 'em cloud companies, but back then they were just simple hosting companies. You rack servers, you spin 'em up, you lease 'em out as fast as possible. Few iterations of director of IT and a lot of other roles.

And then I went and joined a startup, which I think that's its own podcast for all the stories that I have there.

And shortly after that, I joined a company called Soft Layer to build a startup programme. And the idea behind that startup programme was you give startups early stage companies, free access to use services. And back then there were only two other companies doing that. Now of course, there are a lot of companies that have similar programmes. And so I was really doing community development as early as probably 2009 before I even thought about any type of developer activities for developer relations. And when we're onboarding companies onto this, what amounts to infrastructure as a service, it's really not a developer skill. And so I'm really staying in that infrastructure side and the DevOps side more than anything else. And through the course of onboarding startups and working with founders and speaking at conferences and speaking in front of accelerators and helping people, it was a natural progression to start with Python and get into everything I could to help these developers build what they're trying to build so that they're successful on our platform so that I'm successful.

And so almost as intentional kind of, but really stumbled into it at the same time. And then the acquisition of Software by IBM happened, and then I was moved into a pure Devra role, and it was very, very different than even what I was doing before I was concentrating on developers and startups. And IBM's version was typical of ibm. It's just very, very different approach. And we were doing developer advocacy for customers or potential customers as well as developer advocacy for any developers you find out in the ecosystem. And so I have a very, very interesting and probably unique take on getting into DevRel and lasting as long as I have to be honest.

Rebecca Marshburn: Well, let's dive those takes. I think Suze had some ideas around what she thinks would be super helpful to hear and to dive into from your points of view. So Sue's take it.

Suze Shardlow: Okay, so like I said at the beginning, one of the age old questions about DevRel is how do I get into DevRel? And I think there is some sort of misconception sometimes and maybe a little bit of confusion as to how to do this or what you need. Because naturally people are going to approach the most visible people to go and ask them. And the most visible people may not necessarily have had the most accessible path into DevRel because not everybody can craft that big personal brand and get into it that way. And there are hundreds of people working in DevRel that you never hear about because they're getting on with it, and they are just not visible to the general populace, but they're visible to the audience that they are serving through their roles. So I kind of want to get some actionable advice out of you folks for people who want to get into DevRel and they're thinking, right, okay, in the current economic climate as well, I'm really trying to hang onto the job that I've got and I'm looking for a new job.

It's really difficult. I don't necessarily have a lot of time to spend on this, but maybe there are things that I can do in my current role that will serve me really well to moving into developer relations. So my question to you is, I'm going to come to you one by one to make it easier is which one skill would you advise people to hone so they can get their first DevRel job? And how can they hone that skill on very sort of scam time and money resources? So maybe how can they do that in their day job and then demonstrate that to a hiring manager? I'm going to come to you, Bekah, because like you say, you yourself, yourself as the baby of the group. So you have very recent experience of getting hired. So which one skill would you advise people to hone?

Bekah Hawrot Weigel: I feel like this is maybe a cop out and you want something more specific, but I think communication is the most important skill that you can have as someone on a developer relations team. And there are lots of different ways to communicate, and I think that's important to remember to communicate in ways that work for you, but also discover how other people communicate, right? Because developer relations is not about you. It's about helping in supporting other people in some way. So finding out, okay, how do you communicate? What is the best way that you receive information? What is the most effective way for us to communicate together? And then think about how you can support other people in the way that you best communicate.

So find the ways to match up those different communication skills. And in terms of growing those skills, it can be anything you could be writing.

It might just be you writing a daily journal of the things that you did get started there. It could be writing a blog post, it could be making a TikTok or doing a video or live streaming. But I think that it's important to focus on where your skills are good, but also don't be afraid to get out of your comfort zone either. So in terms of communication, I found that to be really helpful for me. It's easy to stay in like, Hey, I really like writing and I like to spend all of this time just focusing on this thing and taking time, but finding other ways to communicate has been really valuable for me. And also asking people for feedback on that too. So in terms of wanting to grow and become a better communicator, sometimes people give you feedback and that's great, but oftentimes things move really quickly or there's not opportunities for feedback. And so reaching out to people that you know and who you are comfortable with and saying, Hey, would you mind providing me some feedback?

I just gave this talk and I want to do better. Even if you think this is the best thing that I've ever done, there's always room to grow.

Suze Shardlow: Cool. Thanks for that. And Phil, you have hired people into Devra roles at all different levels. Oh, we've got another baby Devra in the background. Phil, you have hired people into all different levels into developer relations. What's your take on this?

Phil Leggetter: So I think the skills that somebody should focus on, and at the time, obviously they should focus really depends on, I think if they have an understanding of the role. Because in developed relations, there are lots of different roles from community management, from pure technical writing through technical writing into more blog posts, more acquisition focused type content. Then there's speaking, which can be live stream recording videos, which is different from doing a live stream, which is different from standing on sage and giving a presentation, which is different from giving running a workshop. So I think if you have an idea, you want to be in developed relations, but you can be specific about, okay, those are the types of roles that I'd like to do, or these are the skills that I have that I'd like to do more of. Then I would probably focus on the skill related to whichever kind of role you're looking for.

So I don't think I would've gone for an evangelist type role, which was definitely, well at a startup company is very general. It was like doing everything from SDK development to docs to blog posts, to running online competitions, to in-person hackathons, which were definitely a big thing back in 2011. I definitely wouldn't have chosen to be, I'm more of an introvert, so I wouldn't have chosen to go, I want to be in the community standing there in front of people. I would've gone from more of a educational role. So through to maybe the blog post content, probably not live streams, probably not videos, whether that would've been good for me, I don't as an individual, my own growth, I don't know. But I think an easier path for me, a more comfortable path would've been I'm going to focus on writing some content, which will be technical content, maybe do a bit of library work, good read mes a bit of blogging, and then I would've focused there.

And I think I would've found a way into a company through that approach. But if you are really excited about being out in the community, then, I mean backstage, we were talking about becoming an influencer, and that is a path into develop relations, but it definitely isn't for everybody. But some people may be very excited about that, so may want to focus on the personal brand. And I do think back when I was hired in by pusher in 2011, that would've been ultimately what they were looking for from their personal in dev role. Although I felt I brought a lot more value through the product side of my work, but they really wanted awareness. They really wanted acquisition.

Suze Shardlow: Yeah. Yeah, very true. Very true. And I think that's a whole other table, isn't it? All the different roles and all the different concentrations of folks in, because you can get all those different concentrations in one team. Some companies have more than one dev team that have different focuses as well. Kelly, you've recruited people into dev roles in different organisations. So what's your feeling on this?

What's the one skill you think people should hone if they only have time to do one?

Kelly Hillborn: Well, I think Phil and Bekah gave the best answers already. So I'm having to think fast on my feet here to come up with something decent. That's not true. There's a lot there. Dele, whenever anyone asks me what DevRel is, I always give the kind of canned answer of it's our job to lower the barrier of entry for developers to utilise and using our products. And so to me, that always breaks down to education. And so I really want, you don't have to, I've hired advocates that have zero experience that come straight from engineering, and they just have this desire to be an advocate. And I think that's fantastic because for me, it's easy to teach someone to find that passion.

And Phil's right, you don't want to put a writer on stage and you don't want to take someone that loves being on stage and sticking 'em behind a computer to write all day.

It doesn't make a lot of sense. And their passionate at work is not going to show through. And so to me, it's important to figure out what they're best at and they can hone that skill. And admittedly, being an influencer is part of that. It's not an end all. It's not a be all. I don't think that's a goal. I think that's more of a byproduct.

For me personally, I like the idea of having a large following and people that can amplify your message and see what you're doing. But again, to me that's more of a byproduct. And so I really aim for that empathy and education more than anything else. If you're going to be helping people solve problems, getting started implementing your products and services or whatever the case is, that requires a lot of patience and empathy and a desire to help people.

And so my best advice for someone that wants to get into DevRel is start doing that. Most companies that have a product, even in your company time, spend time in the support channels, spend time in Slack if they have a discord or discourse, spend time in there, answer questions for people, be there, be there. And what I'm describing is advocating. Advocating for that company, advocating for that product, advocating for yourself without trying to build a following. This is more along the lines of, I want to help people be successful with what we've got going on here. And that's an advocate. And if you can learn those skills and you have that empathy, it just shows you're in an interview and they say, well, what do you do in your free time? Spend time on Discord and discuss and helping people and making sure that they can really utilise everything we have to offer.

And it's not frustrating. I can tell you anything I want to download, run or instal. If it's frustrating, I skip it and I move the next thing. And most people that I know are very similar. And so if you can make that journey and that path easier, you're already doing the job. And so to me, that's the best thing that you can learn and it's the best thing you can showcase yourself in an interview or to a hiring manager say, I'm already doing this now I just want to get paid for it.

Suze Shardlow: Yeah, you do hear a lot of people say that because developer relations is very much the Swiss, I mean knife. It

Really is a lot about all different things and you've got a lot of skills that you bring to the party, and that's why not everybody can do it. It is quite a hard job and it takes in a lot of different disciplines. And like Phil said earlier, depending on the concentration arena, it might have a bit more of this and a little bit of that one, but it's always going to be a big mixture. And Kelly, I'm going to come to you again with this next question to be fair, because I don't go in the same order again, then you'd be like, oh, everybody already said what I wanted to say. I think a lot of people look at getting into DevRel and they think about coming in as a junior or coming in at an entry level, but actually that's not necessarily the case, is it? Because you could have quite a long career behind you. Like me, I had 20 years doing other stuff and then I came into developer relations. So can you talk a little bit about how or what you would look for or the kind of people that you would hire into a senior DevRel role as their first developer relations role as opposed to coming in at the entry level?

Can you talk to us a bit about that?

Kelly Hillborn: Yeah, that's a tough one. Now I don't have the scapegoat of saying they gave the best answers, so I have to put myself out there. No, I mean in that scenario, it goes back to what I was just talking about. If someone has the engineering background, and again, there's so many roles in general, you don't necessarily have to have an engineering background, but to be senior, that means that you can almost singlehandedly answer almost any question that comes through, create, maintain, and host your own events. Mentor junior advocates. There's a senior, to me is a really big word that means it's got this all, like you said, a Swiss arm knife, this all encompassing persona that people have that says, you're going to help, you're going to mentor, you're going to teach, you're going to do all of these things. And if someone's been, they're senior in their career, they've done some type of teaching, they are already creating good content, they spent time as an engineer, I would've no problem moving them into a senior role by any stretch.

But just with the understanding that, sorry, I'm going to back up. My general philosophy about a role. If you move into a role, it takes you a year to be comfortable, right, wrong or indifferent. That's the way that I view the world. And so if I have someone come in, even as a senior, they need that year to really just to absorb everything, swallow everything, get moving, and have a solid understanding of where they sit in the world and where they're going to be in the next three to five years. But even that being said, you can walk into a senior role and really perform super well. I've seen a few do it that are just still the best advocates I've ever seen. And they came straight from product to me and they just exploded.

They were genius. And so yeah, there are those times, but it does require that you have done a few things, education, content creation, a desire and ability to help others. I can't say the word empathy enough. It's hugely important. And you're there, you exist, you've been online in forums and in Slack and just helping others. That's what you're known for. Yeah, senior all day long.

Suze Shardlow: Yeah, and I think it also just from my personal experience as well, it's about having those business skills that you can only get from having risen up the ranks in some discipline that you're not necessarily going to have honed with very little experience because you haven't been exposed to certain situations. So yeah. Phil, I'm going to come to you with the same question as well, because you've managed a number of teams and in your teams you've had a lot of different levels of folks in your team. So what's your take on this question?

Phil Leggetter: Yeah, senior in the places, I mean, we had this, and I think it's quite common, P three was developer advocate. This advantage, and I've seen this similar at other places. P four was senior developer advocate, P five, and I always get this mixed up. There was staff and principal, so could get, so if you think about senior, it's actually only, I think there was a junior P two, but we often hired de developer advocate P three. So it's only in the middle, the senior. So often we did hire quite a few people who were already working in communities but had a senior engineer role somewhere else. But they were definitely, as Kelly was saying, already doing the job of being an advocate for the community really that they were in. And those communities, very specific technology, I mean programming languages in our case.

So that's what we were looking for.

We're looking for somebody that could be a conduit of communication to that community, making sure we're building the right things for them and making sure we're being seen positively in those communities through often supporting that individual and doing what that individual thinks is best for that community. So I think the skills that those people maybe were missing was more of the business aspect side of things was alignment with company goals, making sure that there was whatever's trending in the Python world, there is a use for that within a communications platform at Vonage. Or if the goal at the minute is if quite a lot of companies that are new, if nobody's really heard of you, then just hiring that individual and them going, Hey, I now work for Tigers data. That's not good enough. You've got to go, okay, well, how do I bring value to the business and value to the community and line those things up?

So I think that thing that's been the hardest part. Same when I was at Aley as well. We had some amazing developer advocates, amazingly creative, amazing engineers. Those are in an advocacy role. If you've got someone who's a fantastic engineer, fantastic, they've creative and everyone's just like, wow, everything they do is brilliant, but then making sure that what they're doing aligns with your company goals. So if it's like we need to be creating content that's going to result in signups, people aren't always driven by that, and I totally get it, but the business will not exist if you don't hit your goals. So that's been the hardest part I think, of bringing people in that haven't done a DevRel role and have been community focused and have been a great engineer or have been a fantastic community manager somewhere else, but then haven't in the companies I've been at anyway, being able to always as easily map the company goals to the work that they do.

Suze Shardlow: That is super important, especially in the current climate where everybody is hanging on for dear life and we really have to, sometimes we have to really just full on justify what we're doing. But I definitely have to make it link back to the company objectives.

Phil Leggetter: Kelly said earlier around, you're not really into a role for a year. Some companies may not exist in a year, so they've got to come in. And sometimes, certainly if you're hiring a senior person, okay, we've got to be hitting some goals quite quickly because I now work at a seed stage company. We probably won't exist in two years if we don't hit our goals this year.

Suze Shardlow: Yeah, I've heard some bad stories about folks that haven't even been in a job for a year before. Companies have decided to make changes as well. So if you can hit the ground running, then all the better, really. So yeah, I think that kind of marks out the difference, doesn't it? You're not going to be given that handholding. You're going to have to just hit the ground running and get on with it. So Bekah, I know that you are very visible on Twitter, and I don't want to keep coming back to this, but you said it like you are the baby of the group, so you've got a various experience of getting into DRE from the beginning. And a lot of people do approach you, don't they?

And they say to you like, Bekah, can you tell me about this? Can you help me? I really wanted to do what you're doing. Can you tell us about some of the assumptions or misconceptions that people come to you with and you're thinking, oh, hang on a minute. Maybe I need to kind of guide you because you've got this idea and you might be leading yourself down the wrong path. Are there any common misconceptions or assumptions people come out with?

Bekah Hawrot Weigel: I think the first one is that you have to be an extrovert. And I think, Phil, you said earlier that you're an introvert. I'm an introvert. Most people guess that I'm not an introvert, but I think that it comes down to doing things that you feel comfortable doing and also being able to get out of your comfort zone. You don't have to be an introvert also. You don't have to do all of the things, right? That's the other thing. Well, I'm pretty good at coding and I can write a blog post, but I can't speak in front of people and live streaming is terrifying.

Then don't live stream and don't speak or don't pursue jobs that have that as one of the primary goals. You don't have to be able to do all of the things, find the thing that you're good at, the thing that you are interested in with DevRel, and then see if that seems like a really good path for you.

Suze Shardlow: Yeah, yeah, I agree. And it is really easy to kind of feel not inadequate, but feel like you are never going to get there because you see these people and they seem to be the egos of DevRel, this quadruple threat, and you're like, how am I going to do all this? Because like you say, folks are introverted. I'm definitely introverted. I do not, no offence to anyone here on the call, I don't really get my energy from being in big groups of people. I'm much happier just kind of getting on my stuff on my own, but I don't mind doing the performance piece. I don't mind doing the live streams. I don't mind doing the talks, but I very much like it to be something that I have control of.

And I think there are jobs like that that exist out there. It's just a case of finding them. And I think folks really need to have maybe have a reality check and go and look at job adverts and really go and speak to more people, like a wider variety of people and find out the reality. Because I think if you focus on the people that are famous or super visible or have the personal brand, you're probably not going to get a full picture of what you could get involved in. And maybe there's a missed opportunity there. Yeah. Rebecca, do you want to kick off the next segment?

Rebecca Marshburn: I do actually. I am going to lob a curve ball. It's not like a fast curve ball, so we're going to all see it coming. But Phil, you touched on something that I thought was really, really, really interesting and all three of you did. And so I think maybe to wrap that up a bit, it really sounds like you're lean into your strengths. If your strength is speaking, then go there. If your strength is writing, then go there. If your strength is personal brand building, then build it away.

And then don't underestimate the power of what you are very good at and becoming and maintaining your joy in doing that. Like Phil, you said the power of a good read me and do not underestimate the power of a great read me. That is such a display of empathy when you set the context for someone else to get into your own head through an amazing read me.

It's like lean into that. Something else that came out of that I think is right is this idea of, now, maybe it's just in this context, economic context or probably always is like how do you connect what you are doing and to the success of the business? How do you actually measure that? And sneak peek is, we actually have a DevRel roundtable coming up in April, I believe, called DevRel and Dirty Words, and it's about the linkages between DevRel and marketing and sales. And for a long time it was like, okay, well DevRel does its thing, or at least a general idea. It was like DevRel does its thing and then marketing sales do. It was like DevOps, you dev it and then you throw it over and you're like, okay, go opposite. And there doesn't need to be, and maybe in today's climate cannot be such a thick wall between those things.

These three things have to handshake because they all affect the outcomes of the business. And so I would love to hear from you all if a career path or something that we have to embrace as people that are, is that something that people entering their career, whether they are tenured seniors coming in as new dev re people, but senior in their space or entry level kind, newcomers just walking in, how might you advise someone to think about the relationship between DevRel and sales and marketing?

Kelly? We will actually, no, I think we have not yet kicked off with Phil. So Phil, can we kick off with you?

Phil Leggetter: Well, so at the minute, the role I'm in, one of the reasons I guess a bit of a personal journey is that I am quite driven to achieve a certain level within an organisation. I'd like at some point to be on a C-suite sort of thing at Vonage, I was kind of at that, but it was a very split org. Anyway, so I'm at a seed company now and I'm, there's not a board of directors because we're so small, but I'm one of the senior people on the team, and effectively I run marketing. So within developer experience is marketing. I mean DevRel team, the developer experience team, whatever you want to call it is marketing. And I think that works at smaller organisations who are entirely developer focused. So in this book it talks about developer first or developer plus, developer first being the end user is a developer. So I think actually marketing being develop operations or developer experience at these smaller companies makes a lot of sense.

The relationship is that function, that is what you are doing in the developer plus or in larger organisations where you've got multiple personas you're trying to reach, they're not always software engineers then. I mean, ultimately it's that age old conversation, where will DevRel set? And I think again, if the goals of what your DevRel team is doing is kind of top of the funnel awareness acquisition, then the DevRel team should sit within marketing and work with marketing and work. I think the best way for it to work, the best way I've seen it work is to be entirely working within that function. So goals aligned, involved in a lot of the same conversations. I mean, sometimes if it's like demand gen paid advertising, okay, don't involve the DevRel team that although you probably do want them reviewing your adverts and things like that, because trying to reach the people that they speak to all the time. So I think the best way for marketing DevRel to work together is if their goals are aligned to be the same function sales.

I'll be completely honest, I haven't seen DevRel and sales work together very well at all anywhere. I think there's a completely different mindset that a lot of salespeople have that does not resonate well with people that think about education as the primary focus. We've seen the emails once someone signs up for a new platform, if it comes from a sales team, it's persistent. There's 10 of them. The wording is different if it comes from people with more of a operations mindset, it's about education, it's about asking questions, understanding what they're trying to do. You can get some really good salespeople that do that as well, but the majority of it is can we jump on a call? What's your use case? What volume are you talking about?

So I don't have a great answer to the sales alignment, although I believe sales is fundamentally important for certain types of businesses to succeed. So I wish I had an answer for the sales side, but I don't.

Rebecca Marshburn: So I will say I think the team at TEMPORAL does this really well in terms of heard developer advocates there and sales team be like, we've actually never worked so well together than we do here. So we can dive into that later, but that might be something to dive into in terms of teams that are seeing success with that. Something that I maybe want to, another dimension I want to add to this question for Kelly and Bekah as maybe should DevRel also be looking to work better together with sales or should those two things as we look into career paths in the future and driving those business outcomes, marketing is certainly a really integral part of that. And should DevRel people also be looking for ways to collaborate and include sales? Or is that something where it's like it's just still not the right intersection? Because I think Phil's bringing up a good point where it's like we haven't traditionally seen it be done well and should it be something that people should be looking into doing? Well, I see Bekah nodding, so Bekah, do you want to take it?

Bekah Hawrot Weigel: I don't know that I don't have an answer for it for sure, but I will say that this has been a question that's been on my mind a lot lately, and it's kind of a personal project that I am working on in terms of being able to tell the story of your company, your community, and yourself. And I think that storytelling is key to creating connections. And there's a company that does it really well. The company 3M most famous for post-IT notes, I don't know if that's what they're most famous for, but that's what I like to go with. I used to have, actually, I have a wall of post-IT notes over there now, but they focus on the storytelling culture and it's top down. It's who they are as a company and then how they share that story with other people share. And I know that their sales team is actually trained in storytelling.

So it's their job to go in and to be able to tell stories to the people that they're selling to. These are the products that we have that would really help you. And they don't do it in a sales way. They do it in a storytelling way because when we tell stories, we connect with other people. And I think essentially we are all telling stories in different ways. And so if we can figure out how to create a storytelling within a company culture, starting at the very top and moving down, then I think it's much easier to make those connections with marketing, with DevRel and with sales because you're all telling the same story. It just might be a different path to that story. And making that connection helps you to curate that story together and figure out what's most effective for your audience member.

And so thinking about it from that perspective, we have an audience. We all have an audience. What story most appeals to them maybe is that connection that can help to unify those voices in a way that allows us to work altogether.

Rebecca Marshburn: I love that. Okay, storytelling. That maybe sounds like something to lean into in terms of practical advice to lean, well, I just said to lean into, but let's lean into it twice. Kelly, what do you think?

Kelly Hillborn: Well, I'm glad I'm last. I could talk about this for pretty much the whole duration of this call. This is a conversation that I have all the time, and they're both right. Storytelling is huge, and so when someone asks me what I do or what value I bring or anything depending on where they're at, heavily dictates my answer. If it's the chief marketing officer, well, I'm seeding the market for the next generation of X users and for sales, it's like, well, I'm educating your next customer, so if I'm doing my job properly, your job is so much easier and they understand it because the time to close a deal is faster. You have honestly, and you wanted to go controversial. We're going controversial. This is one of those conversations that well can get me in trouble, particularly in an OSS environment, like working with sales will get you in so much trouble, but ideally you do want to work with sales.

I mean sales, you don't want them selling at your meetups. You don't want them adding sales slides to your presentations. You don't want them getting into your business and crossing that line. You have a community contract that do not break this contract or you are out. You cannot come to my meetups, you cannot come to my events. But that's kind of an ownership thing. You just heard me, my events, my meetups, my stuff, which you have to work with sales, you have to work with marketing. It's part of the job.

It's that simple. And so your goals, I have a leadership philosophy. It's slightly off track, but leader should very, very simply create and share a vision that the team grasps and adheres to and follows and then creates goals that the team understands and are very easily achievable so that they understand where they sit within the environment in the organisation.

And those goals ladder up whatever organisation, and you can be in marketing, you can be in strategy, you can be in product, whatever the case is, your goals ladder up throughout the organisation so that you don't have to have these conversations very often, and you make sure that everyone on your team understands those goals and where they sit in the organisation and how their efforts benefit the entire company from the ground up to the top. And everyone has that understanding. That doesn't mean that your internal education stops because again, you have these conversations every day, but you do have to work with sales. If someone comes, you're in a large organisation, not a smaller one, you're going to end up at a coupon or an event or somewhere where your people or yourself, you're doing booth duty, you're going to hand over qualified leads to sales.

And so the understanding that I try to have with sales is that's not my job. Leads are not my job. It's a glorious byproduct of all the beauty we bring to the organisation, but it's not my role. So I'm not going to be a goal. That's not going to be a task, that's not going to be a KPI, but I will end up giving you leads and I will educate your future customers so you don't have to try so hard. So if you have customers that go to a meetup, your sales process is easier. So it's on you to send them my way. If you want people to learn and adopt faster, send them the community and the DevRel route, send 'em to our Slack, send 'em to our content.

We have a lot of places. We have a whole series on getting started. You want it easier, use our stuff, but don't sell to my group.

Phil Leggetter: This. Understand, that's be another question actually. What are the specific activities? You've talked about booth duty, I mean that obviously is in person, it's standing next to each other, but often it would be from my perspective, oh, can you do a webinar for a specific customer or can you come and fly over to somewhere else and give a one-off workshop for someone? I mean, are there any other specific activities that you felt that there's a lot of collaboration between sales and DevRel, or is it normally at arm's length?

Kelly Hillborn: Most of the times it's arms length, but it's okay to do that. What I don't want to do is have them being sales change our job, because at that point, we're abandoning our community and our developers, and that's not okay. If they need assistance or help, that's fantastic. If they need help with a certain customer, send them to our meetup. That's fantastic. I'm just going to throw something out there. They're in Berlin and they want to learn about vector search. I'm going to go do a meetup in Berlin about vector search.

You send them, and in the course of our day-to-Day, where we're still supporting our community and our users and our developers, we will educate them on everything that you need. But I cannot take time away from our community and our developers because that's just horrible to educate a customer. That's not my job.

But if we can meet in the middle, that's awesome. That's fantastic, and I will help you out all you want. There are occasions where we actually have in multiple roles gone and just train the customer because it was in line with something we were already doing. Like, yeah, we're going to go do DevOps days, Berlin, there's a customer there that we're going to train. It takes an hour out of a trip that's already scheduled. That's not a problem, but that's a slippery slope. You don't want that to become the norm. And so I generally try to find a very even middle ground that says, we're already doing these activities.

Come in, I'll give you a hug, bring it in, and I'd love to have you there, but I can't abandon the community that I've got to go and do this. And so, and not only that, if you have those clear goals in that clear vision, you empower your developer advocates honestly to say, no, I don't like saying no.

I like saying I'd love to, but we need to have a conversation. But if you take all that out of the way, you're actually empowering your people to say no, because they know their goals. That is not in line of what we're trying to do as an organisation. If you want me to stop what I'm doing and work on this, that's a conversation. And so goals are so huge and it has to work for marketing and sales and strategy, and everybody across the company has to understand you, where you sit, what you do, and how you affect them, and it makes your job so much easier. I could have talked forever on, I'm eating enough time and I apologise.

Rebecca Marshburn: I think that, so Kelly, internally at Common Room, a lot of times we talk about sales and we talk about it in terms of value matching, being like, Hey, let's say you sell for a year, but if the value isn't matched there, then they're going to churn and after a year, you're not going to have that customer. And then you forward all that time and resources into bringing on that customer. Customer. If the value match isn't there, then you're not going to have that customer. And then that's just the goal is to make sure that you are bringing on the right customer, getting the right prospects in the door that are the right, that would get the right value, understanding how to make sure that they're getting the value from what you're selling, and then that value match considering or assuming that it remains value match and that they continue to grow with how they're using your product and your product continues to support how they want to. That sounds like what you're doing as the developer relations side, where you're like, Hey, if people come into the community first, if they learn from our Slack, our Discord, our discourse, our discuss first, and they understand where they want to go with a product, and now they also understand how our product matches the value that they're looking for, then we've made your job so much easier because you're not just a salesperson. You are a value matching person, making sure that this connection is the right one for a long-term journey together.

Kelly Hillborn: And that also it helps everyone, but keeps you out of the process. And I believe Common Room calls that a community qualified lead, right?

Rebecca Marshburn: Yeah.

Kelly Hillborn: Brilliant. It's absolutely brilliant. I don't want it to be a goal, but I do. We've got the jargon. I do want it to be a healthy byproduct.

Rebecca Marshburn: One more thing I wanted to touch on there that I think the three of you sort of touched on as, so we talk about community codes of conduct, right? It's so important to have a community code of conduct when you're going to be hosting a community. But I think the three of you touched on this idea of an internal community code of conduct. So it's not just here's how you should act. Here's the expectations of our community members, but here are the expectations of us as people who serve our community members across the organisation. This is a space for learning. This is a sacred space for asking questions. This is a safe space that will or will not be recorded, whatever that is.

This is not a space for selling. This is only a space for understanding where your customer is at to then inform that story when you have sales conversations down the line if there's a value match. And so I think I really wanted to highlight that because I think each of you said that in your own ways around, it's not just about what you do externally, but how you educate people internally. And I think an internal community code of conduct is a very powerful tool as you bring other people from the organisation into those conversations with community members.

Kelly Hillborn: It absolutely is. We actually have a presentation we give to all newcomers that goes over the community and everything that we do and the rules. You can come here to learn. You can come here to immerse in the community and really get a good feel for everything. No selling. There's this list of rules that you have to agree to or please don't. Please don't break the rules.

Rebecca Marshburn: Yeah. Thank you for that. Suze, we are moving toward rapidly the finish line of the conversation. I want to know if you wanted to ask our panellists for any parting words of wisdom, advice, or mistakes to avoid.

Suze Shardlow: Yeah. So before I do that, I just wanted to touch upon something that everybody just said, which a thought that occurred to me was that, and I've seen this in a lot of organisations, people tend to care about what they're tasked with and they think that's what everybody's tasked with. So they think everybody needs to be working to help that same goal, which isn't necessarily the case. But the other thing I wanted to say to anyone who does want to get into developer relations and maybe is working in tech already, is that I actually think that people working in technical sales, so like solutions architects or in technical marketing are really good candidates for coming into developer relations. I've seen that happen a lot where people have made that switch. They have a lot of the good skills that are needed. They have a lot of understanding of the potential customers and the people that use the product.

So if you are in those sorts of roles and you're thinking about getting into DevRel, then I would say you probably have quite a lot of the skills and experience that are needed. But you have to change your mindset. So you need to think about, right, what is this audience I'm going to be speaking to in developer relations? Because it's going to be different. The messages are going to be different and the outcomes are going to be different. But yeah, definitely consider that if you are in technical sales or marketing, it's definitely a route that I think is open to you. So let's go into the final question then. I think, let's see.

Let's talk about mistakes. Let's talk about things that people really need to avoid. Things from your bitter experience that you really don't want anyone else to suffer. Don't worry about how bad it is. Let's just get it out there. All made some really bad mistakes or being led into them by somebody. Let's start with you, Bekah, because you have a recent experience of getting into death row, but you're also talking to a lot of people who want to get into it.

Bekah Hawrot Weigel: I thought you were going to say you have a recent experience of making a big mistake. What is it, Sue? Can you tell me?

Suze Shardlow: No. You've got recent experience of getting into Debre, so I'm sure you've seen a lot of pitfalls and maybe some people trying to take you by the hand and lead you into something that wasn't good. Maybe not.

Bekah Hawrot Weigel: So I think that last week I met with my former team lead, Michael, and we went over my strengths and weaknesses, and one of my weaknesses he said is You say yes too quickly. And it's very true. I hear an idea and I get very excited about that idea and I want to run with it. And a lot of that comes in the past working not on a DevRel team, doing a lot of running things myself. Yeah, I can handle this totally, but it may not necessarily align with what the business goals are, what the strategy is. Or I was a teacher, so I ran my own classroom and I did the things that I wanted to do because it made sense. Maybe the biggest mistake that I've made over the last year has been saying yes to doing all of the things then at the end of last year, feeling like I just wanted to lay down and die for two weeks because I was so exhausted.

But I also need to take that step back and create that space to say, before I say yes, I need to think about how does this align with the goals of the business? How does this align the strategy and the story that I want to tell for community? And how does this look three months down the road? Does this make sense or is this just me being really excited about this thing that might be really impactful right now or that a bunch of people might jump on board with? And not recognising that there's a lot of other things that need to come into consideration before saying yes.

Suze Shardlow: Yeah, that is good advice for anybody in any job, I think before you say yes, because yeah, saying yes to everything is just totally infeasible, isn't it?

Bekah Hawrot Weigel: Yeah.

Suze Shardlow: Yeah. But it's hard though. Sometimes you get pressure and I think sometimes when your manager says, you say yes to everything, it's like, well, boss, you asked me to do it. What am I supposed to do? Sit there and say, no, really? I don't know. I think that's a whole other thing. It let's do a talk and have to say no to your boss. And it's

Bekah Hawrot Weigel: A tendency too, I think being early career at something, you want to say yes to the things right, because you think that you should be doing all of the things, or you need to prove that you can do 500 things. But I think as Gantt Leor who emphasised to me prior to this, when you say yes to everything, you're saying no to other things as well. And so kind of flipping that mindset becomes really important. What is this? Yes. What does this mean that you're saying no to? And that might be your own free time to recover or to really deepen your skillset in one particular area.

Suze Shardlow: Yeah, and it's hard when, like we said about the quadruple threats earlier, when you're seeing all these people doing all the things, it's really hard to remind yourself that you don't need to be doing the same. So Kelly, you said that you are currently in between jobs, you're evaluating your options. What mistakes are you going to avoid on this journey that you're on now?

Kelly Hillborn: There are a lot of 'em. Luckily I haven't made any that are earth shattering in quite some time. I can see a lot of people saying yes very quickly. I've taken that a different route and saying, I don't want people to just hear no from me. And I mentioned that earlier where I don't want to say no, but I also not going to agree to the demands of someone else if it adversely impacts what I'm doing as far as mistakes to make or not to make. I find that the mistakes that tend to cause me problems are the ones where I didn't have all the information. So there's two things that I want to impart to people. Number one is if you're going to join DevRel, I would like everyone to just have a promise to themselves to be genuine and be sincere.

If you offer to help someone, don't make a hollow offer.

Help them. If you say, Hey, reach out to me if you need anything, that literally means reach out to me if you need anything. And you are promising to help them through it and keep that word will travel very quickly of you being a helpful and genuine person. As far as mistakes go try to have all the information before make a decision. Another philosophy I have is if I go into a new organisation, I don't do anything for about 90 days. All I do is learn. I listen, I talk to everybody, and I don't make any changes or anything earth shattering for about 90 days just so I can really understand everything and not what's going on. Why is it going on if that's not really clear, okay, why was the decision made to go that route in the first place?

So I really understand what's going to happen when I amplify it or shut it down or whatever the case is.

And so most of the mistakes that I've made, I dunno, in the last 10 years or so, are generally I didn't have all the information and so I made a mistake and there's like, oh, well, I didn't know that. And then behind back of my head, well then you shouldn't have made the mistake dummy, or you shouldn't have made the decision, don't do that. So really trying to have all of the information that you can possibly have before making a decision, even if that's about career, if you're starting a new role, make sure you love the technology and you love the people and you love the company, and make sure you have everything you can possibly have to make the best decision.

Suze Shardlow: That is definitely something you can learn from when you've made that mistake

Kelly Hillborn: Frequently

Suze Shardlow: At least once. And whenever you look back, you always know that you made the decision based on the information you had at the time, but once you've made that mistake, you know that you have to gather more and where you might be able to get it from. So yeah, that is definitely good advice. And Phil, lastly, Phil?

Phil Leggetter: Yeah, I mean, I'll continue that and kind of put it on the two sides. I think there's a big thing certainly for people that have been in DevRel for quite a while, that are interviewing for new roles that they kind of want to have a few conversations and then the decision be made. And I get that some people have the experience and have the online collateral to justify that they know what they're doing. But the thing is, part of it is to actually have a moment of working with that company, you're potentially going to join to learn from them to understand what that working environment's going to be like before you make that decision of taking a job. It should be a big step. It should be a big thing, and it should be a commitment. So take the time to genuinely understand each other and to work with each other.

So that's the individual that's home. But also I've been very, I've made mistakes in the past in terms, sometimes they've been great decisions, other times they've not been good decisions. But I get very excited in the interview process if it's clicking with someone and I'm in the position of authority and I can go, right, I'm going to make you an offer now. Now that's just not good. And I've done that a few times, but I've been so excited about the people I've been speaking to that I'm like, okay, let's just start working together. So on both sides of it, you've got to really understand what the relationship's going to be like, what the job's going to be like, whether you can do the job or you can really, as an advocate anyway, you've got to love the product. You've got to be genuine about that.

So that all, having all the information is definitely take your time with that interview process on both sides of it, whether you are the hire or the person, whether you are the employee or the employer, potential employer or employer. And then the last tip is for more junior people getting into DevRel that you may not have all the skills required to be successful in that role yet, but you're being hired as a junior person for a reason. You have potential that you can do this role given time, but from your perspective, you need to make sure that the company that you're joining can give you that support that you need, don't join. So for instance, I mentioned earlier, we've only got a certain amount of runway.

As a seed stage organisation, we need everyone to come in and hit the ground running. We can't hire junior people at the minute. I would love to be able to hire junior people, but if I'm spending half of my time helping someone succeed in their role, I can't perform as an individual contributor for half of that time. So as the person that's being hired, you've got to go, okay, what stage is this company at? What's the expectation from me? Am I going to get the support I need to be successful here, or am I going to join and within two months understand that, okay, I'm making a few mistakes that's completely expected of someone in my stage in my career, but their responsibility as the employer is actually to support me and they're not giving that. So make sure as the person being hired there in the junior role, that you're joining a company that has that structure to support you in the role that you're joining for.

Suze Shardlow: Yeah, definitely. And what you just said reminded me of something else. You see a lot of job adverts for you are going to be the first death rail person, or you are going to be setting up the team. Just be really careful about that. Unless you're super experienced and you have done that before, it could be really, really, really challenging and quite horrible because you may not ever get that promised team. What you think DevRel should be for that company may not be the reason why they've hired you. There might be a big disconnect. And because you're the only person, you don't have anyone behind you to help you fight your corner.

So it can be quite a lonely place. So yeah, if you see anything that you're going to be the sold Evel, just treat it with a bit of caution. It's not necessarily bad, but definitely do your due diligence there and make sure it's the right fit for you all. The Rebecca. Yeah. Yeah. Like Kelly said, make sure you have more information, more information than you think you're going to need. So yeah.

Rebecca, shall we wrap up?

Rebecca Marshburn: Yeah, all I can say is thank you all for not only being here to discuss DevRel, DevRel things for an hour, but over an hour and for diving into things that felt comfortable, uncomfortable, and everything in between. It's such a treat to have you all. And Sue, thanks for letting us co co-host, what a fun thing. Happy Valentine's Day from the United States.

Suze Shardlow: Happy Valentine's Day, everyone. Yeah, thanks everybody for coming. Hope that all the viewers enjoyed it and it gave you a bit of food for thought.

Kelly Hillborn: Thank you. Thank you. It was fun. Happy Valentine's Day. Thanks for having us.

Rebecca Marshburn: Thanks bye.