Building developer communities in Russia

Transcript

Speaker 1: Hi, everyone. Just before I start, I, want to make a small disclaimer that this talk is really two years work for my developer team and me as a developer relation manager. And I try hard to put there everything that I know to share all the story with you that they can help you to build your communities and to work more efficient and to bring people bring developers more, nice experience with with the product. But there is lots of things that I forgot and that didn't fit in the slides in twenty minutes. So if you want to grab me some time after this talk, I would be happy to talk about everything.

Speaker 1: That's me. I come from Kazakhstan originally, and I spent the last, five years working in Moscow for Yandex. I started as a event manager and spent two years working and was lots of developer technology events for Yandex. And then I moved to open source technology team, infrastructure team in Yandex to do developer relations and technology marketing. And, last year, I moved to Amsterdam to work for Bright Computing who builds software for, HPC clusters, Big Data clusters, OpenStack clouds, and do technology marketing there.

Speaker 1: And this is, as I said, will be our if somebody knows BEM as a methodology and a set of lots of different tools for front end. This is the BEM journey for two years with the communication that I would like to share you, with you. And it's not just about Russia, but it's about the Russian Russian speaking countries. So it's Ukraine, Kazakhstan, Belarus, and and the rest of ex ex Soviet block, basically. So what's BAM?

Speaker 1: BAM is a methodology that helps you build websites, huge websites with a lot of code, helps helps you build them faster and also to support them over a long period of time where a lot of developers come to your team and then leave your team, you need to explain them how to the code is written and keep with all the documentation. But it also a lot of huge toolbox with a lot of building tools and a lot more, and the platform with a set of libraries, components libraries, template in engine, and lots of different stuff, and the community behind it. And maybe you recognize somebody from GitHub avatars. And it's all open sourced, created by Yandex, supported by the community, developed by the community. And in 2015, a year ago, it was a team about of about 30 developers and one developer relation person marketing, and it's me.

Speaker 1: And this is a little BAM history. I'm sure that if there is developers here, they recognize this kind of slide. And there is a lot of pain of supporting the legacy code with a loss of dependencies, so no no option of reuse, very easy easier. And then at the end, you are not sure if something breaks or not. And it for most reason most cases, it will break.

Speaker 1: So and here is BEM, which stands for block element and modifier. And we think that it's a cure for everything. And, the idea is simple, that, every interface on the website, you can cut into pieces into blocks. And then, there is certain blocks that are made of elements, And then different blocks behave differently, and this we can write as modifiers. And this is a nice example that you can understand not to write in a single BAM code and just sitting and watching the slides, and this is also something that is understandable right away.

Speaker 1: So the idea is to write semantic code that everyone will understand if they join your team and they just look at the code. And then to encapsulate the logic of every block and every element on block element level so you can support the small pieces. And it doesn't matter how huge your website will be, then it's easier to support this stuff. But the most used idea of BAM is methodology. But as you saw before, that BAM is not only about CSS.

Speaker 1: It's a lot of things and also the community. And you can take one of the pieces or you can take all of them. They're comp compatible with lots of external, not Yandex written frameworks or component libraries and so on. So and this story is kind of obvious today because for the last, I don't know, four or five years, everything was about the component approach to build everything, break it down into small little pieces, and make libraries out of it. But this story that I was telling you is ten years old.

Speaker 1: So it was back we are back in 2006 where nothing was around. There is no CSS methodologies on the market. There is no block libraries, templating engines, nothing. But Yandex was, at that time, already a huge company with lots of services like search, mail, maps, and so on. That all all of these services had similar interface that should be the design should be consistent.

Speaker 1: And a lot of service teams that supported this interface pieces separately. And there is no no way of these teams to reuse their own code. So most of the team were writing the same stuff all over again, and they had no idea how to share this. So that's why and when the BEM was created. And BEM proved to be very nice and sustainable thing that is in life of developers.

Speaker 1: And then three years later in 2009, the team suddenly decided that it's a great idea. Let's share it with the developers because we need to share something that we do which is nice and will help them. And so the team started to go, to different events and talk about them and share some ideas and and stuff. And they got a lot of attraction from the community and a lot of requests for like fixing bugs, feature requests, and so on. So And at the same time, Yandex also grew, and it grew in number of services and number of teams.

Speaker 1: But the BAM team didn't grow in how many people there were at that time, and they didn't grow in how how much code they can write physically. So there was All of a sudden, everything became scary because, there was a lot of pressure from inside the company to deliver, high quality tested product and a lot of pressure from outside the company saying, like, why you're, starting to evangelize in for BAM if you cannot answer all the feature requests that we are sending to you. And, it was, a lot of, miscommunication and a lot of teams inside Yandex started because they couldn't rely on the infrastructure team, and they couldn't get their release plans in one roadmap together with infrastructure team release, and they were dependent on this BAM. They started to develop their own Nana BAM libraries inside Yandex. And it was frustrating inside the company, but it was also frustrating outside the company.

Speaker 1: Because, imagine if you go to a conference and there is few, teams from Yandex and they are sharing, different stories. And one team says that there is a problem, and we solve it with our written open source stuff. And another team says that there is the same problem, and we solve it some some somehow else. And then the people sitting in the auditorium, they're saying like, you work you work in one company. Why you don't agree with each other and don't present us like the one instrument or something?

Speaker 1: So it was a lot of challenge for us. And the first challenge was external that we have to fix. We have to build the community that will be learning by themselves. They will be teaching themselves so we can hire from this community because we were still a small team and we couldn't, you know, cope with with lots of developers outside. So and we needed this community to help us to develop and also to help us to test the product and also to fill the gaps in the pieces that they were asking us to develop instead of owning these pieces and develop together with us locally and globally.

Speaker 1: And this was the perfect picture that we had in mind to go to. And, internally, we want, we needed to build the infrastructure solutions for the services because we were infrastructure team, and we basically were paid by Yandex to deliver high quality infrastructure. And we needed to win back the client base because in Yandex, there is nothing like techno fascism or something. You cannot bring from top to down the technology and say like, this is the only choice you need to use. So we, as an infrastructure team, needed to, you know, evangelize inside the company and prove that we are the best solution available on the market so they actually use us and be transparent and grow internally evangelists that will help us on external picture.

Speaker 1: And this is the picture that we needed to go inside Yandex. So we needed to as an infrastructure team, we needed to fill this level two and level level one to build the the functionality level and then to to to work together with the design team. So the design team will deliver the new design. We put it into our block libraries and ship ship to services. And then services will build some service specific blocks and features on top of this design.

Speaker 1: And the whole process of developing services will speed up. And nobody will be doing the same work all over again. And then this is will be the build result. So and then we defined what kind of ecosystem we needed to build, And we needed to build a self sufficient environment where all the processes work by themselves, and the benefits is obvious to those who work together with us in the community. And also that the community life is not dependent on evangelists or creators of BAM, so that the community will function even somebody leaves the community.

Speaker 1: And inside Yandex, we were called Lego team. So this is kind of attitude we need to adopt, you know, to make the communication, client oriented and service oriented and tolerate all the critics. And we had, two years, to make it. So we actually built the the whole strategy and then defended it in front of the top of the department, and the department agreed. And then we got two years to to to make this strategy.

Speaker 1: So we plan it like this. The first year, we will concentrate on external, and then the second year, while external dimension is built, we will be doing the internal dimension because external dimension had a lot of things in in itself that will that that helped us actually inside the Yandex. Let's say, we were working hard on documentation, and because it's the same product outside and inside, documentation helps, these two parts of the community. And, we needed to define ourselves in order to know how, who who will be the users of our who will be our community. And that were us, the core product team, and also Yandex service team is the users of of the of the product.

Speaker 1: But sometimes they build, their own side projects in free time, so they are, like, community. And also developers outside Yandex who use our technology to build something, but they also build instruments to work with the technology, and they build something else. And, the market in Russian speaking countries was also interesting, and it's still interesting. Uh-huh. So there is no developer success story.

Speaker 1: There is no huge open source kind of stuff. And, so the there is, like, nobody to learn the local market stories from, so we needed to test everything, every step, and go from the results that we we get and then make the next step. And there is a lot of technology events happening, but most of them supported by the big companies to fill the awareness and hiring kind of goals for them. And there is also an attitude that only something that had proven to be successful in the West could be trusted. So there is a lot of, like, Russian speaking folks who participate in, global development, like, I don't know, building React and all this kind of trendy stuff.

Speaker 1: But, they are not investing a lot in local stuff. So we needed to prove that BAM is really working and to prove it with local, with global community. And then to bring these results to show the local community that we are trusted there. And there is a lot of western folks who use us, who write about us, and so that the local start will be moving faster. And this was on my to do list for external things.

Speaker 1: We needed to start analyzing who our community was because we had no idea who these folks are. We before that, we were going just on external events and we had no idea about registration, who was on the auditorium listening to us from which companies these people were. So we needed to do all the research about the actual community. And to do to cope with everything, we needed to lower quant quantity of what we do and then to concentrate better on quality, and to measure one thing at a time, and then to make next step, which will be based on the result that we are getting from the previous kind of things. And then we wanted to move from theory because before that we were just showing PowerPoint slides and talking about some concepts.

Speaker 1: And we needed to move to practical stuff because at the end we wanted the community to build on their own and to get high skilled folks to hire from. And we didn't want to educate them inside the company because it's costly. And then we needed to move online as much as possible because Russia is huge and Belarus, Ukraine, and all these countries. We possibly couldn't visit every city to talk with our folks, so we needed to move as much as possible online, make the website work in documentation and everything. Oh my god.

Speaker 1: Five minutes. And then build infrastructure and set the rules for the community so that the community will feel themselves, free inside of our development process, and they can actually own things. And then internally, we need to deliver stable product, and we needed to build only what's needed and not something that our development team is interested in, and then to make a transparent communication and engage internally. And as I as I said, we did a lot of surveys and a lot of discoveries and internal audit that contains the that gave us an information about the cost per developer, which actually allowed us to build the hiring from the community kind of program. We find out that we are hiring a lot of JavaScript high skilled folks, but then we needed to educate them inside the company to use them.

Speaker 1: And the only person available to do this education is actually team lead. And team lead's time costs a lot. So that's why we needed to move it outside the company, motivate folks that they learn themselves and then hire. And then, infrastructure and communication. We reversed everything that we had for our website.

Speaker 1: It made the redesign and, the new website, can give you a feeling right away that it's community based website. It has a lot of events and blogs and community development with all the repositories published and developed by the folks inside the community and also external contributors, not only people from Yandex. And we had a forum with around 40 questions published per month. And most of these questions are answered by the community before, our team gets to the forum when they have free time, which is nice because it helped us a lot to build frequently asked questions and answer, piece out of this forum. And then we reversed the plan for the events.

Speaker 1: We moved from external conferences to our own meetups because we needed to see folks in in face and know, from which companies they are, what problems they face. And then we moved from, theory slides to live coding sessions where we were showing how to use our product. And then we moved to webinars and recorded some lessons. And then even further from live coding sessions to hackathons. And the next step was to create a hackathon where the external folks can sign an NDA agreement and then to develop pieces of Yandex, which for them was very interesting to get to the big company to develop something together with with with the team.

Speaker 1: But for us, it was kind of job interview already. So And then we also worked together with evangelists from the community and actually sent to the external conferences, somebody working for non Yandex companies so they can share their story. And that stories were even more powerful than us talking about our product with our clear benefits and and and so on. So and this is the internal dimension. So we focused on the product and the communication.

Speaker 1: And inside, we had a lot of internal events. We shared a lot of success stories, basically the same that we did for external part, and it worked very well. And here is the lessons learned. I probably skipped few few slides. We got lots of folks.

Speaker 1: We got their attention to methodology, which was the easiest part. And we started to communicate with them, and we published their story on English part of our website, and then keep this buzz going on and try to talk to them about the rest of the instrument that we have. And we got more and more names from the community and also more and more companies into our portfolio and more folks coming to our meetups. But the most important was that the the inner community grows stronger and stronger because they saw that the impact is outside is growing, and they, yeah, can help be a part of this. And step by step, we restored the reputation and start being positive instead of, lots of critics.

Speaker 1: And this is the few lessons learned. First, is when you try to promote your instrument or service, and most of the technology instruments, they're global. They have global audience that is use that use your services instrument, it doesn't matter which language you speak. So if you aim globally first and use English as a first language, then most of the local benefits you can get from the community and motivate community to translate it into your local language. And then you save some time.

Speaker 1: And also, try to find something that is valued in your community and try to be trendy because it can win trust and attention from your folks. For us, front end is very fashionable environment. For us, it was going West and showing back to the East that we got a lot of attention. So we somehow became trendy. And then there was a lot of talks about engagement.

Speaker 1: And I think that engagement can win you loyalty and long lasting results. But to win a lot of engagement from your community, you need to build trust with them. So be transparent. Share, roadmaps and plans and ask the opinion from the community, and, set up the rules, and then give them something to own. And when they own something, they will be really engaged because they will feel that they they are truly part of the community.

Speaker 1: It doesn't matter in which company they work, but they are part of the development team. And the infrastructure matters if you go to the office for a new company, and if the company offers you MacBook, let's say. It doesn't bring more revenue to the company, but it will certainly win love of some developers and, I don't know, marketing person. And it's the same if you build some kind of community instruments or open new channel for your folks to communicate with each other. It's worth asking them how they want this channel to work and how they want this website to be built because it should be the instrument that they are comfortable with working.

Speaker 1: So and developer relation is something that is that combine itself, marketing and sales and hiring, reputation, brand awareness for the company, everything. And it it's certainly something that is way more, than than a small industry niche industry. It can cover lots of stuff. And, sometimes it help you to last. It it can last longer, when even if you cut cut back on on marketing, if it's done properly.

Speaker 1: And then but it's needs a lot of time to to build proper communication. For our team, it took seven years to nearly ruin everything, and then two years to restructure everything and and build everything. And when I left a year ago, Yandex, the comp my team decided to stay on their own with with the marketing because we had all the guidelines and all the plans in in plan. And I was constantly constantly talking to them how I do this. And it's now one year and a half that they work without marketing, and they are doing fine.

Speaker 1: So you can check it on the website and the repository, and this is the guy who keeps, the technology going. Some of my contacts and also link to the presentation. Thank you so much.