Made by
Made by
Director of DevRel and Head of DevRel
Snyk
DevRelCon London 2023
In this talk from DevRelCon London 2023, Randall Degges and Matt Jarvis from Snyk share how they’ve built process to increase the resiliency into their DevRel team.
They share insights on measuring impact, being realistic in goal-setting, scaling key programs, and automating tasks to increase efficiency. Their strategies and experiences provide valuable guidance for DevRel professionals looking to navigate uncertain economic times and drive success in their organisations.
Jon Gottfried:
I would love to introduce your final speakers of the day. We have a fantastic duo here from Snyk. I’m a huge fan of their tool. I’m a huge fan of their DevRel team, and Randall is a really nice guy. Personally, I just met Matt. He seems really nice as well, but they’re going to be talking about building resiliency into your DevRel team. So please give a final standing ovation for the day to Randall and Matt from Snyk.
Randall Degges:
Alright. So quick question because our whole talk is a pretty common theme that everyone’s sort of thinking about today about building DevRel and doing DevRel in a potential recession, maybe not formally a recession, but on the DL kind of a recession, right? So question, how many of you feel a little bit uncertain about your job at the moment? Maybe throw your hands up in the air. Don’t be afraid. It’s fine. Everyone is. And then secondly, how many of you know someone who’s been impacted either with layoffs, hands up for layoffs, a lot of layoffs, or what about budget cuts? Hands up if you budget got slashed. Yep, yep. It’s pretty normal. And so I think it’s a really good time to talk about this stuff. Some of the other speakers today address bits and pieces of what Matt and I are going to be talking about, but we’re really going to go in depth about specifically what we do. I think we do a really good job of this at Snyk and we’re going to give you the exact playbook we use. Matt, take it away.
Matt Jarvis:
Quick introduction. I’m Matt. I’m one of the directors of DevRel at Snyk. I do a whole bunch of other community related stuff in the open source and cloud native world, and I’ll let my glamorous assistant introduce himself.
Randall Degges:
Yeah, I’m Randall. I lead the DevRel and Community Group at Snyk. Let me get that clicker actually.
Matt Jarvis:
Yeah, it’s your bit.
Randall Degges:
See, we haven’t had a chance to rehearse with the clicker, so one moment. Yeah, so I do a lot of Python, JavaScript and Go Development. I’ve been doing open source for about 25 years. I do a lot of building. So previous to getting into DevRel, I was a founder and CTO for many years and really enjoyed building companies and selling them and stuff. And I also do a lot of writing. So that’s sort of my background. So no surprise, but the tech economy kind of sort of sucks right now, as we all know. Now, the reason I want to mention this before getting into the interesting parts of the talk is because first of all it’s in the news all the time, but second of all, without a good financial understanding of where things are at, it’s sometimes easy to forget the basics because at the end of the day, all of us work at companies, those companies make money, and that money is what pays for all the things that we do.
And so it’s important to understand this stuff. So why is technology not doing super great at the moment? Well, there’s a lot of macroeconomic conditions that are influencing this, but one of the things you have to fundamentally understand is that technical companies over the last 15, they’ve been really highly valued. So investors basically treat investments in technical companies with a lot more promise than they do with traditional non-technical businesses. The reason why isn’t that hard to understand. It’s because tech companies generally have lower fixed costs. If you’re building Instagram, the costs you have for running the business are servers and employees. If you’re building Target or Home Depot or a big retail company, you have lots of expenses, lots of building and rents and lots of inventory to pay for. And so it’s a very expensive company. Additionally, technical companies can dramatically scale their business and everyone knows this.
So if you’re Instagram and you have eight employees and you have a billion dollar valuation and you have literally billions of users, that’s something that you can’t really accomplish in any other type of industry. And then finally, tech companies tend to have higher margins in the long run. So because of all these factors, this means that tech companies spend a lot of money and that’s why you’ve heard over the last 15 years about people saying, ah, these tech businesses are super overvalued. People are investing way too much money in them. They have these crazy high price to earnings ratios. The reason why is because tech companies know that their goal isn’t a short-term goal. It’s a long-term goal. These companies that are bleeding and spending through hundreds of millions of dollars of venture capital and there’s different types of debt of course, but that’s just one of them.
But they know that if they can grow to a certain size and win the market that they will hit all of these big ambitious revenue goals in the future. And that’s why tech companies in particular usually have a lot less cashflow, if any, and a lot more debt than other businesses. And by debt, again, I mean either venture capital that a company raised a startup, or it could be a publicly traded company that is selling shares of their business to shareholders, that’s another form of debt. Or it could be just privately held companies that are funding things themselves. Now because interest rates around the world are rising in the us, if I go to buy a house today, I’d have to get a 30 year mortgage and pay seven or 8% interest. A year ago, that number was like two and a half percent. And so the difference in how much it costs to borrow money has gone up.
And so as a result of that, a lot of companies and particularly companies that need debt to operate, a lot of these big tech businesses have been doing things like laying people off, cutting budgets, et cetera, so they don’t need to borrow additional money or raise additional money at these unfavorable interest rates. Then finally, in any sort of uncertain economic time, investors are going to reduce their risky investments and they’re going to put things into safer options because you can get higher yield from safe things that aren’t risky. You have government bonds, you have more conservative retailers, et cetera. So this is just the state of finance. Now, the part of this that everyone gets scared about is this bit here, the layoffs and budget cuts because that’s the thing that’s most impactful to each individual person. But before we continue on, I just want to highlight, it’s normal.
What’s happening right now, if you’re in a company for a long time, you’re going to go through cycles. You’re going to have really good times. So the company’s doing well and hopefully that aligns with good economic conditions and there’s going to be bad economic conditions times when the company doesn’t do well. It’s very rare for things to always be on an upward trajectory. And so change is hard, but it’s really critical and important. So you have to sort of be used to being resilient. It’s like a core skill in any field, particularly DevRel. So how are DevRel teams and individuals being impacted right now? Well, if you take a look on Google, either trends or search or whatever, you’ll see there’s quite a lot of people talking about DevRel layoffs recently. And due to the show of hands we saw earlier, everyone knows someone who’s been impacted.
It’s pretty common. So why is this happening? First of all, companies have limited budgets to work with and sometimes they have to prioritize other areas of the company for spending. It’s just the reality, right? If your company is not doing well, you’re bleeding money and you only have enough money to make payroll for the end of the year, are you going to prioritize sales to potentially bring in more revenue? Are you going to prioritize r and d to building products? Are you going to prioritize DevRel to help improve experience and market cap? Sometimes companies make different decisions and it is what it’s secondly, a lot of DevRel employees are very senior engineers and they have a lot of other valuable skill sets. And we’ll talk about this in a moment. And in a lot of companies that means that your dev employees are very expensive.
And so sometimes when companies are taking a look at payroll and trying to figure out where they can cut back, DevRel can be a really tempting target for that just because you have very experienced senior employees who get paid disproportionately a lot of money. And then finally, the thing that I’ve heard for years at every DevRelCon I’ve ever seen, but company leadership doesn’t see sufficient R O I for DevRel, and this is a common thing everyone knows about it, it’s no surprise. So just as a fun example, one of the things I did before coming here to DevRelCon is I went through the DevRelCon website and I went back to 2015 at the first ones they did in San Francisco and New York in London, sorry. And I went through and I wrote a little ChatGPT prompt, and I said, Hey, please take a look at the titles of talks from DevRelCon.
Tell me how many of these talks are focused on how to show KPIs and prove value to your organization. And the results are pretty big. Devcon 2019 had 78% of the talks talking about metrics and KPIs of some sort, which really goes to show you that in the meta of DevRel, all of us generally know and understand that this is an issue. Everybody talks about it. It’s like the number one thing DevRel professionals communicate about. So how do we change this? One of the things Matt and I have done at Snyk that I’m extremely proud of is we built a super resilient DevRel team. And that’s what we’re going to go through for the rest of the talk. We’re going to show you exactly what we do to have a team that’s thrived really well in super good economic conditions and is also done really well, even right now when there’s a downturn.
And also just a shout out, but we’re hiring a head of security relations. Our team is growing. So talk to me after if that’s interesting to you. So the first item we want to talk about is impact. Everyone talks about impact, but there’s two things you need to know as a leader of any team at any organization. The first thing is what outputs you’re going to generate from your team. Now, on a DevRel team, this might be things like the number of blog posts you create, YouTube videos, you publish, speaking engagements, you do technical workshops that you teach. Whatever it is, those are outputs. The second thing you have control over in that you need to understand are your impacts. Now, these are things that are measurable, things that matter to the business, right? So for example, the more blog posts you publish, if you’re doing a decent job anyways, the more readers you’ll have on the blog.
That’s an impact, and that will also influence the number of users who read the blog, who then sign up and use your service registrations. So these are things that are the impacts and it’s critical to know in DevRel, particularly in DevRel, what both your outputs and impacts are. You have to have a little table that looks like this to understand because these are the only levers you have to pull to change things. And it’s really important to know what inputs yield, what outputs. So this is a typical developer advocate. Now, I was hesitant to put this slide in here because our advocates are maybe slightly different than some other places. Everyone does it differently, but I’m going to tell you the way the Snyk team is composed. So all of our developer advocates are people who are extremely senior engineers. Matt’s a great example of this. He’s a very well-respected engineer. He has a ton of experience in our domain. He’s also really influential. He’s known in his space, people respect, respect him, and he can act as a trusted advisor to other developers. He’s a really good communicator. So one of the things about advocates that’s really important is they’re good at communicating their ideas through writing, through speaking through,
Matt Jarvis:
You’re making me blush now Randall
Randall Degges:
Through doing videos and all. So he’s extremely humble. I’m talking him up, but it’s very true. The other thing a good advocate needs is they have to be creative and a bit of a hacker. And I mean that in the true conscious of a hacker type person. They need to be the type of person who’s able to just get shit done. They need to build stuff, find creative solutions and work across multiple teams, sometimes in a bureaucracy or whatever it is, just like make things happen. That’s like a skillset that you develop. And then finally, you have to be empathetic to the core audience. And in DevRel, you can cheat at this because if you’re a developer advocate and you’re talking to other developers and showing them how to do stuff and being an educator, you’re already the target user for the service. So what’s going on better than almost anyone else on planet earth and maybe even outside of planet Earth?
So there’s a lot of great things you can do there. Now, flexibility is the main superpower of DevRel because these people have a lot of these broad skill sets that we can easily change and tweak those program outputs that we’re generating and therefore tweak the impacts that we’re generating because we have a lot of flexibility in the types of activities we can do because we have all these skills. So here are some regular goals. This is what goals look like for companies in good economic times. All right? A CEO and the C-suite of a company will look at things like this and say, Hey, we are really focused on revenue growth, getting new users to buy our product. We are looking at market expansion. So are we building new services and launching them to reach new potential customers? How are we maximizing profits?
Are we investing enough in r and d so we can keep ahead of competitors? We need to acquire the best talent and retain them, and then we have capital expenditures that you can’t avoid. Now here’s what goals look like from a C-suite level perspective when you’re in a downturn instead of those focus areas, before companies are focused on reducing costs, driving efficiency, cashflow management, retaining the existing customers you have is very important. Debt management, employee wellbeing, and also of course, improving your products so that the things that are annoying to people don’t become blockers in sensitive times when people are looking to cut budgets. So here’s a real world study from Snyk. Last year in the good times, I’ll say we were really focused on these three goals, revenue growth, market expansion, and profit, sorry, and r and d. We spent a ton of money on these three items. This year we’re actually spending a lot of money on cost reduction, efficiency, customer retention, and helping product improve those pain points that lead to poor satisfaction scores. So now I’m going to pass over to Matt.
Matt Jarvis:
Now you’ve taken the entire slot. There’s a lot of words in that, but so the first thing I’m going to talk about is this thing about being realistic. And one of the big things that we’ve both noticed is that developer relations folks can sometimes put together unrealistic plans for what output is possible. And this is probably driven by a lot of different things, not least of which is that most of the DevRel folks that we know are all super high performers who want to, they’re really keen to show their value all the time, but overcommitting has a bunch of dangers to it, underdelivering for a start, but also in driving burnout, which we all know is a massive issue. So in our team, what we’d much rather do is over-deliver than under-deliver and focus on producing high quality output that really moves the needle. And so we approach this in much the same way as you’d approach any kind of program management by sizing activity and knowing all the time how much effort we have available.
So to do this, we kind of built this resource model for all of the things that our advocates do, and we try and take into account the kind of full range of activity that’s involved in actually producing something. So writing a blog doesn’t take a day, even though the actual writing activity may take that much time. In reality, there’s a whole bunch of research time. You need to think about it, you need to think about the structure. Perhaps you need to learn some tools, perhaps you need to build a demo. And then once you write it, there’s time involved in editing it. There’s time involved in administration in terms of managing your publishing tools. And then most importantly, you need to promote it, which is super important and we’ll come back to a little bit later. But all these activities in our model combined to produce nearly five working days of effort.
And for some activities, there’s some benchmarks you can use already. This is the example of writing a conference talk. There’s this rule of thumb benchmark, which is pretty widely accepted in public speaking, that it takes 45 minutes per minute and then we add in a couple of days for building the slide deck and practice. But the point of this isn’t that it needs to be super accurate either, right? Obviously some things won’t take us long, some will take longer. What we are looking for is a reasonable average that we can use when we do planning.
And once we have the full model of all the activities, we then also look at how much time an advocate realistically has in a week. At any size of organization, there’s going to be a bunch of overhead in terms of meetings, emails, social media, engaging with upstream communities, there’s engaging with the product teams. So we can sort of derive this factor, which defines actual resource that’s available to us. In our case, for an advocate, that’s typically about one day a week of this overhead, which really gives us four days per week. Average month is about five weeks, which gives us 20 days of effort available in each monthly sprint. And when you build these kind of models, you can go off down the rabbit hole here and cover holidays and sick pay and all that. And it’ll also somewhat depend on how much reactive work you have to do in terms of unplanned things. But by using this kind of modeling, we are much more confident that when we do planning, we’re setting realistic attainable goals. And it actually makes us, we are able to respond better to reactive requests because either we know we can’t take more effort in or we can reduce the amount of effort that we’ve already committed to.
Randall Degges:
So for this bit here, you really want to make sure that when you are measuring things, you’re measuring the really important things. So let’s talk about Snyk for a moment. Last year in 2022, we had a vision. It is really, really simple. We want to get every developer in the world to know about and hopefully use Snyk. Pretty broad vision now because of the current conditions at the time, what that translated to in terms of actual impact goals were that we really wanted to drive Snyk awareness, right? So how many net new developers our programs reaching, how many people are learning about Snyk for the first time from a program we ran? Secondly, how many of those people did we acquire? Did we actually get to sign up and use our product? That’s acquisition. So there’s ways to measure this. You can go to Google Analytics and you can see how many people read a particular blog post.
You can see page impressions and net new, but it’s not enough to go a level deeper to get this more in-depth data that you need to run a successful program. You also need to understand how developers just aren’t one group of people. You have Python developers, JavaScript developers, there’s people in different aspects, right? And you need to track and understand that. And on our team, we have different advocates in charge of each of these communities. So in order to get that more granular data, we had to build custom metrics into Google Analytics to report on these things, but that’s also not enough. We then had to tie it into our Kanban system, which is Asana, where we have all of this stuff archived and lots of information. Matt’s going to talk about this a lot more in a moment, but these are the outputs that are yielding some bit of impact.
And I want to give you a high level picture real quick. And the picture is this. Let’s say your company has a sales goal for the quarter. You want to gain a hundred million dollars of a r r. And let’s say that you know that in order to have a hundred million dollars of a r r, your marketing team needs to have $200 million of pipeline because only half of it will convert. So then let’s say how do you get to $200 million of pipeline in the marketing team? And marketing teams have a lot of strategies to get there. They have paid ads, they have content, and a big part of that is DevRel. So at NY for example, DevRel drives about half of that top of the funnel stuff via the programs you run. So that means you’d have a hundred million dollars dev rel pipeline target. Now, how do you reverse your engineer your way to make sure when you’re trying to deliver these big numbers of things that you’re able to accurately get there through the programs you run? That’s what Matt’s going to show in a moment, and it’s extremely, extremely important to do this type of stuff. Also, Jon, quick question. We have five minutes for Q&A, right? Can we skip the Q&A? Alright, no questions. I’m sorry.
Matt Jarvis:
Too many words
Randall Degges:
Ask us after at the party.
Matt Jarvis:
So as Randall was saying, it’s, it’s not just about measuring, but it’s about presenting this information in the right format. And we don’t want to have our advocates having to spend loads of time learning how to use complex tools like Google Analytics and digging around and stuff that find the things that’s important to them. So we build these kind of custom metrics, pipelines, custom metrics, dashboards that are specific to what that advocate needs to see. So this is the one for our Java segment showing performance of blog posts over a particular time period. And that often needs us to link up lots of different data sources for our content program. Asana is our source of truth. Every published piece has a task tracking it. And Asana is where we handle all our tagging, which is basically how we define what we call segments. Our advocates are typically subject matter experts on a particular ecosystem.
So we build dashboards based on the tags for that particular area. And how this works is we have a bunch of Python that runs in Heroku that gets a list of URLs from Asana for a particular set of tags, then uses that to get metrics from Google Analytics. We do loads of slicing and dicing in pandas, and then we’ve produce these custom dashboards and pull ’em, push them to Google Pages. And we don’t just build dashboards for the segment. We build dashboards for absolutely every URL that gets published in the content program. And we also produce a range of automated reports for different things. This is our referrers report. And this comes back to that thing I was saying earlier about promotion of things is super important to us because you’ve put loads of effort into producing content, it’s clearly pretty pointless if nobody actually gets to see it.
We have a really extensive program, what we call go to market for a content piece. This typically means promoting on personal team Twitter, on the corporate social media accounts. We cross post to loads of other different blogging sites like Dev to a Medium. We do HackerNews, Reddit, ecosystem specific newsletters, and Facebook and LinkedIn groups and anywhere else we can basically think of. And by using these referrers reports, we can see not only we obviously seeing where the traffic is coming from for that particular piece, but we can see not only how well we’ve done at promoting it, but how effective that particular route of promotion is. And we just add in this thing in here about Facebook and LinkedIn groups, which a lot of people I think don’t necessarily miss out on the power of some of these groups. They’ve got hundreds and hundreds of thousands of members. If you can get a thoughtfully crafted piece into one of those groups of people who are all interested in that particular ecosystem, you can get a massive amount of visibility.
Randall Degges:
You would be surprised even having a massive Twitter following or X whatever they’re calling it now of a hundred thousand people feels in comparison to just publishing something on the Python developers LinkedIn group where there’s one and a half million people that actively read. There’s no comparison at all. So there’s really effective channels. You just have to go out and find them and do things in the right way.
Matt Jarvis:
So once you’ve identified those activities that have the most impact for your particular team, your particular goals, and you’ve got stuff in place to measure it, you can start to think about how you would really scale that activity. And if you can identify that metric really clearly, link it to business value and then produce a plan showing how you can grow that metric with investment, then it becomes a lot easier to sell that to your organization. But I think you do need to have some of these building blocks in place first before you can kind of make those cases. So as an example, in 2022, as Randall said, our key metric was about driving traffic to the blog. And the big number here is about driving a million sessions by the end of the year. And once we built the metric system and we focused the team around that metric, we can then model how our different types of content, which is what you’ve seen at the top here, typically drive traffic to the blog. And then we look at how many additional sessions we need to drive during that period to get to that 1 million number. And then we can work out, basically model it on how many sessions, additional sessions we need to add per month in order to get to that number by the end of the year. And then basically look at which combination of these things we then use to get that particular number.
Randall Degges:
Just to add one thing real quick, what we’re going through here is essentially our way of having reverse engineered like the growth model of the business and tied it down to very specific DevRel programs. So using all this stuff Matt’s talking about here, we’re able to accurately say that at the start of the year, we have some goal. And because of this stuff we built out, we can then tell, okay, well how many blog posts or videos do we need to publish? And what is the expected amount of people who need to come to these things and learn about it? What is the percentage of people who convert from there? And then what is the percentage of those people who then go on to become paying customers? And there’s a very clearly defined funnel, and we have a lot of consistency in this because of the way we sort of structured it and the resource modeling and everything. It allows us to get these very accurate projections even from a big distance away. And that’s one of the key ways we’ve been able to continue growing the DevRel function even in ad economic conditions, to be frank, because it drives so much of the value of the overall business, it’s quite cool.
Matt Jarvis:
I mean, in this case, we look at these numbers of pieces that we need to publish. Clearly our team is nowhere near big enough to create all those ourselves. So this particular investment case was about investing in content agencies to provide us this very big pipeline of content at a fixed cost. And once you’ve got that fairly simple equation of cost a result, then it’s a lot easier to take that to the executive team and say, for this amount of investment, here’s the result that you’re going to get from that. And that’s what we did for this. And this model basically delivered almost exactly what we planned it to. So I think the point here is if you can get kind of datadriven and provide that easy way of defining that cost to result, that’s what the executive team are in general looking for because that’s how they run the rest of the business.
And this is the graph showing those numbers increasing to the final goal from Q two. These Q one numbers are driven a bit artificially high by various kind of timely things like Log for Shell, which we do take into account of planning that we have some of these things which are unplannable and then we can see in July. That’s our typical monthly output of blogs for in-house for the team. And we grew that by about 400% by the end of the year. And I think this is the one that’s kind of interesting. It shows that power of compounding. So these are the sessions for only blogs which are published as part of that program. So over that half year, getting to that final number.
Randall Degges:
And one of the important things to consider is when you’re doing DevRel work, you have generally two choices of things you can spend time on. There’s things you can spend time on that have a one-time payoff, and there’s significant can spend time on that, have a long-term payoff that compounds over time. The stuff Matt’s showing here is basically we invested a lot of teen time in building compounding things like content where a certain number of people are going to come and learn from it every single month. Things like that grow at a very rapid pace. And it’s easy to misunderstand how much impact it can make without tracking things at a very granular way like we have here. But it contributes massive amounts to the business, and it’s pretty cool to take a look at over the course of a year or so.
Matt Jarvis:
And obviously when you start to industrialize things like this delivering work where there are a lot of stakeholders and a lot of elements, that process gets progressively more complex. Workflows can involve multiple teams, multiple stages. Most folks are going to be using some kind of project management tooling. We use Asana, but even fairly simple things can have a lot of moving parts. So when the way we manage complexity through this is using subtasks in Asana, but these can be across different boards, across different projects, across different teams to get a blog post published. We have something like 20 different steps within our organization. And what we’re aiming for really is to make that super simple for the advocates. We don’t want them to have to remember that they’ve got to create all these subtasks on different people’s boards. It’s very easy for people to get bogged down doing manual work and human ARR gets easily introduced. So the message here really is don’t do donkey work. You look very carefully at where you’re doing repetitive tasks and automate that completely away. And what’s surprising is this can be quite tricky for people to assess. Some folks won’t actually notice that they’re doing loads of manual work or they attach too much value to them actually doing it. So it kind of really helps to have someone on your team who’s sort of ruthlessly focused on assessing what things don’t need to be done by a human being.
Randall Degges:
And I’ll just say Matt’s the absolute best at this in the industry.
Matt Jarvis:
So we use a whole range of different automation tools, custom Python built in Asana rules, but we do a ton of stuff with low-code and no-code in this case, this is our no-code platform make.com. And this is the workflow for one of our workflows for publishing blogs. As you can see, it’s pretty complicated, but it automates away all of that stuff about creating subtasks, moving things onto different boards and all that kind of stuff. The advocates just work in their own sprint board, and then everything from there is triggered in a if this, then that kind of situation, the content team get notified to publish gets added to social media cues and all that kind of stuff. So it basically industrializes the whole process and we’ve built a whole range of tools to handle a lot of other types of repetitive work. The cross-posting that we talked about earlier, this used to be done manually.
Someone used to cut and paste this stuff between different UIs and we now, when you publish like 200 blog posts a year, that’s pretty labor intensive. And we estimated the sunk cost of this as something like 35 days a year of just someone cutting and pasting. So again, we wrote a tool that takes the blog posts from our CMS parses, rich text renders it out to HT m l, adds in all the images, renders that to markdown, and then automatically post to all the downstream blog sites. And we also built this system where folks can automatically retweet things. We did used to have a Slack channel where people could say, could you retweet this? But it’s like it never works really well because people forget to do it or people don’t actually action it. And we kind of made the assumption that actually for stuff we’d published in-house, almost everyone would want to retweet it. So we built this kind of pub sub thing where people create a tweet in an Asana board, it then uses Slack as a sort of messaging system and gets picked up by Zapier and posted to an individual advocate’s buffer account.
And like we try and do with everything, we basically wrap a K P I around this. So some of it’s guesswork, but it’s actually quite a powerful metric. The exec team kind of understand what these numbers are because they’re about hard cash. So we measure this in DevRel days and we can kind of calculate a cost saving based on average developer advocate cost. So here’s that blog reposting one. Save 60 minutes per blog, 170 hours a year equates to 34 days. This modeling is pretty conservative as well. I’d say Randall, right?
Randall Degges:
Yeah, I mean, since we actually built out a dedicated part of our DevRel team that Matt leads, it does operations and automation, and this function has been extremely successful. We’ve saved hundreds of thousands of dollars in yearly spend, and we’ve saved literally hundreds of full-time team member days in basic tasks. So it’s really a massive product multiplier to really treat your program like an engineering problem. There’s things you can engineer away out of your life and you should do that if you can. So it’s a fun reminder.
Matt Jarvis:
And the future for us is probably a lot of stuff that we’ve already started building with OpenAI. So we already do our meetup program. We have something like 50 to 60 meetup groups across the world. They do tons of events every month, and we use OpenAI to automatically generate tweets to promote those events. We’ve also written a whole bunch of stuff to do podcast transcriptions and automatically write blog posts. And we’ve got a system that we’re working on in-house to basically replace content agency pieces with a kind of pair programming thing for the advocates to work with ChatGPT. So I guess that we’ve come to the end. Do you want to recap the takeaways?
Randall Degges:
Yeah, so everything we talked about, nothing super complicated, right? Focus on impact, be flexible. That’s one of the superpowers DevRel teams have. And so take advantage of that, be realistic, measure the really important things that are going to get you to where you need to be in the future. Scale your key programs and please automate stuff. It is so important. Don’t neglect it.
Matt Jarvis:
So thank you very much for listening.
Randall Degges:
Yeah, thanks for the time. We’ll be hanging out the party. So yeah, you can do one or two questions if you want. Oh, okay. We have extra time apparently, so there we go.
Matt Jarvis:
I would’ve gone slower.
Randall Degges:
You can use this one.
Jon Gottfried:
I’ll yell. Oh, there we go. I know this is keeping you from beer and snacks, but we will do a couple of questions here.
Audience member 1:
Thank you very much. Great presentation. How many advocates do you have in your organization?
Randall Degges:
Our team’s about 16 people at the moment.
Audience member 2:
Well, thank you. Great presentation. Top the rootless, automation of it. Anything you have done to apply resilience to the people of your team instead of the processes of your team?
Randall Degges:
So the question is, what automations have we done for people instead of process
Jon Gottfried:
Resilience for people rather than process
Randall Degges:
Resilience? So I’ll just summarize my personal thoughts on this. I think it’s really important. You’re never going to have a very smooth, perfect trajectory in a career or job or a company. It’s a myth that doesn’t exist. Everything’s going to change pretty much all the time. And what you need to do is build enough understanding and context of your business to do the right thing. I think what it really comes down to is each of us in Dorel at a company, we are there at the company to achieve a mission. And usually that mission is to help get more people to know about our product. But in certain situations, it might be different. It might be we need to help get more people to use our product, or we might need to decrease the time it takes for people to use our product. Or maybe the goal is to engage current users of our product and get them to learn more things. There’s a lot of different things that companies want to do. And being flexible as a Dev Rel team and understanding those outputs and those impacts, like we talked about before, is the key piece of understanding that you need to run a program and be resilient. Yeah, hopefully that helps.
Jon Gottfried:
Cool. Well, you can find them downstairs for more questions. Give ’em a huge round of applause for our closing talk.
