Made by
Made by
Tech Community Manager
Kiwi.com
DevRelCon Prague 2022
Code.kiwi.com is an internal community of developers that Kiwi.com has been nurturing for the past seven years. But why does a global travel tech company need an internal tech community and a community team to take care of it?
For Kiwi.com, the answer lies in employer branding. In a fiercely competitive hiring environment, Kiwi.com’s DevRel program is all about sharing the benefits of working at the company.
In this talk from DevRelCon Prague 2022, Alena takes you on a journey to discover the power of internal developer communities. She shares how tech companies can promote their engineering culture using DevRel tools for employer branding, professional growth, and developer wellbeing.
Join Alena to learn more about the business value of the internal tech community, the secret superpowers of the engineers (and how to support those superpowers), measurements, and some amusing stories of the whole department ‘sharing one DevRel hat’.
So hello, amazing DevRel professionals! Welcome to DevRelCon Prague once more! I’m part of the team who helped bring DevRelCon to Prague, so it’s so, so, so nice to see you all here. DevRel professionals, tech community builders, community members, supporters – welcome! It’s great. And I was also part of the programme committee and I read all of the proposals for DevRelCon. Thank you for submitting your talks. It was a great joy to read them and give feedback on those talks. Thank you for that.
Today I will be giving a talk called ‘One DevRel Hat and 500 Devs to Wear It’. I will describe the approach that we use at kiwi.com for internal community building to promote our engineering culture and strengthen our tech brand. And I will be wearing a hat today… But before I jump into my talk, I want to use this couch as a therapist couch.
The thing is, when I was preparing my talk, even my abstract, I was panicking a little bit because I’m not a developer advocate. I’m a tech community manager and I manage an internal community of developers. I was thinking that maybe you were all too experienced to hear from me. Maybe you already know all of this. And then I talked to Matthew, who was my amazing therapist. He said: ‘no, no, you definitely can do that. You should do that’. And I decided to submit my proposal. And then I was thinking: ‘Actually it’s the first time in seven years that we’re building this internal community. I have a bigger stage to communicate that and share with you guys’. And I’m also thinking about the wider audience – CTOs, VPs, directors who are kicking off their internal communities and tech brands right now, and maybe newly-hired community managers who are kicking off their tech communities. So I’m keeping in mind the wider audience. So bear with me if you know it all. I need your support.
Let me briefly introduce myself. At kiwi.com, I manage the internal tech community and I have experience in community management. Previously, I was working not only with developer oriented communities, but also with others such as a community of educators and international students. But I still love working with developers.
You can always find me on the socials mentioned here. I’m still on Twitter, but I’m moving to Mastodon to chat about community building.
Let’s set up what you should expect from this talk. So today I will introduce what the community is all about. I will briefly tell you about the history back to the origins, right? I will be talking about the approach and the tools we are using in the community. Then we will take a look at the measurements, because it’s hard but important, right? And I will share plans and some inspiration for the future.
But before I jump into the agenda, are you familiar with our product? Have you ever searched for your next trip using the kiwi.com search engine? Please raise your hand if yes. Okay, I can see some hands. Amazing. Maybe there are some folks who have travelled to DevRelCon Prague using kiwi.com. Really? Okay, great. Hello. Good to see you here. That’s great. No, we are good. We are good at bringing people to DevRelCon.
Okay, but today I’m not talking about our product. I’m talking about our engineering department and internal community. What is code.kiwi.com? What is the code.kiwi.com community? This is the name of our sub-brand and this is the name of our internal tech community. The members of this community are kiwis of the engineering department, but we are not a developer first company. We are a B2C company and our customer is everyone who is in search of a nice travel option for their next trip. Why do we need to use outreach tools for the tech community in a B2C company?
Before I jump to that, let me share what we are doing in our community. At code.kiwi.com, we speak at local meetups and international conferences. We write in our tech blog and other blogs about the technologies we are using. We educate and mentor local user groups, in coding schools, by ladies chapters. We create developer friendly content using our socials. We support each other on the road to becoming community minded professionals. And we travel a lot. We travel as a tech company and we are based not only in the Czech Republic, but also in Barcelona, Bratislava, Košice, and London. And we are constantly searching for new sites to open our offices.
Back to the origins, the history of the community. I really believe that to answer the question why we have it in our company, we need to take a look at the history. It all started with these two guys – our CEO Oliver, and our CTO, JK. A lot of great companies in Silicon Valley were founded in a garage. Our company was founded in a bar in Brno, when these two guys – JK, are you here? Hey! – when these two guys met in a bar to discuss the virtual interlining idea. And after that, in 2012, the Skypicker Company was founded.That was our former name. So in 2015, we started rapid growth and in 2016, we rebranded to kiwi.com. And in 2016, our CTO JK, who is right there in the corner, started to approach engineers asking them: ‘Hey, do you maybe wanna go outside to share your expertise and attract some like-minded developers?’ So in 2016, we founded the sub-brand code.kiwi.com and we hired our first community manager to run this internal community. By the way, he’s my manager and he’s also sitting right here in this room.
At that time we had the office of kiwi.com in a villa, and in that villa we had a wine cellar. And that wine cellar was our community space to run all kinds of community meetups and events. The first members of the community shared that the atmosphere was very welcoming, although it was cold from time to time. In 2017, we hired a community team. There was no longer a solo community manager. And in 2018, we opened our first overseas office in Barcelona and we started to scale our community initiatives, travelling with our educational projects all over Europe, we organised Women in Tech conference, Global Travel Hack, and more. I met these guys in Moscow in 2017, if I remember correctly. So we travelled a lot with our community projects. I was not there at that time with the company, but I met my manager six years ago. And then 2020. The pandemic hit our industry hard and we were kind of adapting with the community to this online style and working from home. It wasn’t the best time for our community, but we survived. And in 2021, after the recovery of the industry, we started to rebuild the team. This is when I joined. And in 2022, we are on the mission of reactivation of our internal tech community.
What’s the goal? Why do we need to run a tech community at kiwi.com? When I was researching this topic, I realised that there are actually three sides to this story. The story of our CTO, the story of our first hired community manager, and the story of our first community members. When I came to JK and asked: ‘Hey, why was that established in 2016? What’s the goal?’ He said: ‘You know what? We just wanted to post something and get on Hacker News.’ I was like: ‘Really?’ And he said: ‘Oh yeah, I really think we wanted to get on Hacker News’. I said: ‘Thank you’. And I went to talk to our first hired community manager. He said that, at that time, Skypicker wasn’t really known among people relevant for hiring. And then kiwi.com, a brand new company, nobody knew us. So the goal was to let developers know about us and consider us a department that would like to join, in a smart way, using the ‘superpowers’ of our engineers. And when I asked our community members: ‘What was the goal for you in participating in all that fun? They said: ‘Well, we just wanted to share knowledge, meet some people in tech and have some fun’. We are trying to make our community projects as fun as possible. So I think we succeeded.
When I came back to JK and asked him for a third time: We’ve been running this community for seven years already. What’s the goal?’, he said: ‘Oh my God, stop asking me’. I really think that sharing knowledge and giving back to the community is in our DNA. This is who we are in the engineering department, and this is why we have been doing it for seven years already. Now when I formulate it for myself, and you can totally read it with me because it’s quite aligned, I say that we share the knowledge that we have an engineering department with the developer audience to communicate our tech projects, approaches to software development, and highlight our people, our engineers, so potential new joiners would know us before they got the call from the recruiter or they see the job ad. For a lot of people who join our department, we are the first point of contact.
Before I jump to the tools that we are using and briefly describe the approach, I want to make a note that all the value we bring, we bring through the engineering department. We sit in the engineering department and we report to the CTO. We have a head of the community and two chapters. DevRel is more like a developer content chapter, and we have option support who support us at all kinds of different events. We have amazing merge because of them. We have good tooling. And our team, thank you guys, I will mention you one more time during the talk. But yeah, the engineering department is an amazing place to see it by the way, for a content chapter, because you are one of them, you are close to developers and you can easily feel the engineering culture. You can be part of stand-ups if it’s needed.
You can shadow them during on-calls to field the engineering culture. And it’s easier for us as a lot of our job revolves around mentoring developers on submitting their CFPs, teaching them how to behave on stage, and be successful presenters and community minded professionals. So it’s really good in engineering to be close to the developers. And you can ask all kinds of stupid questions, they will answer, but how can we make it work? We have more than 500 engineers in the engineering department. We have seven locations that we want to focus on and counting, because we are constantly researching for new sites to open kiwi.com offices. Our tech stack is quite diverse. We want to talk about a lot of stuff.
We are definitely prioritising, but still. We have quite a small community team to run this internal community. At this point, I need to address the hat.
We consider the role of ambassador of our engineering department as a part-time volunteer role that can be taken and passed among the citizens of the engineering department. Wearing the hat means you take extra responsibilities on top of your job to give back to the community. And we have a team in the engineering department that will help you to be successful. We will help you with CFPs, with writing abstracts, with reviewing abstracts, writing most likely will be done by yourself. I will mention that a little bit later. So it’s a responsibility to give back to the community. So I now have the hat and I’m presenting today on what is happening in our engineering department voluntarily. Don’t get me wrong, we don’t need to wear this hat every time we are presenting outside of Kiwi. It’s just today I decided to wear it to describe the concept.
So how can we make it work? I have one rule that I apply to developer created content, and it may be very obvious to you, but I saw some companies that are doing it differently, that’s why I want to mention it. When we are creating and searching for content, I have this rule – work internally or search internally and then shine externally. What does it mean? To outreach to the external community you need developer created content. And I believe if you throw all kinds of opportunities on your desks to be visible, they will not appreciate it because this is not their job. They are here to solve complex problems. They’re here to write code. They’re not here to be ambassadors or speakers or writers. So I believe if you search for the right content inside, it’ll be so, so much more beneficial.
Why? First of all, you think strategically about your tech brand. You talk to your CTO, VPs and directors to understand what you would like to communicate about your tech stack and your engineering culture. With engineering leads, you would talk about who would be the best person in the engineering department to communicate that. And, yeah, your community will appreciate that as they will feel that you care about their success. You put their success first and you do not care only about the numbers of subscriptions to your newsletter, or the number of people who participated in the challenge that you ran during the conference at your company stand. So you put their success first as speakers and writers. And you avoid stress. You don’t want your community to prepare their abstract one week before the CFP closes, although it does happen.
Right now, we are writing our abstracts to apply for PyCon US. So if you haven’t applied yet, it’s time. But yeah, it’s better to have the content before and we have it, we are just trying to make it better before submitting. So in the end, I believe it’ll help you to create better developer content. You will be more prepared for public visibility. Okay, so you talk to your leadership and you have their support. They give you the suggestions on what you need to focus on technology wise and location wise. Where should you search for the content? They will not give you all the answers. At this point I suggest looking at what you have inside of the engineering department. How you communicate between teams, tribes, organisations. I usually spy on all Dev meetings. We have monthly organisation specific or tribe specific architecture reviews. We have guilds in our company – Reliability Guild, Community Guild, Tech Excellence Challenge and Technology Geek Clubs. We have tech, speakers club and Engineering Lightning talks where Devs can practice before they go publicly. So these help the community manager, who is in searching for the content to communicate outside. By the way, sometimes you are working on a topic with your developer and you will see that not everyone knows about it in the company. So we can actually put on the hat and fill in this gap and ask your developer to present it at the next meeting of all Devs. In this way, you let information flow freely in the engineering department.
I will not describe how you should find the proper format to communicate this content, or how to find the right conference or meet up, or where to publish your information, because it’s a huge topic and I’m more focused on other stuff today. I believe that in parallel there is the important process of supporting your community when wearing the hat. And here our community team works as a help desk for community members. We are here for you to help you before, during, and after your community initiative. We never write content for our developers. We just review and help them with the content that they create themselves. We review their bios and abstracts. We run internal and external feedbacks. They get the feedback internally and externally from friendly developers in other companies.
We help by organising dry runs to help our developers be more successful while presenting. Our writers get proofreading support and content feedback during the community initiative. All kinds of onsite support may be necessary, from information about the venue and timing, to stress relief practises. As we heard today, I usually do breathing exercises before a talk, and chocolate works too. Afterwards, we usually gather content feedback because we want to know if the content was successful and we need to communicate that to our hat wearer. We also write community feedback. We need to understand if your community was successful enough to keep contributing.
I would like to say something that is probably obvious. Don’t forget to reward your community. They work on top of their daily jobs, extra hours, writing their abstracts and rewriting them after getting feedback. Although being part of the community is an amazing thing, it’s still a job on top of your job, so you need to reward people in a way that works in your community. We also run appreciation events for our community. For example, we go to Budapest on our community project and we have a Hungarian Spa together, while talking about ideas for community projects.
The measurements. Well, the tough part, right? How do you measure a tech brand’s internal community? It’s extremely tough and you can look at so many things – the number of female subscriptions, your social media stats. But let me describe what is important for us. When measuring, we usually look at two things – awareness and community happiness.
When measuring awareness, we have a survey for anybody who joins the engineering department of kiwi.com, asking if they have ever come across anything that we use as tools in our community. Perhaps they saw one of our speakers, maybe they read our article, maybe they read our blog post, maybe they saw our booth at the conference, maybe they chatted to our developer on LinkedIn after they published something. So we check the touchpoints, what worked for us, and we also try to connect community and recruitment somehow. If those things that you saw that we did influenced your will to join our company, influenced your will to join the engineering department. And an equally important thing is community happiness. You need to somehow be sure that your developers were successful enough to keep doing that.
With community happiness, we ask how happy they were with the support we provided for them, and how their experience was with the community community initiatives, if they were happy enough. We actually ask our developers if they are ready to suggest the experience to their peers. And I also ask them if they can give me the names of those peers as I need to constantly involve new developers in our community. And I also look at the ‘stickiness’ of the community, asking our community members if they’re willing to join the next community project within the next six months, because I need contributors to keep contributing, right? So in 2022, our community members were visible more than 120 times in more than 10 locations, and 94% are ready to stay in the community to contribute in 2023. That means we will see more community champions talking about the engineering department and kiwi.com, and it’s totally time to pass the hat. Would anyone like to wear it? Thank you.
Find more videos from DevRelCon Prague 2022 and other DevRelCon conferences here!
