Dev rel with agile makes for a good cocktail

Karina: Good morning, everyone. Thank you for attending my presentation. I would like to warn you from the beginning, this is a presentation about my personal experience in DevRel. It's a story of one project, how I started DevRel in a company where we had nothing in the beginning. And, what happened after two years in this project. So it will be a story line, we will go through all the stages, which we passed, what achieved, and what happened at the end? And, also, I applied to this…hello. I applied to this conference three months ago and the situation was completely different so the talk will have, at that moment, the name of the talk…hello.

So you can see the name is: DevRel with Agile makes for a good Molotov cocktail. Because, originally, I am from Russia and I wanted to put, yeah, spicy stuff. And, at this moment, the Molotov cocktail was like a drink. You know, something which is very simple but, immediately, it can influence you, yeah?

So you can see, this is my twitter handle. I would really like to receive your feedback after the presentation. And so remember, as I told you, there's been different stages of the project -- we will go through them. And there's also a timeline and we'll see.

What to look for in a company

So the whole story starts 21 months ago, it's when I joined the company. And the company had a very interesting style. First of all, it was, of course, an agile development environment, which was really cool. But they also had…they put this agility not only in development but also in personality, you know. That like we have to treat things very agile.

And so the first, on the first slide you see what actually are the main things we are looking for when we want to join a company -- especially if you are the developer relations…you have a focus in developer relations. And what I liked at that moment that we had different principles. Like, thinking where you…which means that you always think about developers and the product at the same time. There is also fever to deliver that everyone is able inside the company to provide his feedback. I think it's very valuable, especially when interpretation of the conference or after the conference so you will receive feedback -- feedback not only from attendants but also from your colleagues is very valuable. And, also, freedom to act, duty to correct, so it's a continuous improvement. Sharing leads to caring.

Almost anyone can jump in from the company and give a talk, or provide customer support, or…and I really enjoy this because it's, for me, it's expanding knowledge enormously because I have so much experience nowadays but you know almost everything inside the company. And in team we trust, which means whenever we need to decide something it was done very quickly. It's like in one hour, we have the meeting we discussed and we don't need to go to the management board. And even questions about the budget…and it was one of the main points why I joined the company because I really saw a good value in this. We can achieve the best results very quick, especially in the context of conferences. You know, that when you shouldn't say, do we need to join or not? It was very easy to discuss. We don't need to focus on…like go through the process and wait months or two for approval from a management board.

How to be agile

So but agile, there is different ways to techniques and the most popular one we heard is Scrum and Kanban. And they have their own advantages and disadvantages. And Scrum is good for DevRel because actually the team is cross-functional, which means that you have at the same time -- a marketing person, a sales person, but they're developers who cover completely technical point of view for the presentation, for example, for preparation. At the same time, there is a professional person who's writing blogs. Because if a person studies hard, first of all, for your university -- how to write a professionally a good article, succinct. Whereas, still, as developers can do it better. But they need to have a very good technical background that's why I think in this context it's very good -- for DevRel.

And we had, also, daily standup and project reviews, which is very good for conference preparation, for example. Or, for writing a proper recommendation for developers. Like, you're very flexible and react on any changes and Scrum is good for producing good solutions and with high performance. At the same time, this is not a technique but Scrum, we should talk that it brings work. So basically if you commit to work with Scrum, it means you will start the preparation for the conference like two screens in advance -- something like this. And then, it's really good. I will talk later that you can prepare very well but, at the same moment, you're under time pressure and it feels very stressful.

Kanban is different because you can start like six months in advance and you put all tasks already -- what you want to do. But it can also be not a right technique when at the last moment, before your conference you want to change something or you just got a new feature for the product but the task already done, closed, and you are not kind of able to deduct it.

A very cool style that we had inside the company -- the respect, fun at work…where fun at work is not that we were laughing all the time but that we were enjoying the process of work, like a team. That we were very open and did just speak up and speak out. That we were always transparent with developers -- at what stage we are? What next features would be available? And what we decided it can do? And so yeah, 21 months ago I joined the company. And then, we're going to the next stage -- 18 months ago, in January 2016 -- we start a new project.

Stories and personas

And this project, I was very excited about because like you can see these keywords -- it's, let's say, the most popular keywords nowadays. It was about IoT, AI, and we provide an API for all of these -- it was very cool and but, as today the talk is about DevRel. So basically agile-style is…it forced us to have kind of a scenario for almost each story to make it, the process, easy. And it's, usually -- who is user? Why do they need the feature or project? And what goals does it have? Actually, the same questions for DevRel is answering when we want to target the right community or the right audience and when we choose an event or when we do proper talk, we always think about these questions.

And there is always a user story, which you have to write, which sounds like, as a developer, I want to have…I want to achieve something like to easily integrate API into my product or something. And so that can bring me…make the product more efficient, for example.

And in the agile-style, you always, when you work, you always have a persona. And for DevRel, you have a developer as the persona. And, for example, in our case, we created this persona, which was 20-years-old, DevOps Hero located in Berlin, working with for tech startup with 10 employees. And this immediately gives you an impression for who we want to prepare our presentation, who will read your documentation? What he would be interested in?

And you also can really write a full story about the user. So for example, a story which gives you, really, lots of insider information. For example, this person who doesn't have a family, which means that he's quite flexible. He can always attend hack-a-thons, for example, spend the whole weekend…it gives lots of insider information. And, for example, that he already has his own IT infrastructure. That probably, this person really has gone through the documentation to go try it by himself. So it's better the project has more features and it's very easy to do it and have a comprehensive documentation, which anyway they're going to open. Yeah, user, he's working in an open source, it also gives us a lot of information. And there is even in there, should be some data about his situation -- financial situation and about political…yeah, his freedom is important to him. And is he introvert or extrovert? And, also, the information, for example, that this tech startup is a sort of a company, for him, that he's willing to change and maybe it will be cool that he joins your company at the end?

Using mass media

So this was a new project we start. A project of the same startup, we started mass media. And so 15 months ago, in April 2016, even as the project was just launched already in a conference in New York, and it's called IoT plan. It got lots of feedback and users and we were, obviously, not ready for it, yet. But the good thing that this feedback really give us a picture of what we want to achieve with our product and what is the value, which we want to give the developers?

And this mass media the main questions which we were focused on -- what kind of events we want to attend? Because of the different communities and IoT community wasn't so strong at that moment -- it was a year ago. In the U.S., it was already very strong. In Europe, it was just the beginning, like last year what they're doing for IoT.

We said the word inspiration so basically, what we decide that we will try to do with many user cases as possible. So for almost 10 different IoT scenarios like in alarm systems and water management, and self-driving cars is like different. We prepared completely examples -- how easy is it can…for example, we had all projects in our Github. Developers can use it. Very easily to jump in and see that it's…that it was much easier for them to start with our product. Yeah, and of course we increase awareness with this and in One Sprint work, so we decided to work with the Scrum technology and prepare for the…for example, there is a, how to prepare for the conference? So, first, the preparation for the talk -- you do the presentation, speech, website, announcement, blogpost. And when you have a team with the people with different skills, it's very easy, in one sprint, to write blogposts, to update your website. At the beginning, when I start, I was the only one and I have to do it all in one week and it was really hard to do. When you have a team, it's much better that everyone else uses the tool.

Yeah, then, also, to prepare for the conference, we go through the list of speakers and we try to prepare for networking. If some of the speakers are already trying a new product or you see some collaboration and opportunities, it's very good because speakers are usually quite big influencers on Twitter and other social networks and really bring better results for your product. There is also a conference day, which is quite a hard day. And after the conference, so in One Sprint, if the conference was in between, after the conference, you spend some days to…analyse the feedback and this feedback is really about the product, which means writing new stories -- how to improve what is your next features you want to develop? What went wrong and…so this was mass media.

KPIs in an agile environment

And as you understand, the next three months we spend on creating a better product. And the one main thing is, how to prioritize which product features and improvements you want to do? At the same time we do a DevRel. And because there is like, there is a question -- what is first, in here? Do you want to treat your developer first or you want to focus on your product. And when you do, does it save you time? It can be very confusing so that's why we created the definition of them, which includes at the same time different point of views on almost each story and different criteria. So, at the same time, you have to be focused on the technical details, on the user -- what's available what your user gets with this feature? And, also, business because, at the end of the day, the company has to earn money. And if this feature, it really requires lots of time, lots of investment/personal investment, and if it's something, which is just a small improvement but with lots of time investments, probably, from a business side it wouldn’t be nice.

Yeah, so our KPIs, when you're in an agile environment, actually move from command and control to context and trust, in our case. And I really like it because in DevRel, KPIs, it's something what we're talking about all the time and no one really knows what it is -- KPIs? And when it's based on trust and everyone feels responsible of this product, so it brings really good results even if your KPIs is just based on Twitter use or sign ups for the product.

And, yeah, nine months ago, it was a boom. So at the start, you see lots of developers. And …there was one question -- how will you keep them to use our product? Because we also start to have competitors, at this moment, in the market. And that's where developer relations like inside the company, it was being proven that when we have a relationship with developer, it's actually the best way for a long time. Nowadays, marketing without relationships is nothing, there is all the advertisement over social networks. For developers, it's really important to have his personal opinion, his personal context inside the company. It's like it's very important to go on office events, and participate, and write a blogpost, and have a good social profiles where you talk with your developers.

Be transparent and offer education

And, yeah, some success factors, as you see, why we got so many users is that we were very transparent about which stage we are. So at the beginning, when the product was just launched, we told everyone it's just a testing phase so you can try it out. Yeah, we also didn't try to sell it. First, it was, can you at please try it out and try your ideas? And if it's a cool idea…and so the main thing is, if you give…if one content developers who come up with a really great product will be also good for your network so it's…it's better just to offer it, and a new solution, but not to sell it. And also, choose the language because the software developers, since we have, the marketing language is not our language. And, also, you have to be there for the developer only when he needs it. Don't attack him with all your emails and marketing activities.

And one of the coolest factors are educate your audience, which means provide as many…like, in our case, we create all these use case stories and people could learn and they could see how easy it is to do a smartphone application, for example, and it's really this, for example. So yeah, and social skills for developer relations are very important.

Trust and team spirit

Then, after this, it was it happened that we got an award. And it was an award for Best Innovative Technology In IoT In Germany. And it was immediately given that everyone started talking about us. And on this slide, I would like to talk -- what does it really mean to me? Because when you are doing something, there are a lots competition you can apply, nowadays -- there are so many of them. And, actually, I don't know if you apply 10 times, you win something at least one time. And it's really important because whenever you talk with someone and say you have a product, they just listen to you. And then, you say you have a product and it was named as the best solution, it's immediately trust -- the trust creates right away, even if they don't know about the product -- anything. It's also really cool for team spirit. Because the team is immediately starting to believe in product even more and invest even more time with this. They're going every day to work with it because we work much more happily. And yeah, all competitors and companies around, they start to invest time in researching about your product. Which I think is really cool because they try to do better and when you look at their products, you also try to do better -- so, somehow, it shapes the industry every time.

After this, it was a customer boom. We got like 10 times more customers in this month than in the whole project. And so there is a question -- how many users does a company need to be successful? And we didn't expect many users. And it was such a huge success for us. And as our business model was that you offer our Software-as-a-Service, which means that we're quite stable. And the problem was, with the customers. When your users are developers, the technical questions, which they will come to you are really complicated. So user support should be…or customer support should be a really knowledgeable person. And developers who work inside the company, they usually don't like to do customer support so this was the problem, to answer all requests. At the same time, there are thousands of developers. When you have a team, just two developers…yeah. But, at the same time, because we work in agile-style, everyone in the team, even the marketing person, as they know how to answer most complicated technical questions.

The meaning of a Molotov Cocktail

And this was the moment when I applied to conference and the name of the talk was: Molotov cocktail. And I really thought about the drink because it's like very simple, it's quite…not so many ingredients, very transparent, you immediately get effect -- so this was my idea. And, now, we have come into the stage, this month, what happened in the last three months? Actually, the company got acquired by another company. And they decide to cut completely development and to have just sales people because they don't see real value in DevRel. And the serious question -- what software developers can teach sales representative? And it's what we were talking about these last minutes. It's actually continuous small wins. It's how we work in DevRel, step-by-step, we're winning one-by-one developer. And it's how we're improving our product. You can't sell it either with something. You need to know the technical side of the product and you need to go through all the steps to understand the value of the product. And, yeah, so after this, you could see what was inside of this cocktail. It was agile principles, new technologies like IoT and AI. We create a great product. We were treating our the developers very good. We don't forget about marketing because marketing is still important for DevRel and we go out on our word and we create a really strong relationship with our developers. And the name of my talk is still Molotov cocktail but it's moved from the drink to the real meaning of Molotov cocktail, which means at the  end it is all burning down right now, which is very sad situation, yeah.

I just would like to finish my talk with again, bringing together DevRel and agile development. So this is the manifesto for agile development. And the main part, as you can see, that individual and interactions are always over processes and tools. And this is the same that we do in DevRel. We always treat our users as, first, developers. We're also working software over comprehensive documentation. Customer collaboration over contract negotiations -- that was what I was talking about. That if you see a potential in the idea of developer, just give him your software for free or your product for free. And then, try to sell it and people get very confused because he's somewhere on the early stage of his product and so on. And responding to change over following a plan -- I think this is also, in DevRel, something really important. Because the market changes almost every month and you could create the plans for the next year, how you're going to go with your DevRel it's almost not possible because we always have a new event and we always need to jump in and be very agile. Yeah, thank you for your attention.

Photo Credit : Kansuke Nakai