Transcripts
What I'm going to talk about today- well, while preparing to the talk, I found this nice quote from Rosabeth Moss Kanter, a professor of Harvard Business School, who says that, "Change is disturbing when done to us, but exhilarating when it's done by us." I think that quote really represents the theme, the topic of what I'm going to talk about, and actually that's related to the growth.
This talk is called "Optimizing You," but I would like to go one step above: how you can help other people optimize themselves, how can you build a community, or how can you help other people to grow? And that starts with the overview of how the growth career path can look like at the organization. Booking.com looks like this. If you're a core contributor, you can either select to go to the management path as a team leader, as a manager, and as a director, and so on, so forth, or you could go to the senior development and then principal development.
In this talk we're going to focus on that shift from core contributor to senior. Harry did a nice survey here, about who you are, and do you have more career levels? But the question I have, do you think that the core contributor to senior is a straight line? Who thinks it's like this? Like you need to do something, you need to go there. Who think that it's something like that? At Booking we are good in defining what career levels are. So we have expectations of the core contributor role, we have expectations written for the senior, we have expectations written for the management. It's all good. It's all written; you can read, maybe cross out some of the check boxes and say, "Okay, I'm kind of ready."
Being Senior Means …
In fact, it's not that easy, it's not that simple, and it is still that tangled as in the picture. And the reason is that senior is not a promotion; basically it's a recognition of your work. At booking.com it works like this. You start doing things which are not expected from you, you start acting as a senior developer, and then you get a promotion as a result of your actions. And being senior means that you have to have more impact, you have to have more ownership, responsibility. You need to work on not only your team project; you should go beyond, you should go and influence, to track the department, the company maybe sometimes. You need to mentor people, you need to coach them, you need to be involved in the community projects. All those kind of things which are not clearly defined what you need to do. Yes. If the document says, "Hey, you need to mentor," or the document says, "Hey, you need to influence the other departments," what exactly do you do? Go figure.
So the thing is that senior is not only skills and knowledge. It's basically a behavior. And the thing is that behavior, you cannot teach behavior. Of course, you can go on the training, like, classroom training for a day or two and listen to the teacher, and you can obtain skills and knowledge. But I can hardly mention this that after visiting one day of the training, you will start behaving differently. Unfortunately, you will not, most likely. But you can create an environment where behavior will show up. You can create something where people who would like to grow will get this opportunity to grow. And this is what I'm going to talk about.
Basically this idea came to me and another guy, Denis Yakunin, who is also a senior software developer at booking.com. Idea came to us just during having coffee. We met each other at the cafeteria and we're sitting, and we're chatting, and we're talking about, "Being senior developers we are supposed to help people to grow. So how can we help them? " Because we clearly notice that there is a lack of clarity of how to become a senior. And then Denis just mentioned that he was part of the Facebook group, online Facebook group to help people grow, self-develop and think on some sort of life thinking. And then he described it to me and told me what it was about.
And we thought that we could apply the same principles to actually create the career growth framework, career growth training for our developers. And the three key principles of that work was this. First it has to be marathon: two weeks of 10 days, 10 working days, every day we submit a new task. We'll give the new task to our people, so that they can keep having the momentum going during those two weeks. The goal of it is to create a habit of doing things which they were not supposed to do before. The second part is working in groups, because working together, learning together is actually much more efficient than learning individually. And the third, it should be online, because we do not want to disturb people from their daily routines, we don't want to put them in the class. We want to give them a task and let to finish it whenever they want, being like, asynchronous as possible.
Game of Roles
And we came up with a cool name, because who likes "Game of Thrones"? Everybody likes "Game of Thrones" and we came up with Game of Roles, because Game of Roles is actually the opportunity for you to try and play the different role; the role of a senior developer for a while with no obligations, nothing like that. And the slogan we had is, "Being a senior means playing the role, and to become a senior, you have to try playing this." So what do we wanted to do, we wanted to create for you the safe environment that you could start acting as a senior developer with our help, of course. But then with no obligations to fail, with no obligations to becoming a senior or not becoming a senior, with no kind of risk.
So when you sit up and you think, what do you do? At Booking we do experiments a lot and me and Denis also decided to have an experiment. We wanted to start really low and fail fast in order to collect feedback and get better. So we came up with an MVP of the training, the quick prototype. We wanted to pilot with a limited amount of people, we wanted to collect feedback from them and then reiterate. If you look at the timeline of how things happened, day one, we met together and had this idea born. Day five, we started discussing details and thinking how can we actually do this. Day 10, we made the public online announcement. We committed ourselves that we're going to deliver this training, because without committing, you will never do anything. And then a couple days later, we made the final polishing of the things, and in two weeks from when the original idea was born, we started the training. Essentially two weeks of preparation, two weeks of the real training. In a month span, we could create a completely new thing which never existed at booking.com before, which I think was really, really awesome and which represents the agile way of making things live no matter whatever you do.
Format
So let's talk about what it is exactly. As I said, the format, it's marathon, online, it should have some rules. And I said marathon, 10 days over two weeks, every day we were going to post new assignments to our people, so that they could do this on their own pace on the online activity at Facebook at work. We have to create some rules; what do we expect from them, and what they can do, what they should not do. And of course, the code of conduct. The code of conduct is, yes, it's usual; it has to be you. We wanted to create a trust environment with privacy being safe, safety, group, and be open to receive feedback. So basically when we proclaim this, we'd say, "These are things we are restricting you to." And by saying this, we say, "You are our group that we trust, and we create a safe environment for you." So there is no manager in the group, there is no HR in this group. You are on your own. You are learning. We will not share your information out there anywhere else, so that people could come up with answers, with their sincere answers. And you get the idea why we need them being sincere, because the questions are not only practical tasks, but something more.
So going further about the format, about the thing, it has to be groups. As I already said, if you learn individually, you can only learn from your past experience. Of course, you have some sort of things you know, things you value, things you heard about, and while getting new things, you of course, settled them on your own background, on your own experience, and you can learn only from yourself.
But whenever you learn as a group and whenever you help each other as a group to learn, this becomes the next level of learning. Because if you, for example, look at how that person did an answer, did a problem, you might wonder, "Why did this person did it that way?" You can ask, "Hey, John or Mary, why?" And then she or he replies to you and then you can reflect on that as well. And then he or she can also learn from you, why did you solve it that way. So together with talking to each other, with community activities, you can learn even more.
And the groups have to be small. Since it's online format, it's a Facebook group, imagine that people are posting their answers online everyday. So the more people you get, the more mess you have. So we decided to limit our groups only to 15 people each, assuming that half of them will not do anything, which is unfortunately true. If we assume that 15 people, half of them, say 8, will start doing something, then it'll be easy for us to manage and easier for them to navigate through those answers. And those groups have to be really close. As I said, there is no manager, there is no HR, there are only people who are at the training, who are learning in this moment, and us, like, trainers and moderators. And by this, we allow them to post whatever they feel, whatever they think, and be open to each other.
Funny fact actually, because we had 15 people in the first group. When we were launching this training, we were thinking, "Okay, how many people should we get? Like 15. All right." And we were really doubtful about can we get 15 people out there, because it's a new thing, people might not be really enthusiastic. However, when we did our first announcement on a company meeting saying, "Okay. We're going to launch this. There is a link you can sign in," we got 80 people; 80 people willing to sign in for this training. So it was so, so, so unpredictable to us and so exciting. We were so excited. So we created actually two groups of 15 people each. So we started with bigger pilot group of 30 people, so that we could also compare them between each other.
Tasks
Now, moving forward towards tasks, and I think that's the most important thing, what tasks did we ask them. Well, first of all, they have to be clear. You have to say, "This is what you need to do. This is what the outcome should look like." For example, "You need to go to the errors and warnings monitor and pick one of the errors and warnings, and fix it". They have to be simple. As I said we are not the kind of classical training. We are not the classroom. We don't have well defined time of the training. So we wanted them to be able to complete those tasks on their own pace, assuming that they are also going to work on a day-by-day job. So we said, "You will probably need one hour of your time to complete everyday's tasks." So that's small.
It has to be relevant. They have to be clearly representing what senior developer job is about. So basically, it's actually the reason of why you are in this training. We are simulating things for you. Usually, senior developers do this, so you can also try to do this and so on, so forth. And the solution has to be a separate post in the workplace. So each person at the end of the day needs to create a separate text post on Facebook where they describe how did they approach the solution, how did they solve it, and maybe share some results, etc. The reason for this that people will see this in their workplace ... How do you call it? Flow. And then they could comment on this. They could provide feedback on that, they can also, I don't know, just have written, get the record of what people are answering.
And there are two different types of tasks we were offering them. First is a pretty straightforward one: testing hard skill, excelling in hard skills. As I said, fix some errors and warnings, describe and draw a diagram of your service or product. These are the tasks which are heavily focused on the impact and hard skills, and technical, and craftsmanship things, so what senior developers should do.
But these are not the most important ones. The most important ones, in my opinion, are self-reflection. How many of you, whenever you want to do something, really spend time on self-reflection and understand where you are at the moment? Do you ever do this? Few hands. So people naturally, when they want to grow, when they want to get a promotion, they really start thinking about where they are at this moment, why they are not getting a promotion, or what they need to do become a senior, for example. So by the self-reflecting tasks, we wanted to make people, explicitly make people to think about their own reality. The very first question we were asking them, "Hey, go to the senior developer expectations Wiki page. Go through all of the check boxes which are defined there and try to answer where you are matching and where you do not match and why." So that was the very first task, and people did not expect this. People expected to do some sort of error fixing, community project, all sort of that. That was a surprise to them, but that was the most key thing in their progression; to actually self-reflect.
This is how it looks like in the workplace feed, both about the task which was submitted in the day of the task. This is a sample of an answer. The person describes which error they picked on the monitor, how did they approach it, how did they solve it, what was the reason, what are the next following steps. This is really a nice already thought process; not only just fixing things, but also going, producing the learning, producing the, let's say, knowledge sharing document, whatever. And then it basically impacts their way of thinking, that not only fixing is good, but also making the documentation of it or making sure that people learn from this fix is important.
Moderators
To help with this training, we also invited people as mentors, or moderators. Those are also experienced people; they were all senior developers and one principal developer who helped us during the process. And their responsibility was to actually coach people. So not only coach and support, but the most important thing was coaching. An example of the coaching was asking more questions. If the person answers and most importantly on the self-reflection topic, for example, there was a question we ask, "Hey, what do you like or what do you don't like in your daily job?" And the person just answered for example, "I don't like being confused about what I'm supposed to work on. I don't like not knowing what I'm working on is going to accomplish. I don't like meetings. I don't like complicating." And so on, and so forth. That's an answer, but that's not the full answer. That's just a statement, "I don't like doing this."
And then the moderator comes in, the coach comes in saying, "Hey, those things you mentioned, you're trying to avoid uncertainty. What could you do to make it more clear for itself?” And then the person answers more deeply and then we ask one more question, and then the person answers again. And since no one expects us to coach them, they were really open to this. Because usually when you say, "Hey, I'm going to coach you," you start to like, "I don't really like being coached." Special developers, they're like, "You know, I'm good. Don't bother me with your five why questions or something." But when you do it naturally, while you do it with just commenting on workplace, they don't expect this kind of trick from you and they start being open, and they start to think more about what they need to achieve.
Another example from the coaching was that you don't have to read the answer, but just the amount of text the person has written to the question, to the additional question, not to the topic itself, is remarkable. It's again one more proof that people start becoming more open and becoming more thoughtful about what they are doing.
And the last part was the feedback and AMA. As I said, we want to learn fast, we want to fail fast. So the very last meeting we had with them after two weeks of training was the AMA session where we answered their questions, like, how did we become seniors, what did we do, what is our personal story? But most importantly, we were trying to collect their feedback regarding the training: what did they like, what didn't they like, what could we improve?
What Did We Learn?
So what actually did we learn? Lesson first, we have to meet in real life before the training starts. Even though it's online, even though it's proclaimed as being totally online, we wanted people to actually gather in one single room before the whole two weeks marathon starts. It makes people more open to each other when they know who they are. Whenever you put people in a group, if I can see your face, if I can understand that you are the person you are, then whenever I pull something on Facebook, I know that you are a nice person to me. At least I know you, then it gets more connected.
Second lesson is keeping the work-life balance. In the first run we were posting the questions on the evening of the day before the question, the topic has to be answered. So 7:00 p.m., I was posting the question and I noticed that 7:05 or 7:10, people start answering on this topic. I was like, ''Come on, guys. You are not supposed to work after 7:00 p.m. You are not supposed to work when you are supposed to be at the bar or with your family." So we changed that to post topics in the morning of the same day. And In order to be easier for us, we automated this with Facebook. You can make a schedule post, so we don't have to bother and wake up early to submit the topic which people are expecting to have.
Second lesson, that's one of the most important things we've learned, that we need to give people some time to rest. What we noticed, that you get the first task, you finish it pretty good. Next day, you get the second task. The third day, you get the third one. The fourth, you get the fourth. And it’s a snowball if you, for example, need to answer on the day three, you get a new task on day four, and now you become anxious about, "Hey, I didn't finish the previous one, I get the new one." Now, day five comes, he didn't finish two days and now, you get more and more and like a snowball, you start thinking, "Okay, I didn't do something there. I wouldn't even bother reading the next question."
So actually, before we introduce the catch-up days, the response rate was like this. Those are how many people completed how many tasks, and we see that after, say day four, there's a huge drop down in completion because people start getting overwhelmed. So what we did, we said, "First Friday, the day five would be the day of your catching up." We didn't post any new assignment. We just said, "Hey, this is the time for you to catch up on whatever is left and if you've done everything, go and read other people's posts and comment on them. So help your colleagues." And it helped. More people got to the last end of spectrum. More people completed eight tasks which now becomes the full training.
One more thing to improve the statistics is introducing OKRs, or at least something like clearly set the expectations. We got from the feedback, we got that people sometimes were perfectionists and they were thinking, "If I didn't finish one of the tasks, there is no point for me to finish the other ones because I didn't complete anything. I would not complete 100%." So what we did on that, we said explicitly, "Hey, guys. We are not expecting for you to complete everything. We only expect that you'll complete some of those tasks." Let's say you will finish OKR 0.3 if you complete four of the tasks. You will reach 0.7 OKR if you complete, let's say, six tasks. And you will reach 1.0 OKR if you will complete everything and also we'll provide some feedback to your peers.
So what we noticed to go from here, we went to here. This gave people extra motivation to do things. This gave people extra safety of feeling that they are not supposed to complete everything, and by this, they did actually complete more, because they were not under pressure anymore. And there was an example of a person who said, "I wasn't supposed to finish one of the tasks because I felt that this is easy and I usually do this on my own already. But since there is an OKR 1.0 saying that if I complete everything, I will reach this OKR, I decided to complete this task as well. So thanks for introducing that kind of motivating thing." So that worked.
Can We Measure Value?
And then there were lessons five and six, and seven. We collected feedback. We learned, we learned, we learned, we learned. But how can we measure if it was successful or not? How do you know that the training you've been through helped you, and how do you know that this training that you create helps people? Any ideas by the way? How do you by the way measure if the training helped you or not?
Participant 1: Number of promotions.
Mogelashvili: Number of promotions. I have a question to you, how do you know this promotion happened because of that training?
Participant 1: We don't know.
Mogelashvili: Actually, you can't, you can't measure this. Well, in shortened term, of course, you cannot measure the success of any training, because unless this is a training specifically on hard skills, how to work in that particular certain technology, then you can evaluate if the person can do this. If we focus on something which is soft skills, if we focus on something which is behavior, if you want to change people's behavior, you cannot measure this straight away. But you can collect feedback, as I said. And this is the only metric we could use in our evaluation. So we were collecting feedback right after the training finished and we were collecting the feedback two, three months after, so that we could compare what people think immediately and what people think while time passes, while they have settled things, and if they really change their behavior with time.
And then a few feedbacks I would like to share with you that we've received. So this is actually the thing we were aiming for. The person here writes that, "I think the most important insight I got from Game of Roles is that there is no checklist or roadmap to become a senior. It is not about the number of programming languages you know. It is not about of developer tools you can work with. It's more about the way of thinking and solving issues, the way of sharing your knowledge with the community." It is exactly what we were aiming for people to understand that it's that.
The other feedback is that, "I liked the environment we had in a workplace group which made it easy and it also helped a lot to learn about other people." So that's the proof to our assumption that group learning is something which makes you learn even faster, even more. And the third feedback was just remarkable: "It motivated me to do things which I would otherwise postpone forever." While I was reading this, it was, like, so, so, so great a feeling to me, "Yes, we did the right thing. People liked it." And also we got a lot of positive scoring like, NPS or something like that. Would you recommend it to your colleague? How did you value this? And everything was really above 80%, 90%
So in general, so far we have trained 80 people in total, which is around 10% of our development headcount. We have 50 more people in the waiting list for the next month and we got the support from talent development. They promote this as a part of the recommended training if you want to get promoted, all this kind of thing. So it got noticed by somebody whose job was basically to train our developers. We are not trainers, as I want to remember. We were just developers. We were doing this on our own time, on our own enthusiasm.
What’s Next?
So what's next? There was one feedback which actually helped us to figure out what we can do next. "Most of the tasks and questions given seem like they would apply to other senior roles as well, not just backend developers. Any thoughts of opening it to everyone and give people the opportunity to interact with people in other roles?" Hell yes, why not? So we decided to build a kind of so-called franchise. There is a Game of Roles senior developer edition, there is a Game of Roles team leader edition. I hope they will have a senior designer edition. I hope now, we are talking with senior front end developer. The Game of Roles now is somewhat more just a training for developers. It's a framework for helping people grow no matter which role you would like to grow in.
And the good part about it is that the framework itself doesn't change. It's still a marathon, it's still online, it's still group. What changes is just the relevancy of tasks you are going to present. For example, if you want to teach people to become a team leader, then of course, you need to focus more about how to give feedback, how do you manage performance, all those kind of things. We were making more offline activities to them in a group, they were working together, whatever, to train the feedback and something like that. But the key framework didn't change.
What I wanted to end with, I want to repeat again this nice quote, "Change is disturbing when it's done to us, but exhilarating when it's done by us." When you are being told by someone, you think, "This is obligatory. The person teaches me. All right." But you can receive it well, you can receive it not that well. But whenever you teach on your own, with your own peers and colleagues, you start changing and start behaving differently, much faster.
So what I want from you from this talk - I don't want you to implement exactly Game of Roles or I don't want you to do something, like start and change the way you learn. But I want you to not wait for someone to make training for you. If you feel that there is a need in your organization for this sort of activities, if you feel that there is lack of clarity of how to become senior developer, how to get promoted, act on it, change this way. You don't have to be a trainer. You don't have to be a certified whatever, master, blah. You can do it as a developer. You can do it on your spare time Just be proactive. And if set up right, people are able to help themselves. If you make the environment that will help people grow, people will grow. And I think it will be even more beneficial because you are not an authority to them; you’re yet another developer who wants to help yet another developer. So by doing this, you will help yourself grow and you will help other people grow, which is just much better.
How to Create Game of Roles
And that's how you can create the Game of Roles. Find a partner. That's really important that you find somebody who will help you to set it up, because first of all, this person will keep you challenged, this person will keep you motivated, this person will help you not slack off in the middle of this preparation. And of course, it's easier for you to handle all of this, you can distribute the load. Go online. I think it's a much better idea to help people learn on their own pace through the platform they would like to be on, not in the classroom. Also you don't have to have a classroom in your organization, you can go online.
Marathon, that's important. That's really important because if you want to obtain a new habit, you have to do this for 21 days. So by this, by training, spend two weeks or maybe three weeks, you will create the habit for people to actually do something more they are not used to do. Make it as work as group. Find moderators to help you with. Define small practical tasks which are relevant to your organization, to your definition of what senior is. Don't ask people to complete everything. We are not perfectionists. We are there to learn. We are not there to compete to each other. Give them time to rest, give them time to catch-up. And always collect feedback; what do they think you are doing good, and what do you think they can learn more.
That is it. This QR code is linked. There are tasks which we created to our training. So you can just have it as an inspiration, but of course, they probably will not be applicable to your organization, but as a reference. You can connect with me on Facebook, on Twitter, wherever.
Questions and Answers
Moderator: How small of a group you think you could have?
Mogelashvili: I'd say 10. Assuming that half of them will just do nothing. You still want to have some people contributing to the activities. Because if you make a group of five and you say three of them will bail out, then there are only two person. And two persons will not learn much from each other, then you can just set up a meeting with them. So I would say 10 might be an okay number.
Moderator: Five active participants.
Mogelashvili: Yes, something like that. As long as you can have a constant sharing and communication within the group.
Participant 2: Do you think that one person because we're ready for the promotion, but not so many promotions are available? Did you observe that thing also? Everybody is now trained and they're all ready for senior positions.
Mogelashvili: No. Unfortunately. So as I said, we are not training to become seniors. We are giving them opportunity to understand what the role is about, and then it's up to them if they want to continue acting as senior developers or not. So I think out of the statistics, 30% of people got promoted since they first participated in the training. Again, I cannot say if that's related to what we did or just the way they were doing things. You cannot clearly say, "Hey, go to our training and then you'll get promoted." You should never say that because then you will put yourself in a pretty bad station if they didn't get promoted.
What we were saying is just, "Hey, you can go to this training to understand what this role is about and maybe you can understand if it's not for you.'' Because I had a feedback from a person from the team leader training, who said after the training that, you know, "I now understand what team leading is about and I don't want to become a team leader." This is the perfect feedback. This is the perfect scenario. I like this because if the person would become a team lead and understand this after being in a role for a while, it would be much more destructive for them and for his team. So it's better to figure it out early.
Participant 3: I share your enthusiasm for how much you can learn from other people's experience. So it made me wonder, going back to your childhood beginning where you've got these two separate branches of the management in technical careers, do you think there is scope for doing this so that the management branch do a task with the people in the technical branch at the same levels? So you haven't got the hierarchy thing, but so that they can learn about each other's jobs and understand those issues from a different perspective.
Mogelashvili: That's a good suggestion. I didn't think about it. Well, the way we put the training was to actually give you clarity about your future role and we didn't think about that, "Hey, maybe managers would be interested in becoming seniors and the vice versa." I can't answer you right now. I think I will take it as a suggestion, not as a question, if you please, because I don't know how to answer that right now. I need to give it a thought.
Participant 4: So in this framework we've got eight tasks. How much thought do you put into selecting those tasks and into picking the habits or traits you want to train? And can you talk about the process?
Mogelashvili: Yes. As I said in one of the slides, we had only three. I think we had three meetings regarding what do we want to put there. So the first meeting we had, it was only me and Denis. And we were just framing out and drafting what we want them to ask. But later on, we shared this idea with other senior people and with principal developers. At the brainstorm session we had six or seven people in the room, seniors and principals, thinking of what we could ask our people, what would be the most beneficial thing to ask to help them grow. So we were selecting those things and focusing on communication, craftsmanship, what we also call commercial awareness. So those things which we care about while promoting people. So we wanted to cover all of those topics. We focus more on soft skills and hard skills going beyond their responsibility. So we had I think maybe three, four meetings together to kind of brainstorm what we wanted to ask.
Participant 5: When you organize a group, so what kind of member do you think is the most efficient? You have to come with different roles and, you know, you don't have HR, right? So you have architecture, a senior, and a team leader, or something. How do you pick, I think, this kind of member, the most efficient in the group?
Mogelashvili: First come, first serve. So we announced that, “the new training will happen on date X.” So people could just sign in to be there. The only thing we had as a restriction that you have to work at booking.com for a year because we think that during the year, you will just get more knowledge. Sorry. Six months. Anyway, it doesn't matter. We wanted people, not just the fresh starters, but somebody who already spent some time working at Booking to understand how the culture works, how everything works. So we think that it's the right time they can think about their promotion. And then whoever signs in, everybody is welcome. So we didn't handpick people who want to train.
Participant 5: For example, they have at big companies, they have different teams, engineering teams. So different teams probably have different requirements for certain rules. Basically, how do you more efficiently treating your members, like, your club members?
Mogelashvili: No. At Booking we have team leads and senior developers, and all the other roles are defined, so that they can be interchangeable. So there are no senior developer payments. There are no senior development bookings. Every senior developer has the same profile same with the team leader. We don't have to choose between what type of senior or what type of team lead you need to be trained. It's just generic team leader, generic senior developer.
Participant 6: They are all backend developers already? It's not that you mix different technical people with different …
Mogelashvili: No. We started with backend developers because I'm a backend that just understands what that does it mean, but basically we are now talking with front end people because behaviors are mostly the same. It's just maybe some technical things we should change a little bit.
Participant 6: But you don't set task, like, more technical tasks between those eight?
Mogelashvili: When we set technical tasks, we were focused on backend developers. So that's why we didn't mix people together because we could only come up with technical backend tasks, not front end.
Participant 7: How did you choose who your moderators were? Or was it just open to anyone who wanted them?
Mogelashvili: We were begging them. The trick is that, as I said, it's really hard to measure the value of this, and by this, it's really hard to get people onboard because they question, "What's in it for me?" And we say, like, "You will teach people." And they're like, "Why?" "Because it's good." "Can you show me numbers?" "No.” “I'll think about it." So the usually response is, "You are doing great, but I have other things to do." So we were really chasing people to help us with moderating things. We would really lucky in the first round because it was a fresh new thing. People didn't know what to expect, many people jumped onboard. Later on, it's only me now.
See more presentations with transcripts
