Starting up startup DevRel

Lorna Mitchell: Hi. I'm Lorna. I am head of DevRel at a company called Ivan. We do cloud databases, as a service. So I have one of these head of DevRel titles, which was so controversial yesterday, and actually, I'm internally I'm technically developer relations lead and there is a clear career path, but I tend to use head of DevRel outside of the organization.

So today, I want to share my experience of bringing DevRel to a startup that did not already have DevRel. Now, Ivan is a pretty mature startup in that we have announced both a series c and a series c extension this year since I joined in January. So like we're now a unicorn, your call whether you think that still counts as a startup. I'm gonna share my tips of what really worked for me, and the advice that I wish I'd had a year ago. So, a year ago, this photograph was taken, because ten minutes before my final interview at Ivan, I ran down the stairs to my husband and said, quick, photograph me, I think I look presentable.

It doesn't happen often and I've been using this headshot ever since. What this woman who's about to land an amazing job that's gonna change her life does not know is that being the first hire for DevRel for a startup is super super risky. And I think in the year that, or nearly a year that I've been doing this job, I've really started to understand why. And the main reason is, you know, when you make your first hire for a startup, for DevRel, really your first DevRel hire in any size of organization, you need to be clear what you want them to do. Is it the senior hire?

Are they gonna have responsibility for strategy? Are you gonna listen to their expertise in DevRel? Or do you already have a strategy and are you looking for people to fill that in? I've been kind of had neither, but I needed a new job and I thought they were pretty cool. Also crucially, I was not the first hire for DevRel at Ivan.

I'm only half of the first hire. The Francesco is in channel, so he will wave at you in discord. If we were in real life, I would make him stand up and try to embarrass him in front of you all, but as it is, you'll just have to heckle him in text based chat if that's okay. So we we joined, we kinda realized that Ivan had some idea what he wanted. I didn't agree with all of the ideas.

We'll talk about that in a moment, but we pitched a strategy, we ran with it, and I'm gonna share you the outline of our year one strategy later as well just in case it's useful to you. So where do you even start? There's gonna be a research phase. You are gonna ask all of the questions, and you're gonna ask really basic questions, really entry level questions. And this is really important because you might think you've already heard an answer, but it's really important to hear all the answers from all the different people that you can meet in those first weeks.

And I think it's really important to understand how people respond to you asking those really basic questions. DevRel, you know, we we see it as being quite, an external facing function, but in truth, especially in a small company, developer relations is the glue that holds the departments together. I am the universal translation service at Ivan between sales and marketing, developers, customer success, support, like content, product marketing, we speak everyone's language. We speak our customers language, we speak our colleagues language and you will need to build those alliances. So that's part of what you're doing here when you're asking all of the questions.

The first question is what even is this thing? What are we making? What does it do? The second question, and this is the bigger question, is who is it for? Who are we helping?

Who will be successful with this thing? Who is gonna have the biggest win from using these platforms? Ivan's a really interesting one actually as an advocate. It's not a product, It's a bunch of open source technologies that you already know and love. I do not need to explain to you that Postgres is fabulous, you know that, and if you need a Postgres, ours is probably great.

As an advocate, the side benefit is that I can teach you how to do a really cool thing with Postgres, like some kind of windowing functions or some cool integration. You can use it on Ivan. Isn't that nice? The demo probably uses Ivan. That's polite, isn't it?

But you can use it on your own postgres, on our competitors postgres. Developer education genuinely helps all developers everywhere. This is not the only reason. I love working for an amazing open source company, but as an advocate, having previously kind of papered over some less awesome products, it's nice. It's really nice.

The other thing you need to know at the research phase is what's already happening. Does your company already have a blog, a webinar series, some social media presence, you are gonna adopt and should we say adapt? Those things already. Check Ivan's tweets from a year ago, check them this week. Yes, There are developer fingerprints on there.

Check also what's going to be valued by the people who will be paying you. This is an interesting one. You must understand the expectations of your manager and probably their manager depending how big the organisation is. However, you don't need to take their advice, but I recommend you pick at least two things from the things they think are important while you carry on and do the things that you think are important. So understanding what's valued, you know, is the expectation that you will do a lot of events regardless of whether you think that's going to move the needle on what happens.

If it's expected, I'd recommend you manage some at least. So understanding kind of what's here already, what people think you are there to do. We've talked a lot about DevRel not being well understood, and you are there to educate, but it'd be great if you could stay hired long enough to do that education. Right? I had some very clear ideas about DevRel, and I changed some of those ideas when I came to Ivan and they had different needs than what I had done in the past.

You need to learn what people are saying about your organization, so you're gonna spend time in the digital or or in person if that is ever a thing, communities hearing what people are saying about your product or about your platform. Hopefully they're saying something, because if they're not, that is a super hard place to start from. One of the early no news is not good news. Right? All publicity is good publicity, and I feel like that's it.

You wanna be part of the discussion and be able to hear what people think about what you're doing. One of the first things that we did, when we joined Ivan was we created the Ivan tag on Stack Overflow, and I wanna shout out to the DevRel community for this can happen a few times probably in this talk that a developer advocate from an a direct competitor used their Stack Overflow Karma to help us get ours. Our tag added to Stack Overflow so that developers could participate and chat with us there. We're a strong industry, and we can support one another beyond the interests of our employers and their businesses, and I really appreciate that. I think it's rare.

My sales team think we're lunatics, by the way. I am fine with that. So you end up with loads of ideas. Right? So these are the ideas, the things that are already happening which you're gonna pick up and bring forward, the things that people expect you to be doing, the things that you've now thought of because you've been out there.

We've got this massive, collection of ideas, and if there's one thing I can tell you, it's that you cannot do everything or not this year. My catchphrase is not today. Yes. Not today, and this is where the hard work really starts. You need some criteria to filter all of these ideas down and decide which things are gonna pick up first.

You probably, if you think of how the existing activities, the expected activities and your own priorities overlap, things that are in at least two of the circles are very good candidates. So that means things that are in all three, start there. But things that are in any two, maybe one from each overlap, should give you a solid foundation of things that meet your own needs, the company's exist picking up on what the company was already doing, to build on that and also to adopt some stuff that will keep you in the job long enough to do the other good ideas that you had. So this is one way of filtering your ideas. The other way I think is very very important in startups, and it's one thing that I think as DevRel professionals, we sometimes struggle to get right when we transition into those startups, and that's the speed at which your company moves.

So I have three flavors of startups here for you. On the left, the tortoise. Perhaps you are familiar with the the story of the hare and the tortoise. The tortoise wins the race. It's a short talk.

A nutshell, the tortoise wins the race. And the tortoise wins the race by using what they have and doing what they know and showing up and trying hard. And this is the fundamental basis of how DevRel gets done. There's a plan, you show up, you do some more. I know that we are widely perceived to be glamorously flying around the world, but the truth is a warm salad in a hotel room in the wrong time zone at 9PM.

The tortoise, especially for something like a bootstrap startup, you do the best you can with what you have, and if you are a tiny team, probably this is how things look for you as well. You have a limited amount of resource and that might be people, helpers, money, know, you have to make what you can, and this is on us to be resourceful, and to continue to find ways contribute. In the middle, this is the caterpillar. The caterpillar is going to be a butterfly, but right now it's in stealth mode. So you have some time, it might not be a lot, but it's some time to prepare for the best developer experience in the world, and I like to think of this as like planning a big party, and you've got all week to plan the decorations, order the food, you know, like get everything ready, work on all the place names.

You've got time, but you are not getting feedback from your community while this is happening, but you do have the opportunity to put in a full suite of SDKs and documentation and tutorials and everything else. And that's fine. You can have some kind of bigger plans as long as you can ship them in that stealth timeline that was available. And finally, on the right, the cheetah. This is the move fast and break things starter.

It's early days. It's very, it's probably well funded but moving really quickly, so you might be seed or series a. You don't have time for a content strategy. Okay? You just need to ship some content.

Right? These people do not want to pay you for a month in order to get to the point where you can tell them what your first blog post is gonna be. You're gonna write content strategize later. Okay? So this is about matching the cadence and the context.

DevRel is all about empathy and this is a really important part of that story. So you're gonna use all of that criteria and think about what your company needs, and how you can filter those things through. If you have there's there's a there's a a blog post actually, it's been out for a while now, but I think it's had an update. There's a blog post from Phil Leggetter about what's called pirate metrics, and this is about really understanding the stage that your company is at and what they need you to do right now. It's an amazing piece disclaimer of work fulfill, but when you're just starting a dev rel function, then you, and maybe the company isn't super well established, the products might be pivoting around you, it can seem pretty ambitious.

Another Vonage escapee, Alex Lacatos has another post about baby pirate metrics, which is just prioritizing the awareness and acquisition, the revenue and the product. And I think there's a solid places to start. I've got some links to the pirate metrics and their baby pirate metrics, stuff, so I'll either share them in chat or my team might beat me to it. So you've got a filter. You need to be ruthless here because people are gonna ask you to do more things.

You don't need to over plan. You need to under plan because you have no idea what's around the corner. We arranged the internal developer conference on a seven week turnaround. Yeah. I didn't have that in my OKRs.

So, under schedule and that means you have to be ruthless. You have a plan, but you don't have a strategy until you have metrics. You don't have a strategy until you know how to tell that your plan is working, and I think in DevRel, we just wanna do the right thing by everybody, and and we know that people are not a number. It makes us rubbish at metrics. And this is a funny thing because I was really unsure about taking the Ivan job.

It reports into marketing. I have heard terrible things from very technical advocates about what happens when you report into a marketing department. Turns out there's more than one way to do marketing. My marketing people get it, understand developers and are beautifully good at metrics and at data driven decisions and growth. They I have learned as much about numbers in the last nine months as I think I'd learned in the previous nine years of my career, and I think it's actually been a strength for me to be in marketing and to have that level of pressure, clarity, clarity about what the objectives are and whether we are moving the needle.

In a tiny startup or a very small product user base, sometimes the error bars can make things uncertain, but I think being scientific about it is important. Your metrics in the very early days might be activity metrics. We certainly started with how many blog posts we would write and how many course of papers we would submit to. Those are activity metrics. They're not outcomes, but they help you to quantify whether you should do yet another event or if you should be prioritizing the content to keep the balance that had been in the strategy.

Now we've moved away from how many blog posts and we're aiming at organic traffic because that's one of the big goals for the company, and for the marketing function to bring more interested people in through actual useful technical content. It's radical. Here is a very loose outline of our, year one DevRel strategy, and we split it into three pillars, and I think they're probably in order of size left to right as well for how that worked out. Developer education is the most important, most scalable thing you will ever do. Written content reaches people across space and time.

What you publish today will be indexed and findable by everyone tomorrow. It can be translated, it can be spoken aloud, it can be made into a bigger font, and you don't need to see my talk today because you're in that same conference as me. You can read it at the moment that you need the information. For me, this is the one true way. Yes.

I would rather write than speak, and I think I'm better at it. So developer education has been huge. In particular, we've kicked off a very ambitious documentation project. Check out developer.ivan.i0 if you wanna see what we're up to. It's also static site generator, all open source, come and have a play.

The middle pillar is evangelism. This one's super interesting because I thought that evangelism, the events, the speaking was not always a good investment for educating developers. I thought the return wasn't there. Ivan needs awareness. Actually, it's the most important thing for us.

So I've changed my mind hugely just by seeing the needs of a different organization. And finally, developer experience. We're a very open source company. We advocate for our own open source projects. We are customer zero for all of those open source tools as well as the products.

We fix readmes, institute codes of conduct, publish sample apps. We try to make things better for developers everywhere, and this is close to the education and documentation piece, but it needs its own pillar so that things don't get lost. I wanna close with just one more remark, and this one's about you. I think I'm echoing the previous speaker as well. It is on you to find a way to work sustainably in your strategy, but also in your working practices.

With developer advocacy, developer relations, all of the community roles, all of it, there's always more you could do. There's always another pull request, another blog post, another tweet, another review. More code, more talks, more rehearsal. Be sustainable and find a way that you can do this career and continue to do this career. I think we cannot be the best professionals that we can be when we're not taking care of ourselves, and especially, at Ivan.

It's based in Helsinki. They are very Nordic, and they are not asking me to hurt myself in the process of doing what I do. In fact, they'd be quite cross. Right? So find an employer that really supports that and make sure that you have your own support network.

I could not have done what I have done this year without the support of the wider DevRel community. Cultivate that community. Hang out with us here. Find us on the internet. Chat with us.

Have informal coffee with people. You are not wasting time. You are building a vital vital support network. And I wanna say thank you. You know who you are.

Thank you to everyone who rescued me from things this year. It was a massive learning curve. I've tried to pay a little bit of it forward today, but that peer group has been possibly the biggest thing that I brought. It's a start up. Things change a lot.

Try to enjoy the ride. Right? Especially when things are going well, take a moment to reflect and see that you have done super well. Yeah. It's an adventure.

Hold tight.