In the recent episode of groCTO Originals (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Lubo Drobny, Software Engineering Coach at Cisco. With an impressive professional background at Seimens & SAP Labs, Lubo also actively contributes to the tech community through blogging, hosting podcasts, and organizing meetups centred around product and software engineering topics. Their discussion revolves around ‘Building teams from scratch vs branching’.
The episode begins with Lubo sharing his love for programming, hiking & gardening. He also gets into the details of a life-defining moment in his career that shaped his current coaching style.
Moving on to Lubo’s career progression, we get a glimpse of his journey from Slido to its acquisition by Cisco, highlighting the key differences between a startup & a corporation. He also shares strategies for team building through hiring, onboarding & training while focusing on delivery.
Lastly, Lubo highlights the key engineering metrics for assessing team excellence and their impact on delivery and quality, while underscoring the importance of prioritization.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who loves to organize meetups with product and with tech fellows. He loves to organize engineering podcasts. He has 16 years of engineering and leadership experience. Currently, he’s serving as a senior engineering leader at Cisco. Welcome to the show, Lubo. Great to have you here.
Lubo Drobny: Hi! Hi, everyone. Thank you for having me. I hope you will enjoy this episode.
Kovid Batra: Of course, we will. And I’m sure you would have a lot of things to share from your journey at your startup and acquisition by Cisco. So, we’ll definitely enjoy this. But before we get started on that part, we would love to know you a little more. So, if you’re comfortable, can you just tell us about your hobbies? What do you like? Some life-defining moments for you? That would be great.
Lubo Drobny: Yeah, perfect. When we’re talking about my hobbies, I would say that my first hobby, uh, programming, I think this is not a surprise. This was probably also kind of a life-changing moment. So I was just 11-12, teenager and I got my first computer at that time. It was an 8-bit Atari XL and I fell in love with this machine, not for games, but for the, let’s say, the possibility of creating new stuff, programming stuff and so on and so on. This was a very important moment for me.
But another one, it was, um, I would say, and a life-changing moment probably was when I was at a Swiss company, RSD, and my boss was a very good mentor. So this is something I probably never felt before, or didn’t have the experience when your manager or your leader is also a great mentor and helping you to grow. And this was very, very eye-opening for me. And it worked well.
And then about my hobbies, um, I like hiking. Uh, usually in Slovakia, we have nice mountains, but also around Europe, for example, Italy, the one, it’s Austria, uh, very nice mountains. Uh, I like gardening. So, this is also connecting to nature. And I like to play in my small garden. And I’m a proud father of three kids. It’s not a hobby, but something which defines me.
Kovid Batra: That’s great. Thanks a lot for sharing that. And you mentioned that your mentor, your boss at one of your companies was a really, really good leader and he guided you well. Can you tell us more about that experience of yours?
Lubo Drobny: Yeah. Uh, it was I think about 10 years ago or 12, I don’t remember exactly. And I was switching my role from technical developer to manager or engineering leader, and what needs to be said, it is a different role. It is not like evolution. So we go step-by-step. It is kind of a different role to lead the people, manage the people. Uh, it’s different than coding because computers do what you want, but people are very different. And for me, it was very important to tell him that okay, I’m kind of new to this. I would need help because otherwise, it could be a disaster. And he was very open and he, what was important was that he discussed a lot with me what he plans to do, he asked me a lot of questions, how I would approach those problems, what needs to be done, but he also really comforted me, okay, well, this is good, done. And he helped me to have focus on important stuff because at the beginning you cannot keep all balls in the air. When you are juggling, some of them could fall, but he always, we talked about it and he always told me, “Okay, this is not important. Don’t focus on it. It’s okay. You are doing good. It could be better, but we need to.” So, he was very encouraging. And this is a kind of quality. Usually, a lot of people kind of only criticize. But he was also very encouraging, very helpful always for me. So this was a very nice experience. And I think it really helped me to survive and grow as an engineering leader. Probably without him, I would, I would go back to coding and engineering.
Kovid Batra: I think that that’s a really great example. And when you, when you find someone at that stage of your life when you’re actually growing or making such transitions and somebody guides you well, you’re tend to actually learn from them, that trade and you yourself try to implement it. So I’m sure that today your team members who are looking up to you as a leader, are sharing the same emotion and feeling.
Lubo Drobny: I hope so because I think I copied kind of this coaching or mentoring style of management. So I’m, I’m not very direct. With my team, I usually talk to them trying to find, uh, the answers, the questions. So I’m not bringing the solution upfront, I’m trying to help them to find it. And I try also to coach them or mentor people around me to grow, not only as a team but also grow, uh, as persons. So it’s very important for me because if you have good people on the bus, uh, it’s, it’s a perfect setup.
Kovid Batra: Yeah, right. Absolutely. Great, Lubo, I think it’s a really great start. And talking about compassionate leadership, empathetic leadership, I think is very important these days. So let’s, let’s get started. Let’s look into more of your journey as a tech person, as a tech leader. Your stint at Slido was quite long. You spent almost six years scaling that startup from zero to one, and then this acquisition also happened. And then, you moved to Cisco. So this journey is quite interesting, at least from the outside. You tell us about your role at different points of time and how, how you took the team from zero to 50 members. And then, how did this acquisition happen where now, you are serving at Cisco as an Engineering Leader, how have things changed for you from Slido to here? I think it’s a big question to answer. You can take your time and let us know some interesting facts from the story.
Lubo Drobny: Yeah. So I hope that it will also be interesting for the audience. But in general, I joined Slido, I think seven years ago. Uh, at that time, it was a promising Slovak startup and there were around 40 people. But only five, uh, developers and two students. But at the time it was like, yeah, this could be interesting because they started to make some profit and the Slido application, if you don’t know, it’s about engagement in meetings and conferences. So, it’s a polling and questions and answers tool. So the presenter can communicate with the audience. The presenter can see the questions online. It’s soft real-time or can poll again in a soft real-time manner, uh, audience and see results and so on and so on. And looks that, uh, this is an interesting niche at the time and it could, it could grow and also the leader or CEO at the time, but the company decided that, yeah, this is a good time to scale the team and try to push more on, uh, also on engineering.
And my role since then has been the same. So, build world-class engineering and world-class products. So this was kind of the mission from the beginning. It’s kind of cliche, of course, but, this is usually the mission of everyone at a startup. You would like to build something great. But, to build something great, you need very good or great people. So as I said, it’s very important who is on the bus with you. And, so my first, of course, my first role was to start hiring and put together, let’s say, a solid process. And there were two levels to this. So, um, once it was, let’s say, kind of short-term, so find the gaps in the team, double the positions, so we are, we are strong and double the team, um, kind of in short time. But on the other hand, also think on, let’s say, mid or so, a long-time period. But we discussed that we should also build some awareness in the engineering community that, uh, we are good because otherwise nobody knows. So, um, I was focusing with the HR team on typical hiring. So, looking for the people, prepare the process, stages and all the stuff. But also we worked on some, let’s say, ‘engineering marketing’ or ‘advocacy’, how we call it. So we started to write some blogs. And we started to be more visible on meetups. Uh, lately we’ve started to organize meetups. So today, I’m helping to organize the product meetups in Bratislava, engineering, uh, meetups here in Bratislava. Uh, we started to be visible at conferences because we believe that it’s important in the long-term also to increase the awareness that we are here and we would like to build a great team. So, this was at the beginning.
Uh, then the next challenge, I would say, was finding a good structure for our teams and deciding how we would like to work. What we put together also with product leads, is that we would like to have small teams because they are, um, in our point of view, most effective for what we need. So, up to 8-10 people, not bigger. And we would like to have cross-functional teams. So, product parts, we call them ‘discovery’. So, it’s Product Manager, Designer, later also, User Researcher. And then, a ‘delivery’ part, which is the Tech Lead, engineers, front-end, back-end, and a tester. So it’s, it’s kind of a typical setup, but we’re experimenting, uh, let’s say, with the size of the team, with the roles. But in the end, we found out that this is probably the best template for us, how to create a team with it. Of course, few mistakes. Maybe the big mistake was, for example, starting the new teams from scratch because usually, we lost the culture thing. And so, therefore, we decided that it’s better, for example, to start the new team by splitting from the older one, which worked better.
Kovid Batra: Sorry to interrupt here. I have a question. You had this great strategy of, um, hiring the right folks by creating that awareness. So you started this community aspect, right? So, from there to hiring more people, you were like, it seems that at that stage, hiring becomes the highest priority, right? You want to scale, you want to grow and everything is going on. At that moment, when you are hiring, new people are coming in, the time period of onboarding somebody easily, like if we talk broadly, it takes 8 to 10 months for somebody to actually show you something productive coming out because the person would come in, gain the context and then get familiar with the things that are going around. So then, at least it takes eight months for somebody to come out and deliver something. And in a stage where you are fast-growing, how did you manage to deliver alongside hiring such folks and training them faster if you are doing that?
Lubo Drobny: I understand the question. The first point was that, uh, we were focusing on experienced people. So let’s say, seniors because usually they are able to be onboarded faster. So..
Kovid Batra: Yeah.
Lubo Drobny: So, for example, in my experience, how we did it, uh, when someone senior joins the team, the first month, okay, setting up everything. But we are in a startup. We don’t need a lot of permissions. So it’s very quick. This is your laptop and accessories. Uh, then we have, I think one or two weeks in general onboarding to the product, uh, to the company, everything. And then, after one month, I was like, “Okay, guys, what I expect is that you will do the first small release to the production.” Because we are a web application, we can release very quickly. We are using a common tech stack for the web, it’s TypeScript, Node.js, React, or Angular. And when we hire people who are proficient in those technologies, that is great. And we are not using some internal special frameworks or something, you know, you need to figure out how it works. And also we have very, very light processes. So, even when we hire, for example, a Java Engineer, after three months, they will be ready to code, ship, and deliver. So..
Kovid Batra: Oh, that’s great.
Lubo Drobny: But the best guys, in one month, they did the first release. So it was very quick, but we were focused on seniors. Then there was a question, okay, uh, what about the juniors? Because it’s, you can’t hire only, only them (seniors).
Kovid Batra: Right.
Lubo Drobny: And, what would I really like? We started the internship program which remains. And so, we decided to do a three-month summer internship for full-time and paid internships. Usually, four or five people join. And then, if they decided to continue part-time, it was really great. We were focusing on university students, of course. And this was a very great way to find very, very good junior people who are on top level, I would say. So I can recommend the internship program also for, for others. It is working for us very well.
Kovid Batra: Yeah. I think hiring the expert folks, having your tech stack pretty common and simple and sorted, having the least number of processes, and having automation in the right places can really accelerate that process of onboarding. And hence, when you’re hiring someone who is good, you can get the productivity as fast as possible, right? So..
Lubo Drobny: Yeah.
Kovid Batra: That, that really worked well for you there. So, I think that’s a good piece of advice to keep such things in mind when we are proceeding to scale, at least at that point when you are navigating towards two different goals. One is, of course, bringing in people and then training them and hiring them. And at the same time, delivery. This could work out really well. And I think the point which you started that also seemed very interesting. Like you said, we thought of not hiring people and putting them into new teams, we just branched out, uh, new teams from the existing teams itself. So, this seems to be a very interesting strategy. I think you could just continue on that. So, I’d love to hear more.
Lubo Drobny: Yeah. Because what we, what I, or what we realized, when we started teams from scratch, they came with some culture or habits from previous companies and they started to replicate this thing because they didn’t have, uh, let’s say experience from our teams, our culture and the way we work. And in the end, we realized that this is not the, this is not the best. And maybe it is more clever to, for example, we have a good team, we can hire a little bit more people there, and then, turn around and split them. It’s also easier, also for the team and to keep the culture this way if you already work in a good team and you understand how we work, what are the habits, what are the things, what is important for us, you can easily continue. So, uh, this is the, let’s say, mechanics, how it, how it works for us. I think it’s, it’s better, at least in our practice.
Kovid Batra: Definitely.
Lubo Drobny: But, of course, sometimes you need to start from scratch if you do not have, let’s say, the skills, technology, or you started with something really new, so you cannot pick it for everything. But let’s say, if you would like to have the new team with the same tech stack and the same culture, this is the better way from my point of view.
Kovid Batra: Definitely. Even I agree with that point. All right. I think, apart from this, when you scaled up and, uh, I’m just going back to that piece where the company got acquired. The way you were operating at Slido and now, working as an engineering leader with Cisco. How have things changed? Like, give me some examples, like, okay, this is how we used to do here. And now, things have changed for the better or maybe for a little worse here.
Lubo Drobny: Yeah. Of course, something changed. The thing is that, uh, we joined a very big company, a corporation. And also, corporations focus on security, definitely. So, what definitely changed was that we had to implement more certifications around the ISO, 9000, 27000, and also, another American certification for software development, security and quality. This was kind of challenging for us because we didn’t want to sacrifice, let’s say, our way of work, but we had to change some processes, of course. But we didn’t want to slow down our, let’s say, release process and our possibility to be, to be fast. Um, therefore we had to implement a lot of automation and we had a lot of discussion with the experts in this certification, how to do it. It is compliant and it is okay from the security point of view or quality point of view. But we had to do some sacrifices, I would say. So, it is not the same as before. But on one side, we, are, uh, shipping more secure products, so it’s, it’s not bad.
Kovid Batra: Yeah. Yeah.
Lubo Drobny: On the other hand, we joined Cisco as a business unit. So, they didn’t change the way, how we are organized, how our teams work and Slido is still continuing like a standalone offer. So, also, the Slido brand still exists. Also, this is kind of different, so they didn’t swallow us, I would say, but we are still living as a Slido, which is kind of, kind of nice. And therefore, we are keeping some autonomy, which is good for us to some extent that we can continue working, you know, let’s say, the way we consider them the best force for Slido. On the other hand, as I mentioned, Cisco brought on to us more focus on security and quality, of course, because, um, this company requires high levels of that and more opportunities in, uh, let’s say, integration. Integration way. So, we started with integration with Webex, of course.
Kovid Batra: Yeah. Yeah.
Lubo Drobny: This is a Cisco tool, but then we continued with the integrations with also other video tooling. But, in this cooperation, with Webex teams, gave us a lot of experience, how to do it right way and so on and so on. So, and of course, they gave us the opportunity to reach a broader audience, especially in an enterprise environment where usually the startups are not, let’s say, uh, preferred
Kovid Batra: Yeah, I know.
Lubo Drobny: Usually, corporations would like to buy tools which are strong with the maintenance and all that certification and all the stuff.
Kovid Batra: There is one more important thing that I just felt like asking. When you were building Slido and you were an independent company, the level of impact you would have felt that you’re creating with the product that you’re rolling out and then, integrating with a tool like Webex and then reaching out to like millions of users, right? So, that changes the overall feel of how you’re building it, how you’re doing it. So I think that that must have been a good experience.
Lubo Drobny: Yeah. This is, uh, this is definitely the positive thing that, uh, we were able to, to put Slido in the hands of the enterprise users, like the Webex or another integration. So this was definitely, definitely very positive. We were able to do it because otherwise, probably, we would not have gone in this direction, definitely.
Kovid Batra: Of course. I mean, even if you reach so many people, it would have taken a few years to reach there, right? So that’s, that’s a good jump there. Cool. I think that that’s interesting.
And now, the last piece that I just wanted to understand here. When you are operating with 50 developers with you, I am sure being, uh, an empathetic leader, you are trying to understand every aspect of your developer who is part of the team. But how do you exactly measure their overall excellence? How good they’re doing? How do you measure their work? How you measure their achievements is what I want to understand from you.
Lubo Drobny: Um-hm. So, what is most important for us is the product itself at the end and the value that we are bringing to our customers. So for example, if we build something in time, in high quality, very secure, but nobody’s using it, in the end, it is a failure even if we did a good engineering job. But if it is not working for our customers, we will scratch it or discard it or trim it on the part of the product. So, in the end, it’s, um, this cooperation with the product is very important for us because we are a product company. And also, my evaluation of what we are doing is connected with this, that at the end, when we’re doing and delivering something, we believe, of course, that Product did their jobs and they, they suggested a good feature or, or product to build. Uh, but this is still a very important part of, uh, let’s say, also evaluation of what we are doing in engineering. If in the end, what we built is used and it is built the way that people can use it. So in this case, the second important thing for us, it’s quality and usability, which reflects, for example, uh, net promoter score or statistics like this. So you can, uh, you, you want to measure that these deliver something, that it is a good idea from the product side, but it also on the other hand, it is delivered with good quality because we have experienced if there is some big bug, uh, in the product and our NPS is going down next week.
Kovid Batra: Yeah.
Lubo Drobny: It’s, it’s very connected, it’s, it’s very connected. And for us, it’s a, it’s a very important metric. So, it’s NPS. Then, of course, what we’re evaluating is, uh, the quality by measuring, for example, the total number of bugs or trends. So if we are able to keep it in the, let’s say, a reasonable level, so we have kind of a ‘zero medium +’ bugs policy. So, we are okay to have small hiccups in the product and we are, uh, we are okay with it. But we would like to fix, let’s say, medium, medium bugs as soon as possible. So, this is important for us. Then, uh, for us, is important, deployment pace, that our CI/CD and all this, our continuous integration, and release process is fast. So, there is no problem, that test automation is working well. So, we are measuring weekly deployment strength. And again, if we see that there are some problems or, uh, developers are complaining that something is taking too much or if the tests are unstable, we would like to very quickly fix it and address it, because this is very important for, let’s say, developers’ experience. If you have eight people, A-class people in the team, they just want to release it. They don’t want to wait. They don’t look for some..
Kovid Batra: Reviews or anything.
Lubo Drobny: ..Some excuses why they want to push it. And they want to see their work outside. So, this is very important for us.
Kovid Batra: I think this, this brings me to one important point. Like you said, you look at the bugs rate and, like you have this policy, like, as soon as there is a medium-severity bug out there, you have to resolve it as soon as possible. See, these things ultimately tell you that, okay, this is the problem, like this is a symptom kind of a thing, right? But at the end, when you have to drill down and understand what is the core, like is it a bad review process or is the initial code quality not good? Then how do you end up finding it? Uh, like, of course, you can go by the brute force method, but I’m just, uh, curious to know how you do it.
Lubo Drobny: For more, let’s say, some critical bugs or some high-severity bugs, uh, we are doing, um, postmortems. It’s usually a very interesting process. Uh, usually takes two, three weeks. So, if something happens, there is an owner of the postmortem. So, it is not about who is guilty or not. There is someone who is the owner, who is able to put it together. And it usually is investigated because, uh, you need to, you need to check the log files. You need to talk to people about what’s happening. You need to check the slight communication and you put together, let’s say some scenario, what happened before, what happened during the incident. And you would like to evaluate more things, how we reacted, if our reaction was good or it was slow, um, because maybe we could do revert or we could fix it. And, you know, there is a lot of, a lot of nuances. You can evaluate it during our reaction to this bug or to this problem. And then, of course, there are some five ‘whys’, this typical ‘why is this happening?’ and why, why, why, why. And you asking yourself more than five times to really find a good, to find the root cause of what really happened. And then, you would like to suggest a good, let’s say, some short-term fixes and maybe also some long-term, because you maybe need to just fix some code because there is a bug. But maybe also you need to fix the process or you need to fix some communication issues. You need to fix something else. Because sometimes, some problems happen. But, if you are able to react in seconds or minutes, It’s perfect from some point of view. If you can improve from, let’s say, reaction time in hours to minutes, it’s also a good deployment. This is what I want to say.
So for us, it’s also improvement, uh, important in this. Uh, time to detect the problem and, uh, time to fix, of course. And if we are able to increase those, uh, decrease, decrease those times to a minimum.
Kovid Batra: That makes sense. Perfect, perfect. Great, Lubo. Uh, this was really interesting. And, uh, when someone shares like these level of details, but with some examples, I think that’s the best part and I loved that while discussing this with you. So, I’d surely love to have another round of discussion with you on other topics related to the engineering channel sometime.
But today in the interest of time, I think we’ll have to call this short today and thanks a lot once again for giving us the time and sharing your learnings and experiences with the community.
Lubo Drobny: Okay. Thank you again for having me. I really enjoyed it. And I wish you the best.
Kovid Batra: Thank you so much. See you.
Lubo Drobny: Bye bye.
Implement DORA metrics, gain dev visibility & drive success in your teams.
Try Live Demo
