From stocks to stacks: economic lessons for DevRel

Swift: Hello DevRelCon! How are y'all doing today? Yeah, pretty good. Pretty good. Let's see if we try that again though. I want a little bit more energy. Hello DevRelCon. How are we doing today? All right, well, we'll see if we can bring up the energy a little bit with this talk. Hey everybody, I'm really excited to be here. I'm Swift. I'm the CEO and Co-founder of a little outfit called Major League Hacking. I've been spending the last 15 years empowering developers to change the world and to change their lives through code, and today I'm here to talk to you about some of the lessons I've learned, helping organisations like the ones that you work for, reach developers in a scalable and authentic way. But I'm also here to talk about another topic that's near and dear to my heart. It's economics and really more specifically finance theory and how that actually can be applied to your DevRel organisations.

Now my goal is to draw some parallels, parallels between things I've observed, well established theories in the finance world, and to show you how you can actually utilise them in your day-to-Day DevRel strategies. Specifically, my hope is to convince you that number one, you need to build a diversified portfolio of DevRel activities or investments in the analogy that I'm going to draw for you and that you should have a clear methodology for deciding what you actually do with the limited time and money that you have, those resources that we use to build that portfolio. Ultimately, I'm going to give you a framework that you can actually fill out yourself to help you maximise the ROI of your DevRel organization's returns or return on investment. To do that, we're going to evaluate three different hypothetical DevRel organisations at different stages in their journey. We'll look at what resources they have to invest the specific ROI that each of them is actually trying to achieve and generate, and the beliefs and strategies that inform what I think each of these organisations based on their stage and constraints should actually be doing.

The first dev organisation we're going to look at is at the startup stage. They're on that search for product market fit. They're looking for early customers that are ultimately going to enable them to establish that they have a real business and to enable them to look at the next stage in their journey. Now that stage is growth. This is an organisation that has a product with traction. They're starting to shift their focus from proving they actually have a business that works to building market share and brand awareness in the industry. They may be thinking about expanding into other customer verticals, but they have a core group of customers that they know they can reach and they know they solve a real material problem for. Finally, we have an organisation that is in maturity. They're focused on preserving the existing market share that they have and to deepening the relationships that they have with their existing customers to ensure that there's lock-in and growth of revenue.

They're really just focused on retention rather than expansion. Now, I just want to note that these do not necessarily mirror to the stage of your company. This is actually really about the stage of your DevRel organisation. There's plenty of huge companies that can spin up new D teams focused on new products or feature sets that can start at the startup stage and be working towards maturity. I would call out AWS is a great example where as they launch new products, they build teams around them that start at the startup phase, finding customers proving the value, and then ultimately they level up into mature DevRel organisations that we know and love and see every single day. So here's a quick preview of the framework that we're actually going to fill out as we go. This is an opinionated framework that I'm going to be telling you from my perspective, working with tonnes of companies about what I think they should be doing, and as we go along, I'll explain the various finance theory and logic behind all of the decisions that I'm making and ideally, you'll actually be able to fill out this same framework for your own organisation and I will share a link to the slides at the end where you can actually follow along with this whole thing from the beginning.

Now, you don't need to be a DevRel manager to utilise this. I want to emphasise that this will work just as well for an individual and a DevRel organisation thinking about their portfolio of activities as well as a manager of a DevRel team who is thinking about the activities of a group of DevRel professionals working on a variety of things. Now, before we actually dive in though, we should take a step back and say, what business do I actually have talking about either DevRel or finance? Well, first of all, I've been building developer communities professionally for about 15 years now. I was the first developer advocate hired at a company called SendGrid where I helped them to build their DeVere programme and ultimately scale that up to about a team of 10 developer relations professionals. While I was there, I actually helped run the only programme that we were actually able to directly tie back to revenue, connecting the dots between evangelism and sales, which is an important milestone to the company.

I also founded a startup previous to Major League Hacking. That was the first platform for hackathons, helping organisations actually organise and run them and connect with developers. And finally I started major league hacking where I've helped nearly 10% of all the software engineers in the United States alone get started in their careers. We've made an impact on significantly more than that as you'll hear later, and if you can't already tell, I self-identifying nerd, especially around developer stuff, but it's not the only thing I loved to nerd out about. Every year I try to set myself a reading goal. I typically read about 50 books a year, and I originally started reading all business books, which I can assure you gets really, really boring after a while. So I started picking themes and I picked three themes each year and I dive into books in one of those themes.

Now, last year I picked presidential biographies, ai, science fiction and finance and monetary policy thinking all of these things would be extremely relevant for 2024. Well, it ends up the first two were in a lot of ways, but the third one was actually really relevant to the types of problems that we solve for our customers at Major League Hacking or MLH. So you've probably heard about MLH. We've been here at this conference saying that over and over again, but you may not know what we do. You may know us as the hackathon guys and yeah, it's true. We do a lot of hackathons, but we do a lot more than that. I actually did get my start as a developer at a hackathon. I was an aspiring lawyer who quickly realised that being a programmer was a much better idea for me. And after switching into computer science, I also realised that we don't actually teach computer science students any of the skills they actually need to start their careers.

It's a lot of things that are really useful once you already have a job, but it's not the practical problem solving elements of using code that you need to get that job in the first place. Luckily, I was able to find things like hackathons and internships where I was able to actually get a world-class education in building things, and I founded MLH as a way to help that entire next generation of technology talent, whether they're a computer science student, a bootcamp grad or self-taught actually bridge that gap between what they learn and what they need to be able to do to be employable. We do that through immersive educational programmes that are free for developers and allow them to get their hands dirty with the code and tools that they're actually going to use on their journey. They're going to build a track record and a network that are going to ultimately lead to their success of going out and landing a job.

And we started with events, things like hackathons and workshops and conferences. We launched a massive co-located virtual internship programme that's all based around open source and we do a tonne more than that. And to give you a sense of the scale, this is not some small side project we've been working on each year right now we're reaching one in three US computer science graduates just in the United States alone, and that's just one of 90 countries where we have a presence around the world. And in fact, earlier this year, our community actually passed over a million community members, which was something we actually completely missed because of how much it has grown. Yes, that is pretty cool, and not only these just aren't some email addresses in a database. About 40% of those people say that joining the MLH community changed their life and they would not be where they are today without us.

So we know a lot about developers and the way that we actually fund all of the important work we do is that we work with brands like the ones that you all work at who have a vested interest in the specific skills and technologies that the next generation of developers actually learn. Fun fact, those community members actually also have a vested interest in learning the best technologies that are going to prepare them to enter industry. And so we help connect the dots by teaching those developers how to actually use your APIs and technologies to solve real world problems so when they go on to work at companies, they can actually use those tools as if they were default tools in their tool belt. We worked with some brands of all shapes and sizes of various stages. In fact, a lot of our customers are actually here in the room today, which is pretty cool.

We've been able to say hello to a lot of you and today I'm going to share some of the expertise that we've developed in working with these companies and empowering nearly 10% of all of those software engineers in just the US alone. So we're going to use a little bit of basic finance theory to accomplish those goals. Now, in finance, we actually usually have one goal. It's to maximise returns in our financial portfolio. Returns are just the total value of all the assets that we have in portfolio, and while some individual assets like stocks or bonds may go up, others may go down. The thing we ultimately care about is adding all of them up and making sure that at the very end, that number is going up in general and endeavour. While our ultimate goal is probably sales, especially in this market right now, DevRel, there's actually a tonne of more diverse leading indicator returns that we can care about.

Things like enterprise sales as we just talked about, the trials and free signups, brand awareness, product development and feedback, relationship building use cases and content, cross-functional value for other teams and community goodwill. Now ultimately we're going to build a portfolio of programmes, things that I'll talk about what those look like in a second that are going to help drive some of these ROI. Now, we can't do all of everything all at once. We actually need to focus on some level. So in the framework I'm going to fill out, I'm going to constrain us to a maximum of three of these ROI goals that we're focused on and a maximum of three strategies that we're using to actually pursue these. And the way that we actually generate this ROI to be clear is investing in again, these assets using our resources, our budget, our time. So what are these actual resources?

Well, in finance we have traditional asset classes, things like stocks, bonds, and cash equivalents. In DevRel, our core three assets might be things like events, content and maybe community engagement. Events are dynamic, they show significant returns quickly. Maybe they're close to stocks in the world of finance, hackathons, conferences, workshops, webinars, so on content, these kind of steady streams of engagement that build continuous trust over time and provide just this continuous return. Maybe that's something like a bond, but it's blog posts, tutorials, videos, podcasts, newsletters, and community engagement. This is just kind of the low risk always on stuff that we're doing to make sure that we're reaching developers where they are day to day. This might be things like social media or stack overflow or forums or your Discord or Slack group that you have. There are plenty of other asset classes that you can bring in when you're ready, things like ambassador programmes, open source work, like whatever.

But for the sake of this talk, I'm going to focus on these core three. So how do you actually go about selecting the assets, the things that we do in our DevRel portfolio, how we spend our time and money? Well, as painful as it might be to hear the most common DevRel strategy is actually what I call throwing darts, and it's also called that in the finance world. Basically the way that we apply this strategy is we often empower individual developer advocates to make decisions about how they spend their time, what events they go to, what content they write, and when I first started in Devrel, it was exactly the same way and every team or many team I've encountered over the years operate the same way too. And while it may seem intuitive to just trust your hired experts, the truth is that where they actually allocate their time each day is going to be variable and it's not going to be working in concert.

And so ultimately it's going to come down to luck more than anything else. Now, the world of finance also had the same problem, and back in the 1950s, portfolio managers used to think that their only job was actually just to identify the best individual stocks and pick them considered on a standalone basis, but that all changed when this guy Harry Markowitz came around in 1952, he wrote an essay which he later won a Nobel Prize in economics for where he had coined the phrase, invented this thing called Modern Portfolio Theory or MPT. It's basically just a mathematical way to look at risk inside a portfolio and to evaluate the expected return of individual assets as well as a total portfolio. So basically like to sum that up, really all he did was give investors a formula where they could think about how to build the best possible portfolio in aggregate rather than thinking about individual assets.

I won't bore you with the actual math, but the key insight is that an individual assets risk and return should not be assessed by itself, but in the context of the overall portfolio and how it contributes to the overall return, focusing on picking the one individual best stock is less important than making sure that we have a portfolio that is going to be the best overall portfolio. So what does that actually mean in practise? Well, to see that we need to talk about risk and specifically we need to talk about two different kinds of risk. The first one is systemic risk or portfolio risk. This is the stuff that is common to every asset that you cannot account for covid, a tech recession, an AWS outage, AI eating the world. These are the things that you literally cannot prepare for, and everybody in every asset deals with the same challenges.

Specific risks on the other hand, are the risks associated with individual assets. There are things that go wrong with some kind of individual programme you're doing. Your staff gets sick right before they go to an event. Your company's blog goes down, a random framework falls out of favour. These are things that can ultimately be reduced through something called diversification, which effectively can be used to cancel out these specific risks. And what that ultimately means is by having a bunch of different kinds of assets, we can make our portfolio way less risky than owning a single one. Now, it seems almost too obvious to state, but diversification is so powerful because it just helps eliminate a lot of the random noise that comes up in how a portfolio is returned. Now, the same thing is true for your DevRel portfolio, and what I've learned so far is that rather than picking individual investments, we need to be considering that whole portfolio of all the things we do in our DevRel activities and optimising it so that it all fits together into a cohesive strategy that ultimately helps us maximise those returns.

The last two things we need are an investment style, which is basically just a set of beliefs and philosophies we have about how we're going to use our resources. It's often constrained by our goals and by what we actually have on hand, and we need an investment strategy, which is how we actually put those styles into play or those beliefs into play through execution. So now we have everything we need to start filling out our framework. So let's start with the resources that each of these organisations have. The two main resources that we're talking about are here, again, time and money, and as you'll see, they're kind of inversely correlated. The startup has the least money and the most time the larger or more mature organisation has the most money, but the least time they're spending a lot of time going through internal bureaucracy, managing internal meetings, things like that, and the growth organisation is somewhere in the middle.

What about the ROI for each of these though? Well, it ultimately might be direct sales. Let's talk again about those leading indicators for the startup. They should be focused on activities that will get them into that product market fit, right? It's finding use cases for their technology. It's collecting feedback on what they're doing. It's deepening relationships, the potential customers to identify the actual problems they're going to solve. In this portfolio, we're going to be looking for assets like individual hackathons, niche communities where potential customers live and thought leadership targeted it the problem that we're actually going out to try to solve our growth stage. D organisation cares about getting potential customers in the door and expanding the spectrum of offerings that we have to ultimately be able to service them. They care about activities that generate lots of new user signups, build brand awareness among potential customers and build cannon fodder for sales and marketing that ultimately power those engines.

I would expect this portfolio to a mixture of events and contents and community engagement with targeted offerings in areas of expansion and scaled programmes in the core customer bases that we know work. And finally, our mature organisation is going to be way more focused on maintaining their position in the market and preserving those existing customers. They care about brand awareness. They care about making sure that they have those customers for a long time. They care about deepening those relationships and expanding the work that they do together to ensure that integration is not going anywhere and that revenue grows over time. Their portfolio is going to be the widest given the amount of resources they have, but they're going to be focused on maximising the scarce time that they do have available by leveraging other external partners. Finally, we need to talk about investment style, which again is the set of beliefs that we have that inform those strategies.

So the first thing we're going to look at is active versus passive. An active investor is somebody who's actively picking the investments they make. They believe that they can exploit their own individual knowledge or their time doing research to find the best possible investments, whereas passive investing is investing or relying on an external system or person to do that on your behalf using some kind of algorithm. In the long term, almost all investors read towards the average, which intuitively should make sense to everybody here, and so what most people end up doing is use passive investments like your 401k or maybe like a robo investor because ultimately they're going to bet on the entire market rather than spending the amount of time and individual assets. The way that translates into DevRel is actually really interesting. We can spend our time actually looking at individual investments.

We want to make blog posts, we want to write events we want to attend, or we can start working with trusted partners that have their own algorithmic way of picking this. And this is a really interesting place to compare and contrast working with somebody like MLH versus an individual hackathon. When you sponsor an individual hackathon, you have the ability to generate significantly more or ROI. By being there, you're investing a lot more resources by working with somebody At MLH, what you're saying is like, Hey, rather than having a presence at this one particular data point, we want to actively work with MLH to reach hundreds of hackathons over the course of calendar year. Other examples of this might be working with a content agency to generate your content or paying external community members to do support, but ultimately it comes down to are you doing it yourself or are you relying on someone else?

The next bit we want to talk about is value versus growth. Value. Investors are looking for bargains. They're looking for cheap, often out of favour, stocks, cyclical things. This is the type of thing that Warren Buffett is really famous for, just looking for stuff that's undervalued, whereas those who are focused on growth are looking for opportunities for their investments to grow radically. Usually they're looking for lesser known assets that have a chance to grow exponentially. A good example of this is South by Southwest in 2011 versus today, back in 2011, a lot of DevRel startups were there doing guerilla marketing. It was a place where you can go and make a lot of noise and splash. Today it's incredibly saturated. It's still a really important event, but it's a lot harder to be heard from all the noise of all the other stuff that's going on.

It's really hard to be investing in growth if you're not actively investing, right? If you're relying on passive investments because they rely on actually picking specific growth opportunities. Finally, we have the size of company or size of opportunity or investment as a basis. Large cap versus small cap. You could think about this as something like your blue chip kind of established brands versus the smaller up and comers. There's pretty strong evidence in finance that your smaller assets are going to be able to grow more considerably by factors of magnitude than your larger assets, just kind of the way things work, but obviously you need a lot more of those smaller ones to be able to have that pay off. You can think about this as like name brand kind of flagship events, maybe like AWS reinvent or picon versus doing local meetups or more community kind of aggregated networks.

How often this is going to be constrained by your budget. Just as an example, sponsoring one event can be really expensive. Let's call it 10 K at a minimum between your time and t and e and all those things, but if you want to be highly visible at some of these larger events, you're talking about increasing that by own order of magnitude or even more sometimes, so it can be really expensive. So which of these should each row orgs invest in? Well, our startup is the most binary of the three due to their extremely limited resources. They don't have the ability to run scaled programmes, so they need to take advantage of the unique insights that they have about their potential customers and make investment decisions actively. So they should be picking the content community and events they get involved with. Explicitly every opportunity should be about growth.

It should be expanding into the right new markets and looking for opportunities to develop new customers. They should be staying away from those type of larger blue chip events where they're just going to get lost in the crowd. Our growth dev org starts transitioning into mixture of scaled and passive programmes. I'd expect to see about a 50 50 split from them. Their programmes are still focused on growth, so expanding into new potential customer bases or people that they can offer solutions to driving that funnel. But occasionally when a good deal comes across their desk, they're going to take the value option. We also have the budget where we can start thinking about getting involved with some of those bigger name brand opportunities, but we have to be really specific about which ones we compete in. Finally, our mature organisation has transitioned into relying on external vendors for scale.

They're not picking their own investments, but they should be picking the right partners that ultimately allow them to achieve a consistent always on programme. When they do pick their own investments, it should be extremely rare and strategic. They also love a deal bang for our buck. The more ROI we get for our dollar, the better. And it's not that we're going to be spending less money in those opportunities. We're going to be spending the same amount we would in more expensive growth opportunity. We're just going to get more back for it when we do it. We also do have the budget to make a splash of these bigger events, and so we are going to be looking for those bigger opportunities because we're going to use our strengths. We're going to dig in and make sure that we can box out potential competitors. Now finally, now that we have these constraints, we need to actually think about the strategies we want to use for each of them.

Let's start with our startup. The first thing they should be thinking about is what's called contrarian investing. It's an investment strategy where you're basically characterising purchasing things based on the prevailing sentiment of the market, often going against it. This might be something like investing in things outside of hype, like AI is really hot right now. Maybe you say, okay, I'm going to go after Web3 events because they're less than the zeitgeist. You believe that crowd behaviour can be exploited to your advantage, and a startup implicitly has the ability to be able to do that better than anybody. The next thing they can be doing is quality investing. This is about investing in best of class assets, making sure that the picks that you do make since they're the most limited, are the best ones you can possibly make for those resources you can be looking for in assets.

Things like a great management team. Maybe for events you're looking for great organisers, but you're using a quality bar to assess your investments. And finally, our old friend throwing darts. The startup stage is the only time it is acceptable to be throwing darts at all because ultimately you're going after unknown unknowns. This is a time where you can explore and find things that work, but we're searching for product market fitness as soon as we find it. We need to stop throwing darts now because they're actively investing those growth opportunities. They're going to come, they're going to be able to formulate these beliefs and really pick actively. The key point is that they have the time to try to beat the market. Unlike our other two DevRel orgs, our growth stage needs to be thinking in strategies that give them leverage while enabling us to invest directly in new areas of growth.

They can use style or theme investing, which is an approach when you basically lump things into categories and best invest in those specific categories. So that could be things like maybe emerging markets or clean energy in DevRel. That could be specific language communities or that could be maybe you want to own all the DevOps meetups. In addition to that, they should be doing what's called momentum investing, which is the idea that you are doubling down on the investments that are paying off and divesting from the ones that are not. You are. Goal is to find things that are working and can keep putting your resources into those to keep pumping the engine while reallocating the resources that are not working as well into other things. So sponsoring an event one year, evaluating whether it's a good opportunity and then reinvesting it if it is or changing it in something else.

And in fact, doubling down is the key component of that as well. And finally, they can start using satellite and core investing where they basically identify a core group of assets, things that we know reach customers that we already can speak to every day, and use our passive programmes to reach those while we're actively investing in expansion opportunities, things that bring in new customers or markets that we haven't actually reached yet to build our expertise there. So our startup has these resources, not a lot of them. We should be building scalable passive programmes, but ultimately we need some always on opportunities. Our mature organisation is going to do some things a little bit differently. Their strategies involve making sure that they can maintain their lead, so things like buy and hold where we're investing in something over the long term. This is a viewpoint on market timing.

You're able to think long-term as a larger organisation, and ultimately if you can stick around longer, you can see the ups and downs of things until they ultimately return in a positive direction. They can also use indexing like being everywhere. It's again, I talked about your 401k or maybe things like that where you're basically just getting a collection of everything, having a presence everywhere you can. And finally, laddering, which is this idea that we're going to have a series of investments that have different time horizons of payoffs. We don't want to just focus on investments that are going to pay off today. We need to think about some that are going to pay off a year from now, two years from now, five, 10 years. It's called laddering. This is actually another great example to highlight MLH, but nearly 40% of our audience goes on to introduce technologies.

They learn through MLH into production at their first job when they graduate. We did a five-year longitudinal study on this that actually showed that we were able to directly impact cloud platform buying behaviour of developers over a five-year time horizon after they had been exposed to one of our customers and then ultimately went into the job market and that they were 50% more likely to buy the cloud platform that they actually learned on while they were student at Major League Hackings events. This is an example of buy and hold indexing and laddering all at once where we are investing in a long tail of developers who are coming online and ultimately building customers over a longer time horizon. So there we have it, a concrete diversified investment portfolio plan for three different DevRel organisations at different stages, and we started with the resources we have to spend.

We identified our desired ROI. We came up with the concrete constraints around what we believe about the market and what we can do and ultimately identified strategies we can use to effectively implement these. And now the one thing I want to say to make all of this work is that while your DevRel organisation is growing, there is an natural push to do more, but there's one key to making this all work, and that is to just say no. If something does not squarely fit into your strategy, you have to be willing to turn it down. Less is more, and organisations that focus on the specific implementations and strategies that they have identified are going to be more successful. You may get lucky occasionally throwing darts and just trying to do a lot of things, but I promise you that focus is the best way to generate real returns.

So let's all practise together. Let me hear it. Let's all just say no. No. Oh my God, my 1-year-old at home does a better job than you guys. Let me hear you say no, I know. No, there we go. Okay, finally, I'm just going to give you a three quick things that I think are my hot takes on the DevRel industry right now. If you're looking for opportunities and investments, things to be doing, the first one is to take advantage of the hyper focus on revenue and the United States. Right now, every company is retentioning in the market with the highest buying capacity, and they're really focused on proving ROI right now. The maximum that you should be advancing while your competitors are retreating is something that you can be taking advantage of by focusing on investments that don't have a necessarily direct media connection to ROI and terms of generating revenue, but will in the long tail, you should divest from anything that boils down to glorified tech support.

We saw that demo earlier from Craig around where chat GBT is right now today. It is really good at solving the types of problems that people post on Stack overflow or posting your local discord chat. You should be doing your best to divest from those and focus on value that is unique that your evangelist can provide that is not around these basic bug triage. And finally, email and SMS are actually the most valuable developer networks out there. The adage that developers don't check email is complete bs. I can tell you that with confidence, everybody's phone has their email and their SMS in it, and if you can be in their hand engaging with them, that's the most intimate connection you can make with the developer to build loyalty, trust, and connection. So with that, I just want to thank everybody for your time. I hope you learned something today. The link to the slides is up there on the screen if you're interested. It's speaker deck.com/they call me Swift. It's got all of the slides from every presentation I've given, and I want to just give a quick shout out to the devcon organising team. They did a fantastic job putting together this conference and all of you made it such the success that it actually is. So thank you everybody. Happy hacking. I'm swift.

MC: Alright, thank you so much. Do I anything?

Swift: No, you're good on the teeth.

MC: Okay, cool. Nice. Got to check every time you know those bagels, we have time for some questions and so I opened the floor to you all. Any questions out there for Swift show hands? Yeah, no,

Swift: It was very thorough.

MC: Now we got, now I got some here. Wait, I got, I'll give

Audience member 1: You check, check, check. Can you just elaborate on your last point there about the glorified tech support? Just want to hear you say more about it.

Swift: Yeah, so basically what I'm saying is if you look at DeVere activities that ultimately boiled down to solving and triaging basic developer issues, things like, Hey, I'm trying to set up the sample app and this thing isn't working. If you hang out in the Discord channel of a lot of APIs or platform companies, that is the most common thing that's happening. A developer is trying to get started with the API or the SDK. They encounter a bug and they go to the Discord and post it. If you look at historical stack overflow questions, it's a lot of the same stuff. The lion's share of tickets or issues that are being raised are things that are easily addressable by generative AI solutions right now. And they're not perfect. They certainly have a long way to go, but the trend is converging around those types of low level time to hello world type bugs being resolved by computer systems.

And so my advice is that you should be thinking about your developer relations team and the value they can provide on a level that is more difficult for technology. So that's going to be like strategic advice for businesses or ideation and brainstorming of financial solutions, exposing them to unknown unknowns, things that they don't know that they have right now. But if you have activities like let's say that you're going to hackathons and you're mentoring people on how to get started with your API, that's great right now, but this is a closing window in terms of while that's going to be useful and the skill level you'll need to be able to do that.

Audience member 1: So for a company that's reaching maturity, but just getting started with DevRel, what's the best way to engage with MLH to accelerate our programme?

Swift: Yeah, it's a good question. I actually think that in almost all cases, no matter how mature the organisation is, you need to evaluate where you are as a DevRel organisation first, to be honest, if you don't have the basic fundamentals down, no partner MLH or otherwise is going to be able to help you get them. The failure points we see often when that stuff is happening is maybe they don't even have documentation set up. Maybe there's no way to actually sign up for a free account or to give somebody promotional credit so they can try something out. Maybe the API is bottlenecked by compute capacity and they don't have the ability to just bring in 10,000 people to do it. My honest advice if you're just getting started in your DevRel journey is that you shouldn't be looking for scaled opportunities like the traditional way of working with MLH.

We do have individual events that you can sponsor and be a part of where you can engage with our community directly. I'D out something like Global Hack Week, which is a monthly festival we run for a week each month focused on a different technology theme. Those tend to be much more direct engagement opportunities where you can get a demo, something, provide a prompt to hackers to work on and actually see them do it. But bringing out a scaled promotion to a hundred hackathons of something that you're really just figuring out is probably not the move that our team would advise you to do. So my honest read is come to MLH, say, Hey, we're going to get involved in some of these events to talk to developers, get them using our APIs, build the muscles around the basic mechanics of deux, and then as soon as you're ready to transition to that growth stage, that's when we're going to become a valuable partner.

MC: There's one behind you, Rosendo. Oh, and one in front of you too. Alright, cool.

Audience member 2:: Given what you said just a moment ago about generative AI being be able to solve these smaller triage things, on the counter side of that is that AI got smart because of public documentation. So do you think you should be investing more in better documentation or you should just have more content out there and less polish just so the AI can pick it up? How do we compliment that?

Swift: There's a really, it's a chicken or egg problem you've correctly identified. Here we are, this is a deep tangent, but we're riding a wave right now where we're benefiting from all of the free public information that's been available on the web for basically decade plus at this point. Let's maybe call it two decades. And that is what is making everything that's happening right now in generative AI possible. And as we become more and more dependent on those systems and we're generating more things with ai, it's kind of like a snake eating its own tail. We have to kind of hope that there are going to be other unique proprietary data sources that will come along. And I would actually argue that something like GitHub is actually just like a maybe ubiquitous turnkey solution to that in the future. If you look at copilot, it went from zero to 80% adoption among our community members in less than 12 months, which is an absolutely unheard of meteoric rise.

And the reason for that is because it just has this utility that solves a really basic problem that just about every junior developer has. And I think as they continue to write code and we can continue to utilise that same data set to basically feed itself, the one advantage we have there is that the code is guaranteed to be working if you're building software that actually works. Maybe it's a little bit less error prone than things like Stack Overflow or documentation, but my honor's advice is you've got to do the basic stuff. I would argue that community generated content is a longer tail strategy, but you have to be at a mature stage of a DE organisation to really be focused on gaming. That particular system that you're talking about

Audience member 3:: That ties in nicely. You mentioned the long tail strategy. You mentioned your five year study that you did, but DevRel as an industry is still pretty new. What is your advice for selling some of these long solutions and experiments that we're trying if we don't have data to back it up?

Swift: Yeah, it's a really good question. So you need leadership. You cannot possibly expect to be an individual contributor or even a manager level and a team in an organisation whose goals typically revolve around quarterly or annual metrics and then be like, Hey, we need to focus on five years. That's not going to work. You can do it and you can certainly go for the bait and switch where, because the truth of the matter is our programmes do generate immediate short-term ROI, just as an example, right? You work with MLH should do a hundred hackathons over the course of a year. You're going to get signups, you're going to get use cases and projects. If you're really investing, again, doing something for five years or whatever where you're building ubiquity, you're building a laddering system, you're building trust among the community with repeat brand impressions. That is certainly the best way to do it.

But there is short-term ROI that you can fall back on and do that, for lack of a better term, kind of bait and switch thing. If you do have the buy-in though, or you want to build the buy-in, my advice is to rely on the data that external partners have. Like case studies are an incredibly valuable thing, especially when there's a voice, like a real person that you could talk to back it up. And I think that if you were to talk to somebody like MLH and be like, Hey, I want to bring this to my CEO and convince them that we need to be thinking on a five year time horizon for DevRel, that we could connect you with somebody who did that successfully at an organisation like AWS or Google Cloud and help sell that internally, or at least give you the collateral and the data that you need to be able to back that up when you don't have it yourself. But in truth, all industries are like this, where you have to rely. You're not always going to have the data yourself. You're going to have to rely on third parties, but trusted third party vendors with a long track record of success, whether that's an organisation like the DevRel org or MLH, is going to be your best bet for something like that. I think we're probably out of time on questions. I know I went a little over.

MC: Yeah, if we have one more question, is there, I want to make sure we, okay.

Swift: Okay, here we go. I'll be around. I'm going to be here for the rest of the conference if you want to find me. I'm happy to chat. I'll be around during the coffee breaks. But again, thank you everybody for your time and attention. I hope you have a really great rest of the DevRelCon. Happy hacking everybody.