Transcript
Mogelashvili: First of all, I want to lower your expectations, because the things I'm going to talk about now are really obvious to me as a team leader, as a senior engineer. However, even though they are and might sound obvious to you. What I would like you to do after you leave the room is, think about my talk. Basically, try to reflect on those things. Understand whether you know that you have those skills, and if you apply them consciously or maybe unconsciously. Go and try to do the self-introspection, do the self-reflection on the topics I'm going to cover.
Booking.com
I'm going to start with a little story. It happened almost six years ago on February 14, 2014, the Saint Valentine's Day, me and my wife got married. It usually happens when people get married they go to the honeymoon trip. We decided to go to New Zealand. I used to live in Moscow back then, and to get there it took me 30 hours to cover 16,000 kilometers, which is around 10,000 miles. To justify this ride, we had to go for the longer vacation. We took three weeks to go through the entire country. You can see the route over there. We had almost 3,500 kilometers of road by car. We had stayed in 15 hotels. In 21 days, 15 hotels, pretty intense. We had to pack and unpack all those things almost every day. Hopefully, we booked all our recommendation, hotels, bed and breakfast, all different lodges, and everything. We booked everything on booking.com.
This is not a commercial. This is not an advertisement of booking.com, even though I work there. However, this story is really related to why I'm standing here on stage, because after we came back from this vacation, I got really excited because our trip was not ruined because of the hotel, or host, or any other property. We haven't been asked to relocate somewhere else. All the pictures matched exactly what were in the website. They matched exactly what was in the property. I got excited not about the trip itself, but also the smoothness of the trip, because of the product booking.com was doing. I thought to myself, "They're doing a great product. I would really like to join them, to work for them." That's where I went, careers websites for booking.com, and I applied for the software developer there. They got me hired. That's where my story ends.
Proactivity
Why was I talking about that? Because it really defined my life into the next five years, and it really defined why I am standing here on stage in front of you right now. Most importantly, the moment I submitted my CV to the careers website, I showed the first skill of the manager, or of the person, which is called proactivity. Let's put it this way, when you are reactive, that means that something happens and you respond to that. Being proactive means that you are doing something ahead of time, that you foresee something which may happen and you first act before that happens. What I mean there is now, imagine you work on a Scrum, you have Sprints, and your Sprint ends on Friday, and today is Wednesday. Let's say you've completed your Sprint. You have no items in the backlog, and you're a developer. What can you do? You can just do nothing. You can watch YouTube. You can watch conference videos. You can read. You can go for a walk. You can drink coffee. That's ok. I don't blame you for that because you were given a task or a set of tasks and you accomplished all of them. That's the contract between your manager and yourself. You've accomplished it successfully.
If we look at this as management people, I'm upset. I cannot blame you because that's how things work. However, what I would like you to do, and I would love this person if they approached me and said, "I've done everything on the backlog, but I have other things to do. For example, I have this idea. I have this new feature in mind. Can I start working on that?" I would literally love this person at the moment because not only do they help me to avoid this emptiness in their backlog, but also they try to move forward the product. They try to bring some added value to that. Of course next time, where there will be a decision between promoting the person 1 or person B, I would of course prefer to promote the person who tried to help me, who was proactive in bringing things to the product.
How Can I Help You?
What do you do if you don't know what those features are, if you can't come up with the feature to work on yourself? Easiest thing to do is come to your manager and ask, "How can I help you?" If you ask them, "I have free time. What's on your plate? What can I take to help you sorted out?" Me, as a manager, I would be really grateful for this conversation because that means that my life becomes easier, and the life of the manager is always hard. If the manager is not hundred percent occupied, they're doing something wrong, or really, maybe something great, but usually does not happen. If you ask them often, how can I help you? That means that you're trying to help them and you're learning some new things on your own, and you're making people around you better.
Commercial Awareness
Imagine we have a feature. You have a feature proposed, but it's not the only requirement you need to have. You need to also have some commercial awareness. You need to understand why this feature should be done. You know about this place on the picture? That's Hobbiton. That's from the movie, "Lord of the Rings," which was filmed in New Zealand. The whole movie set was built on the land of a person. There was a guy who owned the land, and they built it. Why am I showing this picture in relation to commercial awareness? That person did not take much money from the filmmakers when they built it. He didn't take much money to do right for filmmakers to build the set. Instead, he kept all those things, all those artifacts after the movie filming finished. Now it's a huge attraction place for tourists coming to visit New Zealand. This guy makes a huge amount of money just because he was thinking commercially and strategically. He didn't rush up for the immediate revenue, rather for the strategic view and how this is going to bring him more revenue, more money.
Can you please remember a topic or a feature you've already shipped to production, some recent feature you've already shipped to production? How many of you can now tell me, do you know which impact this feature had on your business in relation to metrics like sales, or whatever metric? How many people can tell me, what's the impact of the feature? Much less. How many of you knew what the impact would be before you take in this feature from the backlog? Not much. That's what I'm talking about basically. I usually hear from developers, "I'm hired here to write code. I'm not here for business." That's ok. Yes, you were hired to write code. To make business, there are product managers. There are chief product officers, whatever. However, if we talk about becoming better developers, becoming higher up on the career ladder, you need to think about business. You need to bring on those commercial things as your skill set.
When I joined booking, two, three months after that, I was working in the team which was responsible for the hotel page of the website for tablets. It doesn't matter, hotel page. We were responsible for making this page look better, even though it was an already well-done product. After a while, I noticed that there are rooms in the rooms table which are sorted by price. However, in the photo gallery on the hotel page, pictures were randomized. I thought, "What if we sort out the pictures in that gallery in the same way as rooms are sorted," because people tend to buy cheaper rooms. The hypothesis was, ok, you scroll through the picture gallery, you find the first room there, it's cheaper than others. You click book straight from the gallery, and you are done. You're our customer now.
I discussed this hypothesis with my product manager. She said, "It might be a good idea. The data shows that it may be working. Let's run the experiment. Let's set up a feature." I ran the experiment. After two weeks when I needed to make a decision whether to put this experiment full-on or not, I noticed that, first of all, yes, conversion increased, so people started to book more. However, the commission from those bookings was higher than my entire yearly gross salary, in two weeks. I already brought more money than I would have cost my company to hire me, to bring me to Amsterdam from Moscow, for the full year ahead, in two weeks. That was super impressive. To me, just two, three months in the company that was like, "I can do such things here because I think about what can be better for the customer next." I've implemented other features, successful not successful, but I was always thinking about the customer and thinking more about what else can we do. In the end, it resulted in some bonus to me. Basically, I got some money back from the company.
Talk to Your Product Manager
What if you don't know our business? What do you do? Just talk to your product manager. These are people who work hard to make product better. They understand about metrics. They understand about any other business related topic. Talk to them and ask. Every time you pick up the issue from the backlog, just ask them, "Why am I working on that? What benefit will this feature bring to the customer? What benefit will this feature bring to our business, to our company?" Try to understand data. Try to gather more data, try to come up with new ideas and validate your hypothesis with product managers.
Responsibility
We have a feature. This feature is good from the commercial point of view. What do we do next? Next, comes responsibility. What do you think if I say somebody is responsible? That means usually that generally this person is good. We can rely on them. Whatever task you assign, they will finish and everybody will be happy. There is a slight difference between responsible and responsible for. Those three letters make a difference. Because if I am responsible for my dog, I can be a really shady person, I can be late on stand-ups. I can maybe commit bugs to the repository. I'm not responsible. You cannot call me responsible, but I'm responsible for my dog. I know that here he's fed well. He was walked in the morning, and he's happy in general. Or people from New Zealand, they're responsible for kiwis. Kiwis are tiny, little birds, bigger than this tattoo. They are almost all extinct. There are around 300, 400 species in the whole planet. They all live in New Zealand. People from New Zealand are responsible to make sure that those little creatures can live longer, can survive, and can become a stable species again.
That's what I want you to bring on, being responsible for the things you're proposing. If you have a feature in mind, make sure that this feature will be brought to the end, maybe not entirely by you, by other people. Or if you cannot handle this, find another person who you can delegate this feature to. Or, as a result it couldn't be, "No, we're not going to make this feature." Shut it down. That's also a result. Being responsible for something means that you can take it from the start to the very end.
Back-end Developer to Team Lead
In the beginning of my work at booking.com, I was asked to help one team to do some back-end work for them. Because they didn't have any back-end developers, they actually, in fact, had only one designer, house designer and house product manager to work on the specific product. They asked me to help with some back-end. When I was doing this feature, I realized that the same code was written three different times by three different people in three different places. What could I do? I could either, do nothing, write the fourth implementation of the same thing. Go away, because it's not my team, I don't care. Or, I could flag this issue and say, "This team requires a dedicated developer." Maybe not full-time, but at least a go-to person who will take care of that duplicate of code.
A few weeks passed, and I was approached by the senior manager asking, "Would you like to become that developer?" No, but there's a senior manager asking me to [inaudible 00:15:47] in the company for four months. I couldn't really say no. Even though I was really hesitant, in the end, I said yes. That sounds like an opportunity, even though it's maybe not really that nice to work on the product, which was only managed by two-halves of the people. In the end, that resulted into the fully operational team being formed, me as a back-end developer, front-end developer, designer, copywriter, team leader, and product manager. We got the full team after that. We made this product evolve. Eventually, after a few months, my team leader left to the other team and I became a TL in that team. I got promotion, because of my first being proactive and responsible for the things I'm doing in the company. I carried those skills over time and that granted me the new role as a team lead.
Introduction - Mogelashvili
I joined booking.com in September 2014 as a back-end developer. Half a year later, few months, more than half a year, in June 2015, I became a team leader. Then I went back to an individual contributor because we were experimenting with autonomous teams where we were removing team leaders from teams and forming the teams which are mutually responsible for the whole team's health. I moved to one of those teams out of curiosity. I basically stepped back to become a developer. That's the moment where I start realizing that soft skills matter. Because when you're a developer, you do code mostly, you don't care about all those responsibilities. You may do those things. You may be responsible. You may be proactive. You may know commercial side of things, but you're not really conscious about this. When you become team leader, you're again not really conscious about those things. You start using those skills more often because that's what you do. You work with people. You work with product. You have to be responsible and have to be really proactive on things. Again, you're not really conscious about that. It's your natural way of working.
However, when you step back again to become a developer, now, at least for me, that's where the change happened. I started to think, "The other things, responsibility, commercial awareness, proactivity, I could do these more consciously, while being a developer. I can apply those skills while writing code and do things better than that. I can run communities of developers within the organization. I can do presentations. I can write documentation. I can do more. Because I now understand that this is all possible. This is all applicable to development as well." A few months from that, I became a senior developer. Again, being promoted to senior in half a year at Booking is something which is not really common. It's just visualization of how cautiously applying soft skills can help in your career and you as a person, as an employee. Then I became a TL again. Then I switched to individual contributor again. Now I'm a lead developer. I'm going up and down and trying to find, what's my best way of working? That's why I love Booking. I can do these things without being blamed. I can do this free.
Communication
You have your feature really validated and it's commercially successful. The problem might be that you cannot carry on this yourself, not necessarily, you have to bring on more people on board. If you want to have some front-end changes, you need a developer, front-end developer, or maybe app developer. What you really need to do is talk to them. Your next skill, and it's one of the most important skills ever, is communication. Because whenever you bring up new idea to the people around you, they will probably look like this. They will say, "What are you talking about? Why are we even talking about? That's extra work for me to do. I don't want it. What's in it for me?" You need to explain to them why this is important. Of course, you understand that. It's your feature. It's your baby. You know how valuable it is, but they don't know. That's your key responsibility to basically explain why this is happening.
It's not only important to communicate well. You have to know how to communicate with different people. All those people look similar. However, they are not. They are different personalities. Imagine a situation, you have a developer, and you have a product manager, and you need to bring them an idea, let's say, moving to Kubernetes. Kubernetes is great. Everybody loves Kubernetes. Everybody likes cloud-first approach. You would like to talk to your fellow developer and the product manager about this idea. I think that's going to be obvious if I say that you need to talk to a developer differently from how you talk to the product manager, because developers talk about technology like latency, Easy CI/CD. Product managers care about time to market, business value.
The Social Styles Model
Let's say that we have another product manager moving into your team and you have to explain to them the value of the Kubernetes thing. How many of you think that we can use the same pitch, the same arguments to the other product manager? Almost none. Exactly. Even though they share the same role, they are different people. Different scientists like to classify people on buckets. There is yet another model to classify people on buckets. I don't know the name of the model. I really relate with it. I really like it because it matches my personality and other people's personalities, is what I've noticed.
There are analytical, driver, amiable, and expressive people around. Communication to them is different. For example, if you have a product manager driver, that means that they really like to be detailed, direct, to the point, "Kubernetes will bring you this and this in three months." For driver, that's awesome, because you're clear. You're to the point. You don't waste time on going around the bush.
As opposite, if you go with the same pitch to your amiable product manager, they will just say, "I don't know what you're talking about. Please, let's take a break, let's discuss it later," because they were confronted with the communication style which they are not used to. Amiable people would like to first establish personal connection, "How do you feel? How's your family? Everything's going good? What did you have for lunch?" Then you start, "There is a Kubernetes thing. It can bring you this value. It can bring you this time to market." Yes, you still have to use the same business arguments, but in a different communication way: more relaxed, more interpersonal, more welcoming. Knowing that, at least that model or any other model, knowing that people are different, helps you to bring your idea to its end and to make sure you have people on board.
Feedback
That's all great, but how do you know that you're doing a great job? That's where feedback comes in. Sometimes feedback can be perceived as something negative, because I'm telling you that you did something wrong. When I deal with people who are defensive to feedback, those people who don't like feedback, don't accept feedback, and always tell me, "No. That's wrong. I didn't do this. You got it wrong." I feel I'm talking to the wall. Really, as a manager, I spend so much resources and energy to talk to people who are defensive and trying to make them understand that I am there for their good. I want them to learn. I want them to become better. In the response I get, "No, that's bullshit. No, that never happened." I will try more, but in the end I will even unconsciously maybe be biased against those people because I don't have this connection. I don't think that they're going to learn from their mistakes. If a person doesn't learn from feedback for quite a long time, that's not going to work for the long-term.
Feedback is a good thing in general. Learn how to look for feedback from your colleagues, especially when you're not coding, because when you code, you just write, you ship it to the production. It works. It doesn't fail. That's your feedback. Everything is ok for you as a developer. However, if you start going outside of the tech and go into coordinating other people, working towards bringing feature to production, being more on the soft skills side of things, then you don't get immediate feedback of whether you're doing this right. Look for this feedback. Ask people around you, "How did you do? What can you improve?" Try to get this feedback right. Try to soak it in, and then see, where can you grow?
Importantly, we're talking about management side of things here. For me, as a manager, that's important to understand whether I am doing right or not. Please, you as my employees, as my developers, come to me and tell me the feedback, whether I'm doing good or not. Because sometimes I can implement the process change, which will bring some results in a year from now. During this year, I will be thinking daily, whether I did right or wrong. It's real pressure for me to not know the results, to not know whether what I'm doing is worthy. Maybe I'm not just the right person. Maybe I'm in the wrong place. Maybe I shouldn't be a team lead. I don't know. All those things come up without feedback. Please give feedback often to your managers. To do that, you want to have feedback in a constructive way.
BIO - Behavior, Impact, and Options
For that, there are some models. For example, I really like the BIO model. BIO stands for behavior, impact, and options. First of all, you need to describe what the behavior was. What was the situation like, the context of this behavior? Then you just talk about impact and then you present some options, how you can improve.
As an example, I would like to show two feedbacks. "I think that yesterday your interaction with Maria was not correct." "Your communication style doesn't fit our company. Please think on how you can improve that." Because this is not constructive, because, yes, that maybe happened recently, maybe yesterday, maybe last week, but I have no idea what you are talking about. Yes, interaction with Maria. What exactly? What did I tell you? I actually don't even remember that I was talking to Maria. I will probably ignore the feedback and move on. Later I will get a PIP because I'm not responsive to feedback.
Now let's move in to BIO feedback. "Yesterday, while talking to Maria, he was loudly blaming someone else's code." "This was heard by Jonathan, who wrote that code. Now he feels insecure, and has to re-check every commit three times. That slows down productivity of the team." "In our company, we try not to blame people, especially in public. Could you please next time, share your concerns one-on-one with him? What do you think"?
There's clear behavior, loudly blaming someone else's code. That's the behavior. That's what happened. You probably remember this, because that's something huge. Then you now show about the impact. Jonathan, who is generally a good developer, he was in the company for a long time. He's doing really great. Yes, he made a mistake, and you brought it up. Now he feels insecure. Now he slows down the whole team. That's impact not only on the person but on the company. That's huge. Then they provide you some options. For example, you can talk to them one-on-one. More importantly, I leave some space for other options. What do you think, here? If you present feedback in that way, it's easy. It has nothing different from the feedback I showed earlier like this, but this is toxic like that lake, and this is not. If you learn how to do proper feedback yourself, and if you spread the word about this feedback technique, it's one of many. There are others like COIN, BIO. What's more important is you have to put the person into context first, and then emphasize what this behavior brought to. Then provide some options, and discuss. Doing this feedback and this style will help you bring this feedback more to the person.
Wrap-up
Let's actually wrap up all those six things. We talked about proactivity. Don't wait until something happens, act. Seek for opportunities within the company. There are always few ways or few things you can improve. Work on that, and then try to understand why those things you're going to do matter for the company. What can you improve from the business point of view? What can you improve from the customer point of view? What can you improve from maybe internal point of view? If you build a community for developers, it's also valuable, maybe not commercially valuable, but it's valuable for employees' health and how they perceive the company. They will stay there for longer. Take responsibility for what you're doing. Bring those features you're trying to implement from the start to the very end. Communicate to people and know how to communicate differently to people, and ask for feedback.
Questions and Answers
Participant 1: Do you enjoy the switching around between individual contributor and team lead?
Mogelashvili: Yes, in short. What I really enjoy is what connects to the feedback basically. When you're a team leader, you don't get instant feedback. You always have to wait until that hits you back some time. When you switch to the individual contributor, the code you write, you write and run it in an hour or so in production: instant feedback, instant gratification. That part I liked. I also like the part that I can do things on my own. At the same time, I've never loved the idea of leading people. Now I'm a lead developer, it means that I'm not only writing code, but I also provide technical leadership. I don't have direct reports, but still, I do work with people. I still coach them, mentor them. For me, people side is always important, at least for me. It doesn't have to be management side, it can be different.
Participant 1: Do you see yourself doing that for the rest of your career?
Mogelashvili: Yes. I don't see why not. I enjoy working with people. It doesn't matter if I technically lead them, or manage them, or lead from the personal side of things. For me, yes, I don't mind switching back.
Participant 2: Since you obviously have this leadership potential, you are able to switch back and forth. What do you think about the idea for you to stay as a lead, and then keep growing other people to be more like you versus you go back in their shoes and be an individual contributor? In the long term, do you think that it might be more valuable for the organization for you to stay as a lead, manager lead role, and keep growing everybody else?
Mogelashvili: I think that it doesn't matter what your title is, what matters is basically who you are personally. When I switched backed to IC, I still kept working with people, I provide mentorship, provide feedback to them. I didn't have this management burden. I didn't have direct reports to do performance evaluations and all those things. However, I didn't stop working with people. That's what I am basically. It's all about being a role model. You don't have to have certain title to be a role model. You can be manager, but nobody listens to you. You're just a manager. Or you could be a leader without a title. It doesn't matter which title I do have, just trying to work with people and lead them and show them examples.
Participant 3: It seems your positions are aligned with what your company and your teams need?
Mogelashvili: Yes.
See more presentations with transcripts
