Managing DevRel teams

Matthew Revell: So talking about managing developer relations, I think I was interested in this particular topic because to me, the the nature of developer relations seems to lend itself to maybe a slightly different approach to management. I'd like to talk through some of those those things, or maybe you don't agree with me and you think it's just like managing any other team. But first off, I'd I'd like to I'd like to ask, what is the the number one challenge of being a DevRel manager? So, Mary, you you you run developer relations at Camunda. So what what for you is is the toughest part, would you say?

Mary Thengvall: I think the most difficult thing is keeping track of everything that everyone is involved in. So I've got a team of there are 14 of us these days between community management and developer advocacy and developer experience, and I directly manage nine of those people. And that's usually on the upper end of, like, how big of a team should you have before hiring middle management. But generally speaking, most teams of eight or nine people are focused on a similar goal heading in a similar direction. And we are, but that goal is far more broad than many teams are, I think.

And so making sure that I know what are the programs that we're currently working on, what are the projects that people are currently doing, what's the status of each of those projects and those programs, how do I unblock people and make sure that they have the help and the assistance that they need suddenly gets far more complex because one person on my team might be responsible for running two different programs and also doing a couple side projects, and that's just one out of nine. So for me, that's that's been the hardest thing is just keeping track of what's going on, how do we know, how do I unblock you in the limited amount of time that I have on a day to day basis.

Matthew Revell: Awesome. Thank you, Mary. Michael, how about you?

Michael Jolley: I'll I'll kind of pair it, Mary, there. I think it depends from probably, like, the size of your team. Right? So, like, at at Deepgram, there's seven of us, including me, and it started out just me. So, like, when you hire the first one or two, it's not a matter of knowing what everyone's gonna do.

It's a it's a matter of prioritizing what's the most important because there are not enough hands to do it all. And then as you scale, like, now we're with seven, I'm like, Mary's over here. Like, I've got nine direct reports, you know, and I'm topping out. I'm thinking, oh, jeez. I'm I feel like I'm topping out with six.

You know? I tell my upline all the time. You know? There's a you know, heck, Jesus only discipled twelve, and one of them fell by the wayside. And I am no Jesus.

So, you know, there's a point where, you know, we've gotta bring those numbers down. Right? And, so so, yes, keeping up with everybody at that scale. So there's it depends on the size of the team, I think. As as as you grow, you you it's easier to get more things done, but it's harder to manage all those things and know where they're at the same time.

Phil Leggetter: Phil, you've you've run a a DevRel team the size of a small country previously. So, I mean, how how do you how how has your experience been?

Phil Leggetter: Look. I mean, definitely, the operation size side of things, as Mary was saying, can be very difficult. And and and in that situation, we I mean, split things up in a very similar way. So this this was at Nexmo and Vonage. So things have been a very similar way.

And but, ultimately, we we had that I mean, middle management, we had directors of developer experience, developer education, and community. So it was a you you're kinda shifting the responsibility down and you're trusting your team and coordinating across those, in that case, those three things. I I think the biggest thing I struggled with was was, I mean, people management, I think, is the most important and also the most difficult. Every individual is unique. They have their own needs.

They don't just have a job. They have a life. So managing their expectations, working with them, trying to align an opportunity within a business to what they want to do in their life and in their their career, I think, is always always very difficult, very, very rewarding when it comes off to see people progress and succeed, but very difficult when there's a misalignment. So those misalignments, I think, are the the most difficult things for me. And then you rely on having really good relationships and being able to have difficult conversations with people.

And and with that transparency, those difficult conversations aren't as hard as they would be if you haven't got a good relationship. So, yeah, I mean, all really important points I think you've raised.

Mary Thengvall: So we we've kinda touched on some of the challenges and and but for someone who's coming into or considering developer relations management or even actually for people who are doing the job already and and and would like to just kinda compare notes. What what is the day to day, week to week, quarter to quarter role of managing a DevRel team? You know, what what are the the core areas? So you've you've touched them slightly somewhat, but, like, I if if you could if you're writing a kind of a postcard that was an introduction of, hey. Well, this is what I do.

What what what would you say? What would you include? And that's for anyone.

Michael Jolley: I I think the biggest thing for me, which also negates any sort of normal daily routine, my biggest priority is to unblock my team members. So if there's processes that they're having difficulty with internally, if there's other people that they need to connect with that they aren't able to, if there's approval that they need for experiments or programs or budget or whatever it is, that's that's my highest priority every day. That means some days, I come in thinking that I have no one to unblock and a few things that I'm gonna focus on, whether that's content or strategy or something else entirely, and I'll get five minutes into the day and go, oh, okay. None of those things are gonna happen. I need to focus on unblocking my team.

And there's other days when I think there's gonna be a lot of unblocking that I'm gonna need to do, and it's a couple five minute conversations, and then the rest of the day is open. And I can I can work on other projects? But that's been one of the biggest things for me that's been difficult to adjust is I'm I'm used to the context switching, but I'm not used to the not knowing that I'm going to need to switch context that quickly, if that makes sense.

Matthew Revell: Yeah. So it's it's kind of humans plans are great, but humans are messy. That that's kind of

Michael Jolley: Yes. Yeah. 100%.

Matthew Revell: What what about managing, you know, the I guess, managing up and managing sideways are things that we hear about quite a lot. What what aspects of the role or how much of the role and what does it look like are involved in in those outward movements?

Matthew Revell: I'm very sorry to to kind of hijack that. Sorry. I I I don't actually know. Could you please tell me what, managing up and managing sideways mean?

Matthew Revell: I'm really sorry. So the idea that managing up being dealing with the people on who who are above you in the hierarchy, so reporting up the success or or otherwise of your team, and reporting sorry. Managing sideways being how you interact with other departments, other teams within the organization.

Matthew Revell: Gotcha. Thank you.

Michael Jolley: I think, you know, I'm gonna call out Phil a little bit because I was a citizen of his small country. But, he was really good at being, I think what he would term as a crap umbrella, which kind of shielded the team from all of that stuff that kinda comes downhill. He smiles because he knows he's used that term before. And so I think one of the things that's worked at Deepgram has been kind of, like, mimicking that is to be an umbrella for those sorts of things. But as new people come on to our team and kind of being a gatekeeper as to who gets to interact with them, initially and setting kind of expectations outside of our department on what we are and probably more importantly, what we're not.

You know? Because we have someone who joins the team who is, you know, a Python developer advocate, and then all of a sudden, they're getting Slack DMs like crazy from sales saying, hey. Can we build this demo for this customer? Can we build this? Can we do that?

And, you know, this person's, like, not even gotten their hoodie yet and have got, like, a three month log backlog, you know, of those sorts of things. So kinda gatekeeping that at first until you can trust that person that's up or sideways to understand what you do and what you don't do. And then once you've, like, hit that point with that person, that then you're like, hey. You're free to talk to. You know, you should just ping this person about that and and open that gate for that person.

You just kinda do it in a a staggered way. As people get it, then they have full access. You know, it's training wheels.

Jingle: Yeah. So I I may have used that terminology, and and it it was definitely around man quite often managing change. And I think it was so there's kind of two things. Right? Sometimes change comes, and you can't do anything about it.

So you you you wait for the right time, you get all the information, and then you you have to let the team know, and you have to work with the team to to go through that change. Sometimes it's about pushing back and actually managing and managing sideways. And and then in those situations, you're you're a bit more trying to, you know, in many ways trying to get your own way or even sometimes it comes from you. Right? You're saying, okay.

We wanna do this in this different way. You're managing you're managing sideways. You're trying to encourage your leadership team to do something differently or trying to get the, let's be honest, the the finance or the legal department to let you do something in a slightly more lean way than filling out ginormous documents and pdf sending PDFs around the Internet. So I think those things, those those are big parts of it. And in both of those situations, it depends on the sort of company you're at.

Again, we were at Michael and I were a very big company. I mean, not not massive, but, you know, 3,000 ish people formed at nine different acquisitions. So and and it had legal issues in the past. So we're always very cautious about, you know, various things. But at some companies that are very open, it it can be very different.

You can have much more open, honest conversations. You can just demonstrate how what you're trying to do aligns with company goals, and they'll go, you know what? That makes a lot of sense. Otherwise, it can be a bit more tactical and understand what their goals are and try and align what you're doing with their goals to make it a win for them. But I think, you know, the the best source of companies, it's more about making sure you're demonstrating what you're doing is right for the business, and then people will understand and and work with you.

Michael Jolley: Agreed. There's two different things for me. So my team is global. I've got people in The States, across Europe, and then New Zealand. And so one of the things that I emphasize with my team is is almost the not the reverse, but similar to what, Phil and Michael were talking about, but slightly different.

So with my team, I make sure that they understand, hey. If someone else approaches you, here's the proper places to send them. Here's the form that they should fill out to get our assistance. Here's what we need from them in order to sign up for this project or or be a part of that demo or whatever it is, but then making sure that people throughout the company know those correct channels too. So in our internal handbook, we have a full page of what we call DevRel DRIs, the directly responsible individual.

And so, you know, if you have a question about the meetup program, you go to Maria. If you have a question about BPMN modeler, you go to David. If you have a question about microservices, you go to Nile. Right? And so making sure that people know internally if they take the time to look who the appropriate person is to go for those things.

But then as a team, people have an understanding of, you know, if it takes more than a half day to a day to finish a particular project. Like, if it's a simple quick win thing that you can get done before I'm even gonna be online and it's not gonna push your other priorities, go for it. Right? Quick win, easy to do, makes another team happy. That's great.

If it's something that's more involved and is either going to cause you to reprioritize the work that you have on your plate for this month or quarter, then you and I need to talk about it. Right? I need to know what your reasoning is, why we wanna prioritize that, why that's a a better area to spend our time than what you're currently working on, which we've already decided on at the beginning of that quarter. So for me, part of how I've I've helped manage nine people is empowering my team to be able to say, no. I can't do that right now.

If you have a problem with that, go talk to Mary. Help her understand the business reason, and then you can come back to me, and and we'll figure it out later. So definitely being that umbrella still, but in a slightly different fashion where I'm not then blocking everyone. So if we have someone asking Josh in New Zealand, and then I have to check-in with someone in Germany, and then I have to get back to the person in Australia, we're talking a week's worth of of back and forth with all of the time zones in there. Right?

So trying to keep things moving as much as possible while also protecting my team from work overload.

Jingle: I just wanna call many things out there. It's great that that, Mary, you talk about that skills and responsibilities mapping, and that's fantastic. So I recently joined Ably, and we don't quite have that yet, but it's one of the things we're working on. And then following on from that, once you know who to go to, the processes you should go through to request that time

Michael Jolley: Yeah. Yeah.

Jingle: Would be great that you called those up.

Michael Jolley: Yeah. Well, there's a big part of that that, you know, I I stress hiring people who can work autonomously. Right? I need people who can say, great. This is the project I need to work on.

I can go work on that on my own time. And there's you can do that at any stage in your career. Right? You can be super junior and still be fairly autonomous and go, great. Yes.

I know I need to do these things. Let me go do that. But the flip side of that autonomy is making sure that people are still checking back in and saying, hey. I'm deprioritizing these things and taking this on instead. Does that still make sense based on the goals that we have for the quarter?

Matthew Revell: I love that. Thank you. It's it's I I mean, I hadn't heard the term before for the umbrella, but, that's that's I really like that because I feel like I've been there, not myself managing, but, like, being being managed, having someone there to to to to carefully balance that transparency and, you know, communication as well as making sure that I can focus on what it is that I need to do. So thank you all for that.

Matthew Revell: To me to me, feels like a diplomatic mission. You know? Your your role is to explain DevRel to the foreign culture in which you find yourself and then also to explain that that culture back to DevRel and and to act as the gateway to.

Jingle: Yeah. So so I don't think the umbrella is unique to DevRel. The point you raised there around that lack of understanding still around around developer relations and the the the requirement to continuously share what it is and the value it brings is is unique.

Michael Jolley: Yeah. The one thing that I'll add on there that I just had a conversation about a couple weeks ago internally was that sharing what it is that we're doing, the actual work output, isn't always enough. Because saying, hey. We published x number of blog posts and spoke at this many conferences and organized this many meetups and did these different things. Other people throughout the company might not realize what that connection is.

Right? They might not see that as, hey. Speaking at these events that we haven't been at before is drawing additional awareness to our product or giving these Meetup presentations to our Camunda Meetup groups is helping enable people to use the product even better. Right? And so there's times when you have to be far more explicit and almost feel like you're over communicating, not only here's what we did, but here's the value.

Here's the, the impact back to the business and why these are the things that we're focusing on.

Michael Jolley: Yeah. I think that's even more critical. Like, if your team is more than just, like, I don't know what I would call, like, general advocacy, like, machines. Like, if you're doing experience and education, a lot of times, those updates aren't as loud as the content part because you you announced, you know, I've got this many livestreams. I've got this many YouTube videos, this many blog posts, and people can go look at that.

But if you say, you know, we reduced issues on our Node SDK by this amount or we added this thing or we've added here's we've added code coverage to our our Python SDK. It's completely tested. No one can see no one really even kind of cares, to go look and find that out. They just you know, it's foreign language to them. What's code coverage?

You know? What's Python? That sounds dangerous. So there there's there you've gotta amplify, but find a way to, like, super amplify those things that aren't just, like, you know, things that they can see and touch and play with.

Matthew Revell: You gotta do the homework for the people that you want to impress, essentially. It's

Matthew Revell: would it be fair to say that you're sort of trying to add that tangible nature to these things so that they can be more apparent to, report to people you report to?

Michael Jolley: I think so. A 100%. I mean, what what does it mean to our, you know, VP of sales that our Python SDK has code coverage. What, you know, what does it mean to those same people that that that code snippets on our blog are now interactive and inject API keys? You know, those things really matter as far as experience go, but most of those people don't even know really kinda what a code snippet is.

Why would I be looking at it? Is it you know, can I catch it? Is there a cream for that? I you know, there's a lot of explanation you had to do in there to say, what is this, first of all? Why is what we did important, and how does it benefit you?

Michael Jolley: I think it's that how does it

Jingle: Sorry, Mary.

Michael Jolley: I was just gonna say, think it's that how does that benefit you piece that's especially important. I had a high school teacher who used to say, so what? Who cares? Right? Like, great.

We published this many blog posts. We made that update to the website. We have code coverage. Why does the VP of sales care? Why is it relevant to them specifically?

Why does marketing care? Why should they care? Right? Because they might not even know that they need to until you take the time to translate that into something that they're going to understand and understand the value of and the impact of on their own work.

Jingle: Yeah. So I was gonna say in these situations, you almost want to be a problem in the first place. Right? You know, we keep getting support queries around the Python Well, we've just done this thing, which means we've got full test coverage, and we won't see those support queries coming in yet. All that customer that's complaining about won't have to complain about it anymore.

So instead, you need to I mean, some of these things are very difficult to measure. Right? You you a lot of those are probably around activation or around support queries or but then actually mapping that piece of work code coverage through to increased activation through customers that then use the Python SDK. I don't know what state of instrumentation your business is at, and maybe you can do that. But but from experience, many businesses aren't well instrumented enough to be able to do that level of mapping.

So I think in in some cases, there needs to be a level of trust as well that you'll be managing to establish to say we're prioritizing these things, prioritizing these things for these reasons so we don't see these problems in the future. And therefore, these are the benefits you'll get from that.

Matthew Revell: I like that. It's kind of a reframing. That's that's really that's really cool. Thank you. And and and I'm getting some really great advice from you all.

So I I'd love to I'd love to ask, you know, for somebody looking into getting into managing a developer relations team, what what advice did you wish you could give yourself in the past before becoming one, a a DevRel manager for anybody?

Michael Jolley: I can go first. No one else is jumping in. I think the biggest thing for me, there's an article that came out couple months ago now, I guess, called energy management for newer managers on the accidentally encode blog. And it's this idea of we focus so much as individual contributors, team members, on time management. Right?

Do I have the time to do that project? Have I set enough time aside to do these things? Am I managing my time properly? And as a manager, that time management is absolutely still a thing, but the energy management is bigger. And it goes back to what Phil was saying earlier about one of the more difficult parts of being a manager, right, is the people.

Right? There's times when I'll step into a one on one where I think it's gonna be a super easy one on one, and suddenly, the person that I'm talking to has had a really rough week and needs to vent. And there's problems that I need to solve, or sometimes I just need to be a listening ear, but there's times when that can drain you of energy. And so learning to manage that energy and plan for those times as much as you can is really important. So I space out my one on ones.

Right? I have that time in between them, so I don't have them immediately back to back. And even if it's just fifteen minutes in between, I can step away from my computer and get some fresh air and get some water and kind of reset. And I think that would have been incredibly helpful for me to know earlier because it's something that I'm still learning now several years later.

Michael Jolley: Yeah. I just written that down because my my one on ones are back to back, and suddenly, I'm thinking, need some fresh air. You know, one of the things I I don't maybe it happens, but I think normally, you don't come in to management in DevRel without actually having done DevRel. And a lot of times in doing it, sometimes you can get kinda passionate about what you're doing. Like, if if you love writing, you love writing, and you just you know, you're doing that stuff, and maybe you enjoy creating courses.

And maybe you're one of those who who love doing YouTube videos, and it's just like, you know, you're at least you're living that YouTube life and or Twitch or whatever. And I think one of the things that, I wish I would've maybe recognized, maybe somebody should've told me maybe Phil should've told me about this, is that you know you're not you're you're moving from, like, individual contributor into management, but you almost need to realize, like, if as as your team grows, you are gonna be doing very little individual contribution. And and it's gonna be a struggle to do that, you know, to to do any at some point. So if that's not, you know, in your mind initially, you know, it can be kind of a shock. You know?

Because if you're really passionate about creating YouTube videos and you realize, hey. Look. I'm now gonna have maybe 10% of my time that I could do that with, or it is more than likely gonna be off hours time. You have to really assess. You know?

Is that what I want? Do I enjoy this enough just to stay in an IC role and and and and do the things I love? You know? That would have been handy to know. Thanks a lot, Phil.

Jingle: I mean, this is not surprising here when you say that. I mean, not they're not blaming me as such, but I mean, because you were, you know, an amazing individual contributor. So and you well, we often see that, don't we? We often see amazing individual contributors be rewarded or feel like they need to move into management because it's the only direction to progress. Certainly not saying that was the case for you, Michael, but then when people do that, there's that balance, and it's really, really difficult.

And I've I've gone through that a lot. And one of the reasons I left Vonage was to go back to be an IC for a bit as well and worked out I was just okay at it. Reminding myself that, you know, as a as a developer advocate, I was generally alright across the board and and definitely missed the people management side of it and and the leadership and strategy and and things like that. So, yeah, I mean, the the things that I kind of thought about with it with this question were again back to the was again back to the people side of things. Although I've managed software engineering teams, I hadn't managed the the DevRel team before.

And, also, I was never given any a lot of official people management training. Vonage is very fortunate that there was there was management training, there was leadership training, there was strategy training. I got I actually had a coach as well, a leadership coach, someone called Stan Beecham, who who was awesome. So, like, super fortunate. But I think going into that at the start of the four years four and a half years of growth, if I'd had more people management training rather than learning on the job or relying on, I hope, my natural empathy for people for because I've done the role before trying to under because I I felt like I could understand the roles that people are in as well so I could help them directly.

I was as I said, I I was work I was learning on the job, whereas I think putting time aside to maybe do more training focus. It's funny. You know, I created a DevRel strategy yet. I can't say I've got a specific strategy around people management other than I try and be honest and open and think about, you know, them first and their career almost outside of the job. So, you know, whether they're where I whether they continue to work where we work together doesn't really matter.

It's more about mean, obviously, that's preferable, but it's more about their career and their progression and planning that with the business. I don't know whether that's the right thing to do. I've read people leadership books and things, and I a lot of the time, I'm nodding my head, but I still can't say, well, I definitely follow these principles when I when I manage and when I go into a one on one, do I have it really planned out? No. So I so training around people management would have been really beneficial.

Matthew Revell: Something that came up just now was the idea that individual contributors who are really great end up becoming managers and then don't contribute individually. What are the options for people, do we think, who should have career progression but don't want to be managers?

Michael Jolley: I can start things off there because it's something that I'm very passionate about. I feel very strongly that people should have career options other than going into management. The last time that I was hiring for a middle manager, I the first question that I always asked is, why do you wanna be a manager? And if someone's response was, well, it's the next logical step for me, career wise, it was almost always an automatic no because you you have to have that passion for people and guiding and coaching and helping people in order to be a good manager. But I think so often people don't see opportunities for growth beyond, well, I'm an IC, I have to be a manager, and that's just the way that things go.

It's something that I'm really proud of the fact that we have at Camundo. We have a, what are what we call our job grades. You can see there's an individual contributor path and a manager path. And up through, I wanna say it's senior director, might even be VP. There's an equivalent individual contributor role.

Losing my words here. So that it's very clear that, you know, the the salary ranges, the compensation ranges, things like that are equal because not everyone is meant for management, and that's okay. Not everyone's meant to be an IC, and that's okay. But figuring out where you best fit and and what the best route is for you and where you can contribute the most value shouldn't be dictated by, do I have a way to get a promotion, earn more money, continue to lead, or be involved in the projects that I wanna be involved in?

Phil Leggetter: I think I've seen some of that, Mary, as well. And because you've put some out publicly, haven't you, the these role definitions. And then do you see that the so so at Vonage, they had the same thing. And, again, you could progress in an IC role, an individual contributor role to a to a very high level. Yet people still felt there was a ceiling on that, and I think it was because from a team perspective, it was sometimes difficult to justify what it to say if someone moves in that IC, you know, to upwards in those IC roles, what they would be doing.

And I don't know whether I mean, there were defined criteria for that as well, but we we often struggle to justify putting creating that role for the business. Have you seen differently? Have you seen, okay. We can clearly justify having an IC roll up to this level so that there has been correct progression?

Michael Jolley: So I think the one thing where things start to get a little interesting is, say, you have five developer advocates. Random number because that's how many I have. If four of them are senior and one of them is principal, things are likely a little lopsided. Right? So making sure that as a manager, you've got a good distribution of experience, I think, is necessary because I'm not necessarily gonna be looking for everyone to be a principal developer advocate because part of what I expect a principal developer advocate to do is to mentor the less experienced people on the team.

So if everyone is upper senior or principal, who do they mentor? Who do they help out? Who do they, you know, help to progress their careers? And so I think I can see the case for, you know, if everyone on the team is more senior, there's likely going to be a cap at some point where you have to say, look. It re you're you're at that point where I could definitely promote you.

I could make a case to promote you into this role. However, it doesn't make sense for us to add another senior or principal or whatever your upper level titles are. Instead, can I help you find a good fit at another company? Or what can I do to help you take on additional leadership or whatever it is that they're looking to do? And back to your point earlier of, you know, it's it's my job as a manager to make sure that that person is successful.

If that's at Camunda, fantastic. I want them to stay here. If it makes more sense for them to eventually move on to somewhere else, I need to be okay with that and continue to support them in that way. And that happens with happens with management tracks as well. Right?

If someone comes to me and says, hey. My career goal is to become the director of developer relations at Kabunda, that that's my title right now, which means they wanna take on my job, which is fine, but I don't plan on going anywhere anytime soon, which makes things a little awkward if they're if that's their goal is to do this job at this company. Right? So then it's my responsibility to go, great. How can I guide you and direct you in a way that helps you to continue providing value here, but also highlights your capabilities in a way that other companies are starting to see that, and you have opportunities coming from outside of Camunda as well?

Matthew Revell: One thing that is perhaps so a lot of the things we discussed not all of it, but some of the things we've discussed could apply to managing other types of team. But DevRel roles are unusually visible and public, And we've actually got to talk about this tomorrow, harm reduction for DevRel teams. But I wonder what is it that you do in your teams to, well, to protect people from being a a public figure, essentially.

Jingle: Nobody wants to answer this, I don't think. No. It is it is a big thought and a and a consideration. I think a business has a code of conduct, and that code of conduct should obviously be utilized within the business, but also outside of the business. And think that should provide a a guiding light to that.

I mean, the what what was the name of the talk yes tomorrow?

Matthew Revell: Harm reduction for DevRel teams.

Jingle: Yeah. Harm reduction. So that's very kind of preventative, isn't it, and defensive, that sounds almost. So, I mean, we have, you know, guidance and and we've worked with teams around guidance of how to conduct yourself and things to consider and and also, to some extent, monitoring and per and quickly providing guidance if if people step outside of how we feel they should behave or or they haven't considered how things should be taken. And I'm trying to think I I often wish I had access to the to the wiki that we had at Vonage because I didn't kinda download it all before we left.

Because there was a lot of stuff on that that's really valuable that I, you know, haven't taken with me. So at the moment, I believe, I'll be honest, I don't know if we've got anything around that, but it obviously is very valuable. So I'll be listening in tomorrow.

Michael Jolley: I'll admit part of the reason I was hesitant to speak up is because for me, it's not just my team is more visible, but also for any women in tech, it's always something that we have in mind. Right? It's always something we're keeping an eye out for. It's always something that there was a thread on Twitter just last week of, hey. I'm starting to travel a little bit more, and this is my first time traveling, and it's post COVID.

And what are the things I need to keep in mind? So at Camundo, we have our code of conduct, our community code of conduct, which extends to employees, but anyone who's engaging with us online and customers as well. So there's things in place. We have a whistleblower app that we use internally so that if you see someone acting inappropriately online or in person or whatever it is, you can fill out the form. Our legal team gets alerted to that.

Our HR team gets alerted to that. So there's there's things that we have set up in place for dealing with our specific community and customers and the people that we are are around on a day to day basis. As far as my team and making sure that they have the resources that they need, the thing that I do first and foremost is how much they travel, where they travel, whether they do things in person or online is up to them. Right? I'm never gonna go to my team and say, everybody on this team has to be at x number of events per year and traveling this much, and this percentage of your work is travel and speaking at conferences and everything else.

And I will caveat that with saying that that's a huge advantage of having a bigger team is I don't need to say everyone's on the road at all times. But for whatever reason, whether it's COVID related, whether it's having young kids and a family at home, whether it's I don't feel comfortable traveling and and being at a conference by myself for whatever reason. If someone says, nope. I don't wanna go. That's fine.

And that said, they don't need to say anything more. We'll we'll figure something out. And so every conference that we sponsor, any speaking opportunities, anything like that is all people speaking up and volunteering themselves. And I'm lucky enough to not have had an issue where we don't have people signing up and and willing and interested to be at those events. So

Michael Jolley: Yeah. We do the same. And I think, you know, code of conducts, that stuff's vitally important, but that kinda addresses, like, how we interact with each other, how we interact with others, and and how people interact with us in our spaces. But there's also, like and I think of it in terms of, like, Mary, the the the women on our team, the, you know, even the underrepresented groups on our team. You know, there's a point where you say you can't say, well, you know, I think about, like, my teenage daughters.

I'm like, it it's easy as a dad to say, well, you just can't have a cell phone. Then I don't have to worry about any problems. You know? But that's not realistic. It's easy for me to say, well, you should just turn off your Twitter DMs.

Don't ever announce where you're gonna be so nobody can you know? But that's not you know, you're you realize you're restricting that person because of the actions of others. So I think some of those things that are out of our control, it's just super, super important to have discussions up front with your team saying, listen. I've got your back. You know?

Here are some resources about how to protect yourself in these different online or or physical locations. But then, you know, if you get somebody coming at you, inappropriately on Twitter or whatever, bring it to us. You know, we've got your back. We'll we'll we'll report the heck out of it. We'll do whatever we can to, you know, make sure that person's not welcome in our spaces as if it was a community space that we control.

You know? And it's

Matthew Revell: Is it also unfortunately. Sorry.

Michael Jolley: No. Was like, unfortunately, it's something you have to deal with. I mean, it's it's ridiculous, but also necessary.

Matthew Revell: Is it also a very kind of practical matter of budget, for example, if we're talking about travel? So earlier in my DevRel career, I'd stayed in some pretty sketchy places because that was what the nightly rate would allow. There was no getting a taxi if it was 01:00 in the morning from landing at the airport to the hotel. You would have to get the frankly unsafe bus that would you know, and all that sort of thing. And I think, you know, if we're asking people to travel and take time out of their lives, then, you know, we we we kinda joke about how, you know, dev dev role people spend a lot of time talking about airport lounges.

But, actually, if we're asking people to make these sacrifices, then that should be backed up by giving them the bare minimum budget to be safe and not the bare minimum budget to to only just about have a roof over your head or whatever.

Michael Jolley: 100%.

Jingle: And it's

Michael Jolley: And I think it's extremely important to not only say that, but give examples of what that means. I worked at a couple companies in the past where the the first version of the travel guidance information for internal travel was, you know, pretend like it's your own money and spend it responsibly. And as a result, I had a colleague who stayed at a hostel for a conference one night because that's how they would have chosen to spend their own money because that's lodging is not something that they wanted to prioritize and spend more money on. And it happened to be, we found out later, a hostel that was also in a bad part of town. And luckily, someone else on the team had an Airbnb and said, please come stay at the second bedroom in my Airbnb tonight instead because this is not good.

And, also, hey, people team, we need to update our travel guidance because this is not working anymore. But I think that's a it's a very real thing. Right? If we say spend it as if it's your own money, there's a certain amount of privilege associated with that, a certain amount of assumption about people's backgrounds, where they came from, what their financial situation was when they were growing up. And so instead of saying, you know, spend up to your comfort level, we need to say, hey.

Around this amount based on the cities, if it's above that, you know, talk to your manager, talk to the travel team, the people team, whoever it is to get that approval because the priority should be, is the team safe? And if, you know, if you happen to be traveling to, I don't know, San Francisco during the Salesforce conference week, things are gonna be through the roof. So maybe you plan a trip to San Francisco at a different time. Right? But I think there needs to be information shared within reason and then guidelines specific guidelines and examples given to help associate that and help people understand what the actual limitations are.

Jingle: Yeah. And and we're we're talking about this in the context of of of relations, but it isn't obviously, these shouldn't just be general standards. They should be standards across the organization, and and everybody should work to these. So yeah. And and and that's part you know, that in these situations, we've probably been in these where we're probably seeing it because our team's experiencing it or we're experiencing it.

And our job sometimes isn't just to change the policy or the thing for the populations. It's to change the thing for the company, and that's where the managing up comes in.

Michael Jolley: We're the canaries.

Matthew Revell: To yeah. Really appreciate that. Thank you.

Matthew Revell: We we are coming towards the end of our slots, which, again, every time we do one of these, I'm kind of like, hey. Yeah. But I've got so much more. But there is one thing I really want to cover, and that is hiring for DevRel. So up until today, I'm not saying anything's changing, but just, you know, in case things do change in future, hiring for DevRel has been hard.

Partly, that's because the role, you know, with not we, but as an industry, people have tried to find people who don't exist, essentially, trying to cram everything into one role. But still, now, you know, there's there's there are a lot of people who who are perhaps on the junior side who wanna come into DevRel, and then there are a lot of vacancies for senior DevRel people. And so I'm interested to hear how in your teams you've you've been able to to to address that.

Jingle: So, I mean, I'll be quite quick with this one. So I haven't hired in developer relations for about probably two, three years. So I feel I've been very fortunate that there's been a, you know, a massive spike in demand. I mean, I know there's been peaks and troughs, but I think this has probably been the largest spike of demand for people within the populations. So as I said, I've been fortunate that we were I've not had to hire in this climate yet.

But I think, you know, to your point, Matthew, around I I do think there's a responsibility to to to bring people into the populations. There's a lot of people who would like to transition in from various stages of career, from from being junior through to second career developers who want to be want to move into job relations. But the and and one of the observations I've got from time between Vonage and and now is that that requirement for everyone to be senior. This is such a big push with certainly within the startup space around hiring senior, hiring senior, hiring senior. And, yes, okay, if you hire senior, you'll get lots of people who can get stuff done quickly, but you're creating problems for yourself in the future, and then you're pushing up the the cost of hiring.

So people are creating companies are creating problems for themselves. So I can't talk directly to about the hiring experience at the moment. I'll let Mary and Michael do that.

Michael Jolley: For us, it depends on kind of what we're looking for. You know, when you're when you're a small team, you're you need more generalists, which may be a little harder because it's hard to find that person that can help with your doc site that's written maybe in PHP, but also can contribute to a Go SDK. And do they know any Python? Because, you know, we're an AI company, and that just, you know, would be really helpful. But once you get to a little bit bigger size, then you're, like, hiring for roles.

Right? You need somebody that can manage, you know, community, or you need someone who has experience with Go. I got I don't care if you've ever touched PHP. You're gonna be responsible for Go stuff here, content or SDKs or whatever. So I I think it depends on that, but I think Phil's right.

Like, bringing in juniors is super helpful, to kinda nurture. And, I think it's it's gotta be a blend.

Jingle: You know,

Michael Jolley: I think Mary mentioned, like, having, like, the different roles of, like, principals and seniors and juniors. I think it really does have to be that way to a lot of times, the juniors are are still in the let me find what I love phase. And and DevRel as a whole doesn't seem to be super defined, so a lot of people think DevRel is, you know, I'm on the road. I'm I'm traveling. I'm seeing all these cool people and giving talks and getting all kinds of cool T shirts and amazing hoodies.

And, you know, the vast majority of roles aren't that. You know, especially in the past two years. So having those juniors able to kinda develop and find their niche, if you will, or the things they're passionate about, Even if it's you know, I just really like coding, and I really just wanna jump over to engineering now. That's cool too. I feel like it's just another on on ramp for people in tech.

Michael Jolley: Completely agreed. And I think just like DevRel can be an on ramp for people to go find other things that they're passionate about, finding people who maybe aren't quite finding their fit in other departments and are well suited for you is a great way to kind of help with that issue of being able to hire people. I can definitely attest to the fact that hiring right now, there are more roles available than I have ever seen before, and it's been growing steadily for the past probably year, year and a half. For Deborah Weekly, the newsletter that I do, we do a we keep a running list of all of the open jobs. And I recently told the gal who helps me curate those, let's only keep things if, a, we're sure that the role is still open, the website is still up, and, b, if they've been posted sometime within the last six months.

And there's over 700 roles posted there. I just checked. So there's a lot of people hiring, but three of the members of my team came from our training division, from our consultants. And so figuring out, you know, where else within your company can you pull from. Are there people in sales who are technical and love the people aspect of sales, but don't necessarily like the, you know, getting the deal signed part of things?

Maybe they're a good fit for DevRel. Is there someone in marketing who really enjoys the deep dive technical side of things from product marketing maybe. Pull them into DevRel. Right? Figure out where those people are throughout your company wherever you can.

And then if you are looking to hire, my biggest recommendation is be as specific with your job description as you possibly can, so that, ideally, people can weed themselves out early on. But, also, it's an easier opportunity for you to, ask specific questions during the interview process to make sure that that person's gonna be the right fit for your team depending on what goals you're trying to accomplish.

Michael Jolley: I think that's really good. We've got a we actually got a a person right now who's in our engineering team who wrote his first blog post for us for for our developer blog. Right? And he loves look. We do speech to text.

We're speech to text API, and he loves writing games. And he wrote a game and incorporated that so you control the game with your voice. He thought that was super cool. We agreed and said, should write something about that. He did and just loved the process.

And since then, he's written, like, three more pieces. And we're like, you know, you should you you're really good at what we do. And his feedback to me was, you know, I really love the deaf part of it, but I'm afraid of the rail part of it. And but but then we we were talking, like, a week later, and he found some third party site that somebody's built. I forget what it is.

It's some game online or I don't know what it was. But the the service used some other speech to text API. And he reached out, and their community discord was like, hey. You know, we have this product. Blah blah blah.

Let's talk. You know what? Turns out the the the owner of that code and that community is rerouting the system to use our API. And we're like, you realize you just railed the heck out of that dev. I mean That's old school hustle.

Jingle: That's old

Michael Jolley: school. I'm I'm like, you you you say you're afraid of it, but you're doing exactly what we're talking about. It's just being genuine. Hey. Let me show you something.

And then, hey. Let me help you get it going and, you know, all that kind of stuff. So so, certainly, we're keeping our eye on that one to maybe Absolutely. Shuffle over.

Michael Jolley: Right.

Michael Jolley: But you know what? I don't think it's just a problem with DevRel and the hiring because engineering is just as hot and if not more so difficult to find people to plug in.

Michael Jolley: Yeah. Yeah. And I'll say too, even if you don't get someone onto your team full time, even if that engineer doesn't decide to move into developer relations full time, Finding those people within the company that you can continue to mentor and coach, whether it's speaking at conferences, writing blog posts, doing videos, even if they aren't the ones creating the content at the end of the day, it could be that you hop on a forty five minute phone call with someone and record it, and they walk you through what they've done, and you go straight to blog post for them. But anything that you can do to scale the output of your team by using people on other teams, finding resources that they're using, can be helpful, and that also helps you build more relationships with other teams going back to what we're talking about earlier with managing out and not just up.

Matthew Revell: Great. Thank you. Well, we're we're most certainly at time. We're over time, but it's been such a good conversation. Just any last thoughts or anything you wanna share about where people can find things that you've been working on?

Mary Thengvall: I I'm hesitating only because I don't have any recent resources, but I do have some resources up at marythangball.com or marygrace.community if you don't wanna try and figure out how to spell Thangvall.

Matthew Revell: Michael?

Michael Jolley: Everything I've got is on baldbeardedbuilder.com. That's really long. Bbb.dev, a lot easier. And, you know, I just gotta say, when when I was in when I was, like, brought into this, I thought this must be a talk about impostor syndrome because getting the chance to hang out with with Mary who literally wrote the book and Phil who I would say is like the granddad of DevRel in a way. You know?

Not that I'm calling you old in any way, Phil. You know, a very young granddad.

Jingle: Thanks. Thanks.

Michael Jolley: You know? I thought, well, great. I'll be I'll be primed to talk about impostor syndrome today, but it's been a pleasure. So great to hang out with everybody.

Jingle: Well, I mean, since I'm so old, I'm just I'm just happy to get followers on Twitter. So if people wanna follow me on Twitter, well, I get to you know? That that good it's good enough for me. No no offense to take on Michael at all. Although, look at the gray.

Look at the gray. I'm not

Michael Jolley: Also, if you're really nice to him, you'll make his top eight on Myspace.

Michael Jolley: New goals.

Jingle: New goals.

Matthew Revell: That's great. Well, thank you so much.