In this episode of the groCTO Originals podcast, host Kovid Batra engages in an insightful conversation with Christopher Zotter, the Head of Digital Engineering at Sky, Germany. Christopher brings a wealth of experience, including a decade of leading engineering teams and founding a software development agency.
Known for his unique leadership philosophy, Christopher believes in the power of building trust, embracing failures, and fostering a transparent culture. He shares his journey from an apprentice in Germany to a leadership role, emphasizing the importance of hands-on experience and continuous learning. The discussion delves into the challenges and strategies of managing culturally diverse remote teams, effective communication, and transitioning from legacy systems to cutting-edge technologies.
Christopher also highlights the significance of being a role model and integrating community involvement into one’s career. This episode offers a deep dive into the principles and practices that can guide leaders in nurturing successful global development teams.
Kovid Batra: Hi, everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have a very special guest. Uh, he’s Head of Engineering at Sky, Germany. He is also the founder of a software dev agency, and he has been leading engineering teams from past 10 years now. And today, we are going to talk to him about how to lead those global dev teams because he has been an expert at doing that. So welcome to the show, Christopher. Great to have you here.
Christopher Zotter: Thanks for having me. I’m really excited to be here, part of the great podcast. I get to know this and also the last months and with key insights and hope I can provide some of my learnings from the past experience also to your great audience. So happy, happy to be here.
Kovid Batra: I’m sure you can do that. All right. But before we get started into, um, knowing something about your team and your, uh, areas of expertise of how you lead teams, we would love to know a little bit about you. Like something that LinkedIn doesn’t know, something that is very impactful in your life, from your childhood, from your teenage. Um anything that you would like to share
Christopher Zotter: So first of all, the most important part is not business, it’s my family. So I’m a proud father of two kids and I have a lovely wife. So this is the foundation of everything that I can do, also my job properly to be honest and gives me energy. Um, and also what is not on LinkedIn or it’s on LinkedIn, but it’s worth mentioning is I didn’t study anything. So you see now my title, which is, I also need to reflect, impressive to be honest, also to myself, but I only did a normal apprenticeship in Germany to work as a software developer. So I really start at the core of the things, but now I managed to do so. So I make my, my way through doing the things, getting hats, hands-on, and don’t fear to make mistakes. I learned from things, um, I did, I deployed the hard coded ID and tested it on production while on a software in the past. Yeah, that never happened again. So I really get hands-on and get these kinds of experiences. Um, And what is also, I think, important is to not only focus on, on the software things, but also doing some things for the society, for the community beside the work, which, which gave me the balance. So this is not on LinkedIn. This is something that has also very positive impact on, on my, on my past. So, um, yeah, that’s roughly where, who am I, but I can also continue a bit of my journey to, to becoming that position if you’re interested in too.
Kovid Batra: Sure, why not? Please go ahead.
Christopher Zotter: Um, yeah, then my, my, as I said, I, I did an apprenticeship in Germany, which takes mostly three, three and a half years, and I had the chance to work at the very small company. It’s not, it’s not, the company doesn’t exist anymore, I think, but I got the chance to work in a very small team with great experts, and I got responsibility from day one. So I didn’t develop something for the trash. It was really then something which can go to production, of course, with review process, et cetera. And again, the advice I can already share is try to do as many things as possible. Even if in the younger years, you have the time. I see that now with family, the priority shifts obviously, but use the time you have, do side projects if possible, because getting hands on the things, nothing can beat experience. And this is, I think also the big learning I had over the, uh, over the time is I get all of my, um, promotions all of my way through the career, starting from an apprenticeship, junior developer, senior developer, lead developer, and now Head of Engineering, um, through my experience. I did hands-on and I can prove, showcase what I did starting from code skills, simple HTML page for with the, with the simple contact form, everything. So I get my hands on different things to get, uh, get, get the knowledge, and I think knowledge and experience beats most of the, of the things, but you can’t study it. Um, you need to get hands-on. Yeah, just briefly, and now I’m here.
Kovid Batra: Yeah, no, I think that was a very, very nice intro, and I think we now, we now know you a little more. And one, one thing that I really loved when you said that, uh, it’s not just about work. Uh, there is family, there’s community that you want to do for. So I’m sure this community thing which you are doing, uh, this, this would have helped in shaping up, uh, some level of leadership, some level of giving back. I think leadership is another name for giving back. So from there, it should be coming in. So can you share some of your experience from there that helped you in your career moving from let’s say an IC to an EM and then growing to a leadership position?
Christopher Zotter: I like that you say leadership is giving back. Yes. Um, I didn’t see it that way, but it totally echoes with me. Um, at the end, it’s all about the people. Um, I think we have, we have also on this planet, so many, uh, wars happening, so many people working against it, and I’m, I try to do the opposite because we’re all humans. And I learned also through working for the community in a certain way. So I, I worked for one year to support disabled people, to go with them to school, young people, and there I learned, hey, these are all humans and everybody’s trying their best. Also now, in my position, it’s about people, it’s about getting their feelings, getting their circumstances and getting their perspectives, getting their culture. We will come to the topic later, um, because there are different cultures. We are working together, even in software development, you’re across the globe. Um, and there, you need, always need to, to think about and not act like everybody has the pressure to get it done, get it done. And so, we need to consider that humans behind and let’s find to create a win-win situation for everybody that everybody feels confident, confident and comfortable and respected. And, um, this I learned, I’m a very value-driven person. And my key value is respect because respect is there for everything no matter what you’re doing. Um, it starts going into the office, the cleaning person, greet the same way as you greet the CEO. Um, it’s, it’s, we are all humans, everybody’s putting the bits and pieces together and this sometimes we, we forget in our daily business. So, um, this is what I definitely learned from being there, putting, giving away something for the community or whatever there is. So yeah
Kovid Batra: Perfect. Perfect. And another interesting piece in your career is, uh, no academic background, uh, in engineering and then doing things hands-on. And then, uh, you are working on a side business as well, which you just mentioned where you, you recommend people to do that in the early ages, because that’s where you get the most of your experience and knowledge to do things, how to complete things. How exactly that has contributed in your career growth? Because I also come from a similar experience. I would love for you to explain it if this has contributed in some way
Christopher Zotter: Okay. Yeah, great. Um, that’s yeah. I started my side business also, I think now eight, nine years ago. Um, and by the way, this will now come to an end right now. It’s already more or less ended because my, my daily job requires full attention plus family. There is no time and you need to also to say no to the things. Um, but in that time it was, uh, it was pretty important for me because what I did is the things I learned in my company, in my apprenticeship, um, I tried to do then some projects for first, for my own and then for my inner circle. So for some friends, they had also built up a company, whatever that is, need a home page, need a web application. Um, and I built it on my side business. Then to adapt the things I learned in my, in my daily business and enhance it on a certain way in my environment to test it to work against and enhance the knowledge. Try things out if they’re working there in a smaller, bits of pieces, not in the big company where you’re working on. Um, helps me a lot to grow, trying out, trial and error. Uh, and at least that’s the experience you get and this experience, if you bring it back to your company, if you want it to make career, um, this is where you can benefit from, and yeah, that knowledge beats everything at the end.
Kovid Batra: Sure. I think for me, like I also had a side business and how it has helped me is that I was interacting with the customers directly, right? So that was for me a great experience, which when you are in a larger organization where you have people doing the front end job and then you are getting just the requirements, that relatability with the problem statement with the audience is much lesser So I think that way it has helped me much more from that point of view.
Christopher Zotter: Interesting, because we at Sky we have, our claim is the, the customer or the users in the centric of everything and I have the, the I, I’m a Sky, a soccer fan, and, and, and Sky probably just to name it what we are doing, um, because there is probably a conflict with your audience from India because Sky channel there is known and it’s a bit of a different thing than what Sky Germany is doing. So, um, for, for, for you, we are the major entertainment provider here in Germany called pay tv. We have sports, um, mostly the Bundesliga, so the German soccer football, uh, um, rights we have in place or some, uh, own produced movies. Uh, you can watch Netflix and stuff over our platform, either it’s streaming or it’s our Q receiver. And, um, as I’m a big, Bayern Munich fan, I use Sky or previously it was named Premier, uh, for a long, long time ago. So I’m also the customer on the one hand side to use our product and know what’s going on and know the issues and can bring it then into and learn from it on, on the other side, which is now a great benefit, but I can echo it. It’s, it’s definitely one of the key things to know who’s your audience and what are the users and what are the customers and go out and get to know them, what is their behavior in order to deliver them the best product, the best experience they can, they can have.
Kovid Batra: Sure, sure. Absolutely. All right. I think, uh, that was, outside what you do at Sky, most of it, uh, we discussed. Now moving in from that note into the world of Sky where you are heading teams and, uh, most of them are remotely working from India, from Germany and other parts of the world. So first thing I would like to understand, like, how things have changed in the last four or five years from your perspective? Um, you have grown from a manager to a leadership profile. What were those things that came into, uh, into your role as a responsibility, uh, that you took up with these global teams that help you grow here? How was the experience the last four years?
Christopher Zotter: It was an amazing ride. Um, I think every, every, every step has their challenges in, in a certain way. Um, being a developer, you can then go to either other developers or have your scrum master and feature teams. Um, but coming to be, um, a leader for such, such a, such a big team. So my team is currently, we have five people here in Germany and we have 15–16 right now sitting in Chennai, India. You have to think about different things. You have to think about the team harmony, how the people working together, you have to think about communication. You have to think about values, how everything works then together, and not only getting the code done in a proper way with all of their quality checks in between, but also that I need now to consider there helps me to get the experience in beforehand to know what is technically possible, what we need to do in order to shape, um, the best and the most effective process. We will talk about that, I think, later also, what can be done there. But also, um, yeah, to consider, as I said previously, the different perspectives. Everybody is on a different level, um, has different circumstances. Somebody is now getting it further earlier. So probably not that much focus on work, which is fine. We need to deal with that also to support wherever we can. Somebody is getting sick and all of the things you need to consider. Um, and it’s, it was also a big change for me and I’m still in progress to be honest, because I started my journey as a developer and I love to code also. Um, but so much coding in that position is not possible anymore. And you need to build up your team where you can trust and give them the task and get it back done or get it, getting the right feedback, uh, whatever that is. So this is one of the things to build trust to having a lot of conversations. So having a lot of coffee in the office with the different guys to get to know what’s going on. And of course, um, you are now, or I am now in a position to having, uh, stakeholders, uh, communication with our CTO, COO, uh, different, different areas, which you don’t have normally as a developer that you only get the requirements. So again, I’m a bit next to the customer, right? Because I can also bring my bits and pieces into some of the features and decisions. Um, and this, this is one of the biggest changes to, to go out of the real, getting the hands-on and, and yeah, bringing the layer on top to prepare everything and protect everything that my developers can really focus or my architects can focus on the work without any disruption and make the work as smooth and as fast as possible.
Kovid Batra: But I think in your case, um, as compared to, uh, I would say, a single culture, a uniculture team, um, your case is different. You have people in India, across the globe. This collaboration, uh, I’m sure this becomes a little difficult and it’s a challenge of a lot of companies after COVID, uh, because things have gone remote and people are hiring from across the borders. How, how it has been an experience for you to handle these remote teams who are from different culture? And what, what really worked out, what didn’t work out some of those examples from your journey?
Christopher Zotter: Uh, yes, this is definitely a challenge and I have to say I’m the only German-speaking guy in my team. So we are a German company, but I’m the only German speaking guy. So I, in Germany, we have also some Indian colleagues, some from Russia, uh, sorry, from Ukraine. We have some from, uh, Egypt. So it’s mixed. And as, as you said, a lot of people are coming from, from Chennai, India. And imagine this is about 4, 000 kilometers difference. Um, a lot of, uh, at the end, and we have two different cultures. And this was the biggest learning I got to know is at the beginning, just an example, a yes doesn’t mean a yes. Um, we had some requirements, we talked about that and I got the feedback, “Yes.” Okay, and then I assumed the ticket will be done, but it was only, “Yes. I got to know that I need to do that.” But not, “Yes, I understand it.” So there’s a communication, a learning over the time and which the whole company has to do. So we all need to transform here at Sky and also at Comcast Engineering in India that we are going together, find a way of communication, get to know the, the other, uh, the other culture, the other people, the other behavior, how they’re working.
Um, and of course, I’m also a fan of remote working, but also a fan of getting in touch, uh, getting into, into personal conversations with people, um, not only, uh, not via camera, but in person. So that’s also why we have some mandatory days at Sky where we need to go to the office. But I’ll also be there in India once or twice a year, even if it’s a long travel and, you know, challenge with family, but, um, the investment is, is worth it. Um, I got to know the, the Indian culture very well. Um, and it’s also kind to them to show appreciation. So they recognize, “Hey, they really take care about us and we’re not only there outsource for things, get the things done.” And as I said, I’m taking care of, at least my goal is to take care about the people, to treat them with respect and try to find the way together. And if you’re having the 1-on-1 conversations in person, get to know the culture, go to temples, get to know all of the things we’re running around, what they, what, the food. Oh! It’s amazing in India. Um, everything. Um, then you grow together and then this makes, after my second visit, I can say, um, the communication was a totally different one. So I got to know then, or I feel really the trust of my team then to say, “Hey, Christopher, this doesn’t work.” So they say and you know, this is a cultural topic because in india, it’s normally, uh, it’s they’re not used to saying, “No, it’s not working.” They say yes and try to make it work anyhow, but it doesn’t help in the, in the daily business. So it’s better to say, “Uh, I need help at the first place and then we can get it done as a team.” But coming to that point, that’s one of the biggest challenges I faced. It’s still not perfect yet, but this is where we think always about what is their circumstances? Is that really yes, they got it or do they need some other kind of help, um, that we can provide them to them?
Kovid Batra: I think a very, very good example. Being an Indian, I can totally relate to it. Uh, we go with that mindset and at times it is not, uh, beneficial for the business as such, but there is a natural instinct which says, okay, let’s say yes. Let’s say, “Yeah, we are trying.” And try to fight for it maybe. Not sure what exactly drives that, but yeah, a very, uh, important point to understand and look at.
All right. So I think this is, this is definitely one example, which, uh, our audiences, if they are leading some teams from India, would keep in mind when they’re leading them. Anything else that you, that comes to your mind that you would want to do to ensure good communication or collaboration across these teams?
Christopher Zotter: I think when we stick to the topic is to be the role model. Um, I said it in my introduction. I deployed something hard coded to production with an ID. I bring that always as an example to say “Yes, this was a failure.” But I took a great learning out of it. So to establish these kind of things to acting as a role model, especially as a leader, because then you lead and the people will follow you and you should.. My claim is to act as a leader who is not there. I’m the same. I only have another title, but we are all equal. I can’t do my work without you and the other way around. So we’re one team, no matter who has, which level of a junior or, uh, whoever that is, so working together as a team and be there and support everybody. And I say always, “If they don’t need me anymore, I did my job perfectly.” Um, so this is what I, what I’m aiming for. No, to be really a leader, to be a role model, to, to say, “Hey, this doesn’t work.” “Oh, this was my failure of the week.” That’s what we probably now try to establish failure of the week that everybody, uh, put that failure into learning and share that with the audience. Um, it breaks a bit everything. So they see, “Hey, they are now doing it. So I can do that as well.” And this takes away the fear of if I say too much things I can’t do, I get fired. That’s the most fear, I also get to know why talking to the people. Um, as I know, that’s not the case. I appreciate it more if you say it to me instead of hiding it. So, um, yeah, this is definitely, definitely the thing.
Kovid Batra: True. I think one example that comes to my mind, uh, when I talk to my, um, friends and colleagues who are working across different organizations, like Amazon, Microsoft, world, handling teams from India for US or vice versa. Um, whenever there is huge transitions, let’s say from legacy systems to new architecture, they are like for 6 to 10 to 12 months, I’ve seen they were in a stressed situation where they’re saying like, “The team is not here communicating and managing that stuff is becoming difficult for me.” They were making multiple trips to, to the, uh, to the main home ground and then getting things done. So in your case, you, you guys are remote-first and I’m assuming most of the times you’re dealing with such situations remotely. So has there been a situation where you had to migrate from some legacy systems to new systems, new architecture, and, uh, there were challenges on that journey?
Christopher Zotter: Um, we’re currently in. Uh, so we are in a big transformation phase at Sky. So this is taking off for some years. And, uh, let’s say we in the final steps to be there to create, we started everything, challenged every technology we had, um, a few years back and say, “What can we provide best to our customers? So what technology is cutting edge? What technology is bringing our faster cycles of deployment, faster cycles of changes?” And challenged our content management system up to all completely our CRM system. Um, and that’s, that’s, we’re currently in the middle of it. Um, the challenge is obviously, yes, you always did in the past, something is not documented, some processes are there, and not everybody’s trying to challenge all of the things which happened in the past but it’s exactly the right time to do so, to, to challenge what was there. Do we really need to convert it and migrate it to a new system or not? Um, and get better into doing that. So take the learnings, challenge it and bring it to the new system. And that we’re in the middle of, um, that’s why, why I also started at Sky to, to, to kick-off that journey and at this part of time I was the developer who started it and, um, now i’m happy to say that we are in a very good shape. So we are live with, uh, with most of the things already, the migration is still going on, but um, our sales journey and stuff is already live and going to customers. We have proper monitoring set up. We have good testing in place. So, um, yeah, but again, what I said is, um, I see also now the old worlds, the old systems, um, and we, we all have to be open-minded to getting, getting transferred to new things, um, to always learn every day, especially, I think your audience knows that pretty well. In software development or development is that every day is a new tool, every day is a new change, a new version and new things you need to update it here and there. To always stick to that level is a challenge we face every day, but we’re trying to do our best to always get the latest version and the best features out for our customers.
Kovid Batra: Sure. I think one very good point you highlighted, like as a leader, uh, as a manager, you might still realize that this change is for the good, and this change is going to impact us in much better ways for the business point of view, from our engineering point of view. But when it comes to the people who are actually developing, coding, uh, how do you ensure like such big migrations come handy, people don’t have resistance? Because giving a plan and a strategy, uh, is definitely one thing which you have to craft carefully. But one very important thing goes into the, the innate motivation of people to execute it so that they think of use cases, make it even better than what you have planned for, at least on the paper. So what, what do you do to ensure such kind of, uh, culture shift or such kind of culture being instilled in people to embrace that change?
Christopher Zotter: Um, first of all, I think if you are yourself your own customer, this is the first thing. So you need to consume your own product as well. So dog food it. Um, It’s a bit difficult with India, but we have possibilities to also use Sky at least in the office to play around, to watch the movies to watch the things, um, that we can identify with that. That’s the first thing that we know what we’re doing to know what, how our customers are acting and I always said is I use a lot of data, um, to just, hey, how many visits do we have on these pages? Or check this feature, has this impact on our sales, whatever that is. So using that data to show, hey, the button you’re changing right now is not only a color change. This has a psychologically thing. If you change it to green one to give a positive feedback to our customers that they would click then and buy the things, just stupid example. Um, And you will see when we put that on production or do some user tests, you see directly your impact and it would go to millions of customers. And coming out and bringing that every time, every day to the table, um, opens up, hey, the things they’re doing, they have a real impact and this is everybody can be proud of. And I said always, hey, look, if you show that to your family and your mother, this, you can, and that’s a good thing at that development. You can show the things, uh, if you’re doing an API, it’s also important, but it’s a different thing. That’s why I love that development to say, you can showcase the things. Um, so we’re constantly measuring the things constantly, constantly improving. And this gives also the, the, the developers a sense of, “Hey, this is really important, what I’m doing here and this is the impact.” Um, and in order not to, you know, putting too much pressure on the people. We always have, uh, uh, we are working in a safe environment, so a scaled agile framework where we plan the next three months ahead and the planning is done by the developers and the developers commit to this, um, uh, plan provided by the business and they commit what they can achieve. So they have then the plan and they have an influence on that. And this gives us a balance to first be predictable, but also, uh, make the developers identify with things they’re developing.
Kovid Batra: Got it. Got it. Makes sense. I think it revolves around creating those right incentives, creating those right experiences for the developers to understand and relate to. Uh, so while, while you’re talking about having those right incentives, measuring the impactful areas, uh, I’m sure you must be using some level of metrics, some level of processes to ensure that you continuously improve on these things, you continuously keep working on the impactful areas. So, uh, at, at Sky or at your previous organizations, what kind of frameworks you have deployed? What kind of metrics you look at for different initiatives?
Christopher Zotter: Um, first of all, uh, I got to know that only what you measure, you can improve. That’s the one claim I always get to know. Um, it can be a weight, but, uh, then you see also some improvements. So just an example. Um, I’m, I’m a developer. So, uh, let’s start with the coding part, probably GitHub. Um, yeah, I mean, GitHub, a lot of different cycles, um, starting from creating a pull request, uh, reviewing a pull request, checking if it gets rejected or not, how many comments you get, um, uh, up to, it’s connected to CI/CD where some of our testing frameworks are running against different features we wanted to merge. Um, this is one of the key indicators where we say, um, or in the past also where we, we were looking into and say, “Okay, um, how big is a pull request? How much time does it take that it gets reviewed?” Um, all of these KPIs, um, or there are KPIs behind that, but the, my goal is that I get identified if I need to go deeper into some of the topics to find probably some root cause. Um, the same happened on, on the delivery level. So not on the code level but on the delivery level where we have our tickets, our story points and where we can roughly say a story point is one day more or less, um, and if I see there’s one story point, but the ticket is in development for five days, um, I need to go into, uh, into communication, say, “Hey, are there any challenges?” Um, or, “Do you need some support? Is there a knowledge gap?” Or if a feature has too many bugs after that assigned, um, after it’s merged to our development stage, um, we probably have a lack of quality. It could lead to a lack of, uh, lack of yeah knowledge here and there. So this is my, my measures to not to and this is again coming into a culture topic, um, to use the data the right way and not to say, “I micromanage you. You get fired if you don’t hit the KPIs.” No. Um, the key is we need to have in these KPIs that I get an alert as early as possible that I need to go into communication and find a way to take the people by hand and work together against some strategies. Could be knowledge sharing, could be coachings, could be whatever that is. It could also be that I got identified. We have some issues with one of the product owners, for example, who doesn’t provide all of the details in a ticket beforehand. It comes to development. It can be a lot of things, but if I don’t do that, I don’t have or at least I get to know that by a lot of weeks later, and then it’s too late. So gives me an indicator where I need to get into communication to improve, um, the process, to improve, um, the people, to make them better and, and yeah, to support them.
Kovid Batra: Make sense. I think very rightly said, um, using these metrics always makes sense, but how you’re using it will ultimately be the core thing, whether they are going to help you or they can give back. So yeah, I think great advice there, Christopher. And I think in the interest of time, uh, we’ll have to take a pause here, though I, I really loved the discussion and I would love to deep dive more into how you’re managing your teams, but maybe another episode for that. Uh, and once again, uh, thanks a lot for taking our time, sharing your experience at Sky, telling us about yourself. Thank you so much.
Christopher Zotter: Thanks for having me. Uh, thanks for having me. It was a pleasure to be here. Happy to come a second time to dive deep, uh, deep dive into some of the topics, um, if interested and, uh, also kudos to you. It’s a great podcast. I love to listen to it on my own because I also pick some nuggets out of that each of the time. So keep, keep pushing that. Thanks a lot.
Kovid Batra: Thank you so much, Christopher.
In this episode of the groCTO Originals podcast, host Kovid Batra engages with Vilas, an accomplished engineering leader with significant experience at companies like Walmart, Netflix, and Bill.com.
Vilas discusses the concept of Developer Experience (DevEx) and how it extends beyond simply providing tools. Vilas highlights the importance of enabling developers with frictionless processes and addresses the multidimensional challenges involved. The conversation delves into Vilas’s journey in DevEx, insights from designing platforms and enabling developer productivity, and the necessity of engaging with key opinion leaders for successful adoption. Vilas shares personal anecdotes and learning experiences, stressing the significance of treating developer enablement as a product and encouraging collaboration.
The discussion concludes with advice for those stepping into DevEx roles, underlining the evolving significance of this field in the industry.
Kovid Batra: Hi everyone, this is Kovid, back with a new episode of groCTO podcast. Today with us, we have a very special guest. He’s an accomplished engineering leader, has been building successful teams from last 15 years at Walmart, Netflix, Bill.com, and with his expertise in DevEx and Dev productivity, he’s now very well renowned. So we found Vilas through LinkedIn and, uh, his posts around DevEx and Dev Productivity, and I just like started resonating with it. So, uh, welcome to the show, Vilas, great to have you here.
Vilas Veeraraghavan: Thanks Kovid. I am grateful for getting to meet people like yourself who are interested in this topic and want to talk about it. Um, so yeah, I’m looking forward to having a discussion.
Kovid Batra: Perfect. Perfect. But Vilas, before we get started, um, this is a ritual for groCTO podcast.
Vilas Veeraraghavan: Okay.
Kovid Batra: Uh, we will have to like, uh, know you a little more beyond what LinkedIn tells about you. So tell us about yourself, like your hobbies, how do you unwind your day? Something from your childhood memories that tells who Vilas today is. So, yeah.
Vilas Veeraraghavan: Okay. Okay. That’s, I was not prepared for it, but I’ll, I’ll share it anyway. Um, so I am a, the thing that most people don’t know about me, uh, is that I am a big movie fan. Like I watch movies of all languages, all kinds, and I pride myself on knowing, uh, most of the details around why the movie was made. Um, like, you know, I really want to get into those details. Like I want to get the inspiration of behind the movie. It’s almost like appreciating art. You want to get into like, why did this person do this? Uh, so I’m very passionate about that. Um, so that’s, that’s something that people don’t necessarily know. Um, and apart from that, like, I, I enjoy, uh, running and walking. It sounds weird to say I enjoy walking, but I genuinely do that. Like that’s my, that’s the place where I do most of my thinking, analysing, all of that.
Kovid Batra: Perfect. Which one’s the weirdest movie that you have watched and like found out certain details which were like very surprising for you as well?
Vilas Veeraraghavan: I don’t know if I would say weird, but you know, all of, every director, every film director has one movie that, you know, they have always yearned to make. So they, their entire career goes in sort of trying to get to that movie, right? Because it’s their magnum opus, right? That’s the, that’s the term that people use. Um, I always find that fascinating. So I always try to look for, for every director, what was their magnum opus, right? Uh, so for example, for Raj Kapoor, it was Mera Naam Joker, and that was his magnum opus. Like what went into really making that film? Why did he make it? Like what? And you’ll realize also that their vision, the director’s vision is actually very, um, pure in those, in a sense that they will not listen to anyone else. They will not edit it short. They will not cut off songs or scenes. It’s such a, uh, important thing for them that they will deliver it. So I always chase that. That’s the story I chase.
Kovid Batra: Got it. Perfect. I think that was a very quick, interesting intro about yourself. Good to know that you are a movie buff. And now like, let’s, let’s move on to the main section. So just for the audience, they know, uh, we’re going to talk about DevEx, dev productivity, which is Vilas’s main area of expertise. And his, his quote from my last discussion with him was that DevEx is not just, uh, some tools being brought in, some dev productivity tools being brought in. So I think with that note, uh, let’s get started, Vilas.
Vilas Veeraraghavan: Sure.
Kovid Batra: What according to you defines DevEx? Like let’s start with that first basic question. What is DevEx for you?
Vilas Veeraraghavan: Okay. So before I jump into that, I want to give you, give the context behind that statement I said, right? Um, it’s not about throwing tools at someone and expecting that things will get better. Um, I learnt that over time, right? I was a big fan of automation and creating tools to help people, and I would often be surprised by why people are not using them the way I thought they should. And then I realized it’s about the fact that their process that they are following today does not allow them to include this. There is too much friction that brings that. If they bring in a new tool, it’s too much friction. And then I realized also what the people, about management, all of that stuff. So it’s a very, it’s a, it’s a multidimensional problem. And so that, I just want to set that context because that’s how I defined DevEx, right? DevEx or I, as I like to call it more about dev enablement, is about making sure that your developers have the best possible path through which they can deliver features to production. Right? And so it’s, it’s not about productivity. I think productivity is inherent in the fact that if you enable someone, uh, you are providing them with the shortest paved road kind of thing to get to their destination. They will become productive. Uh, it’s sort of, uh, automatic extrapolation, if you will, from that. So that’s the reason why I, that’s how I defined DevEx. Um, but it’s important because that’s how, that was my journey to learn as well.
Kovid Batra: So I think, uh, before the discussion started, we were talking about how you got into this role and how DevEx came into play. So I think, uh, let audience also hear it from you. Like, we know like DevEx is a very new term. Uh, this is something that has been introduced very lately, but back in the day, when you started working on things, what defined DevEx at that time and how you got involved in it?
Vilas Veeraraghavan: Um, so back in the day when I started working in a software organization, the thing that drew me to, uh, what we would call ‘platform’ back then was the fact that there were a lot of opportunities to see quick wins from doing improvements for other teams. So for example, if I created something, if I improved something at the platform layer, it will not benefit one team. It will benefit all teams, multiple teams. And so the, the impact is actually pretty widespread and it’s immediate. You can see the, um, the joy of making someone happy. Like someone will come to you and say, “Oh, I was spending so much time and now I don’t have to do this.” Uh, so that drew me in, it wasn’t called DevEx. It wasn’t even called Dev Productivity at that time. Um, but this is I’m talking about like 2008, 2007–2008 timeframe. But then what happened over time was that, um, I realized that automation and creating the tools and all of that, uh, I realized how much of a superpower that can be for a company to have, uh, investment in that because it’s a multifold impact on how quickly people can get features. So how quickly you innovate, how efficient your engineering team is, how, um, excellent the, uh, how it says, the practices are within the engineering organization. They can all be defined by providing your engineers something that is, they can use every day and they don’t have to think and reinvent new ways and they don’t have to relitigate the same problem again and again.
Um, so that drew me in. Uh, so over time I’ve seen it evolve from just platform or like there used to be common libraries that people would write, which other companies, other teams would, uh, ingest and then they would release, uh, and we did not have, uh, continuous delivery. Uh, funnily enough, uh, we used to ship CDs, compact discs for those who are new to this process. Uh, so we would actually ship physical media over. So we would burn all the software on it and then we would ship it, um, to the data center and an admin would install it. So there was no concept of that level of continuous delivery, but we did have CI, and we did have a sense of automation within the actual pipeline, the software delivery pipeline. That is still valid.
Kovid Batra: There is one interesting question, like, uh, this is something that I have also felt, uh, coming from an engineering background. People usually don’t have, uh, an interest towards moving into platform teams, DevOps kind of things, right? You say that you are passionate about it. So I just want to hear it from you, like what drives that passion? Like you just mentioned that there is an impact that you’re creating with all the teams who are working there. Um, so is, is that the key thing or is it something else that is driving that passion?
Vilas Veeraraghavan: I mean, I feel like that is the key thing because I, I derive a lot of joy out of that, because I feel that when you make a change and sometimes, uh, the result, the impact of that change is not visible till it’s actually live and then people use it. I mean, for example, if you wanted to, let’s say you’re moving from a GitLab pipeline to, uh, using Argo CD for something or something like that. You’re doing a massive migration. It can be very troubling to look at it when you’re stepping back and looking at it as a big picture. But then when all of the change is done and you see how it has impacted, uh, you see how fast you’re running or you see, something like that, right? So I think it’s that, um, obviously is, which is a big motivator, but here’s the other thing, right? I think, uh, and this is a secret that I hope others also, uh, realize that it was right there all along. They just haven’t seen it. The secret is that by being in a space like DevEx, you actually solve multiple different domain, uh, domain areas, problems, right? So for example, at Walmart, I got deeply, I had a chance to deeply understand supply chain issues, like supply chain teams had issues that were different from maybe, uh, like teams that were doing more payment management. Uh, the problems are different, but when you look at the problem, uh, you have to understand deeply what that technology is. So you end up having a lot of really broad knowledge across multiple domain areas. And when you solve a problem for a domain area, you will be surprised to know, Oh, this actually solves it for five other areas as well. Right? So it’s, it’s a fascinating thing that I think people don’t realize immediately. So it feels less glamorous than something else, um, like a feature team maybe. Um, but in fact, it’s actually, in my opinion, uh, more powerful.
Kovid Batra: Got it. Is this the effect of working with large organizations particularly? Like, uh..
Vilas Veeraraghavan: It’s possible.
Kovid Batra: I’m not making any assumptions here but I’m just asking a question.
Vilas Veeraraghavan: Yeah. It’s possible.
Kovid Batra: Okay.
Vilas Veeraraghavan: Yeah, it is. I, I, yes. Uh, I, I will say that there is definitely a privilege that I’m, I should call out here, is that the privilege for me was to work, uh, in companies which allowed me the ability to like learn this, right? There was a lot of, um, bandwidth that was offered to me to learn all of this. Um, and Netflix was, is, is always good about a lot of transparency across organizations. Uh, so as an engineer, if you are working for a company like Netflix, you absorb a lot of information. And because you, if you’re curious, you can do more, you can do a lot, right? Um, obviously Walmart, fortune one, big, biggest company I’ve ever worked for. I think it’s, it is the biggest company in terms of size as well. Um, again, right, you have the ability to learn, uh, and you work your way out of ambiguity by defining structure yourself. Um, so same thing happens. I think I’ve been lucky in that way as well, um, to learn from all of these folks who worked there and obviously, amazing, talented people work in these places. So something, you keep hearing about it, you keep learning about it and then it makes you better as an engineer as well.
Kovid Batra: Makes sense. So, um, let’s, let’s deep dive into some of these situations where you applied your great brains around designing the platform teams, defining things for, uh, these platforms. So maybe, can you just bring up some examples from your journey at Netflix or Walmart or Bill.com where you had a great challenge in front of you? Uh, and what were the decision-making framework, uh, frameworks you, you, uh, basically deployed at that point of time and how things spanned out during the journey? So this might be a long question, but like, uh, I just wanted to, uh, dive into any one of those journeys if you, if you’re okay.
Vilas Veeraraghavan: Okay. I think we have had in the past, you’ve had Bryan Finster. So this was something that we traversed together along with many other people. Uh, we were all part of the same team, um, when we did this. Uh, so I’ll start with Walmart, uh, as an example. Um, I’ll, I’ll keep, keep it to sort of, I’ll go into generics and not give you specifics, but the challenge, uh, at a company like Walmart is that as a company, a big company, there is a lot of established practices, uh, a lot of established processes, established tools that teams use and businesses rely on, right? So each of these areas within the company is a business by itself. Uh, they are obviously wanting to get the best possible output for their customers. Uh, and they rely on a bunch of processes, tools, people, all of that, right? Um, if you now, going in, say that, “Hey, I’m going to introduce something that’s brand new.” Or if you’re going to change something drastically, you are creating unnecessary churn and unnecessary friction within the system, right? So in order for us to think about how we wanted to do dev enablement within Walmart, it is important to understand that you had to address the friction, right? If you are providing a solution that is replacing existing solution and doing just enough, that’s not going to cut it. It has to be a sea change. It has to be something that significantly changes how the company does software delivery, right? Uh, and so, one thing I’ll say is that I was very lucky to work for someone and for like leaders at Walmart that also understood this at that time. Um, so, for all those who are in the process right now, you cannot do it unless your leadership has that, you have buy in from that leadership, you have sponsorship from your executive teams. Uh, that helped us a lot.
Now, once you have buy in, you still have to produce something that is of value, right? And so that is where I’m saying this thing is important. So initially, uh, in my mind, uh, naively, my expectation was we build some amazing tools, right? And then we provide that to these teams and of course, they’ll be super happy, uh, the word of month will spread and that’s it. Right. All done. Um, what I found was in order to solve a problem where engineers were spending a lot of time doing toil, right? Like they were doing a lot of manual processes or repeated, uh, work throwing a tool at them was actually exacerbating the cognitive load problem, right?
Kovid Batra: Yeah.
Vilas Veeraraghavan: So now, while they maintain existing solutions, they have to now learn something new, migrate it, then convince their leaders and their teams to say, “Yeah, this is how we have to do things.” And then move forward. So you’re making that problem worse, that bandwidth problem, which is I’m a developer. I have certain amount of time to spend on feature delivery. I don’t have time for everything. So now I’m squeezing this into my, like 20 percent time, on my own free time outside of work to learn what this new thing is about. What that meant is that adoption would not succeed. So if adoption doesn’t succeed, then obviously, if your customers are not using you, you’re not, you’re a failed product, right? So what we realized was there are two other aspects to it that we had not thought about. One was process and the other one was people, right? So when I say people, I mean it could be management, it could be a key opinion leader within the space, right? That’s what we attacked. And you can obviously ask Bryan more about it. He is, he’s, he knows all about it. But the way that we attacked it was we created programs which were more grassroots, like more bottoms up view of saying, “Hey, we are starting to use these new tools. Come join us as we learn together. Let’s discuss what problems we have. Let’s talk about successes that we have. Let’s talk about how we want to do this well.” And we were open to feedback. So, inside my organization, uh, which is the dev enablement area, there was also a product organization. Uh, so we had product owners with each of the teams that are building these tools and the product owners had a pulse on the customer’s need.
So that is, that is how we found success over time. We did not obviously succeed at the start, and there was obviously, a lot of challenges we had to work through, but what happened is adoption only kicked up when we saw that we were able to, one, provide a solution that is X times better than where we were, right? So if you were to, if you were maintaining configuration, if you’re meeting five config, uh, different configs, now we just have to meet in one YAML file and that’s checked into GitHub or something like that, right? That’s a big difference productivity-wise. lesser errors. Uh, second thing is how many times do I have to look at the build? Uh, and then security review after the build and all that. So you say, okay, let’s do security scanning before the build. Uh, so even before you build a binary, you know if it’s safe to build it based on your code scan. Uh, things like that we did to improve the process itself. And then we educated our teams about it. All of our teams. We upskilled them. We gave them a chance to upskill themselves by giving them lots to, lots of references. We showed them like what the industry standards are. By showing them what the industry standards are, you created a need inside them say, “Hey, we need to be like that, right? Like, why can’t we do this?” And so that essentially became a motivating factor for most teams and most managers and directors and VPs started saying, “Hey, I want all of my teams to do exactly that.” Right. We need to be that kind of a team. And that introduced a lot of sort of gamification, right? Because when we, when you look at dashboards that look slick, right, and you’re like, “Hey, why can’t I do this? Why can’t my team do this?” It created a very natural tension, a very natural competition within the company, which served adoption well. Once the adoption was starting to grow and beyond a certain threshold, it became a very natural, or we didn’t have to go asking for customers, customers came looking for us. And so, that’s how we got to the point where there was more uniformity in how software is delivered.
Kovid Batra: Perfect. So I think it’s more around defining the right problem for the teams that you’re going to work with, defining a priority on those problems, how you were like very swiftly slide into their existing system so that the adoption is not a barrier in the first place itself. So the basic principles of how you bring in a product into the market. Similarly, you just have to..
Vilas Veeraraghavan: It is the exact same.
Kovid Batra: Yeah.
Vilas Veeraraghavan: Uh, platform, dev enablement, tooling, all of this. These are all products. Your developers are your customers. If your customers are not happy and they don’t use you, um, yeah, you are a failed organization then. That’s how it is. Right. So if you, if you feel like, um, just because you are part of a DevEx team, uh, what you say has to be the law of the land, it doesn’t work that way, right? The customers vote with their, with the time that they give you. Uh, and if that, if you find if, let’s say in an organization, you see that there are some tools that’s been released by the developer productivity or DevEx or enablement or platform engineering organization, but most people are using workarounds to do something. Then I hope the teams understand that there needs to be some serious change in the DevEx organization.
Kovid Batra: Cool. I’ll just go back to the first point itself from where you start. Is there any specific way to identify which teams are dealing with the most impactful problems right now and then you go about tackling that? Or it’s more like you are talking to a lot of engineering leaders around you and then you just think that, “Okay, this is something that we can easily solve and it seems impactful. Let’s pick this up.” How does that work?
Vilas Veeraraghavan: That’s actually a very, um, important thing to think about. And thanks for reminding me of that because I did ignore to say that. I didn’t say this the last time. Uh, you do need some champions and that’s why I said key opinion leaders, right? In the company, you need champions who can help do that early adoption and then find success. That comes from not just impact, which means, let’s say that someone is doing, uh, a hundred million dollars of business every year. Uh, and if they change something that they made to save a significant amount of money, that can be big impact, but it’s also about what their ambition is. So if I am a hundred million dollar business, but my ambition is I want to be a hundred million dollar business next year as well. They may not be able to be the, uh, they may not be the person who’s pushing at the boundaries, right?
Kovid Batra: Got it.
Vilas Veeraraghavan: They may be saying, “Oh yeah, it’s fine. I mean, everything is working just fine. I don’t want to break anything. I don’t want to touch anything. I don’t want to innovate. Let’s keep going.” But on the other hand, you will see, and this is common in many big companies is there’ll always be pockets of rapid innovation, right? And so, these folks who are in that space and their decision makers in those spaces, uh, them having a discussion with it, a really deep discussion, a very open discussion with them, uh, almost like a partnership, right? Saying, “Hey, I’m building this tool. Let’s imagine you have to use this tool. What would you want me to change in this so that it fits you?” And obviously, you’re going to take all of their input and decide which ones will be more useful to others as well. You’re not going to obviously, build something for just one team, but at the same time you get to know, like, you know, what is it that, what is it that is not getting them to adopt this right now? So you do need a set of those key opinion leaders very early in the process because they are also not just going to influence their team; they are going to influence other teams. And that’s how the word of mouth is going to spread. So that’s the first step. So it’s not just impact; its impact with ambition, which is where..
Kovid Batra: There should be some inherent motivation there to actually work on it, only then..
Vilas Veeraraghavan: I will, I will say one other thing, Kovid. Like if there is someone that, if there’s a team that doesn’t necessarily have ambition, but it’s doing more of a top-down, like get this done, right? I have often found that, uh, by leaders saying, get this done, it can sometimes backfire because the team feels like it’s an imposition on them. They may be very happy with their current state of tools, but it’s an imposition. Like now, why do you have to change this? Everything works just fine, right? You always have that inertia, like people, everyone doesn’t want change, and sometimes change might not be needed either. You might actually already be efficient, right? But that top-down approach doesn’t always work, which is why for us, I will say this, that for me, the greatest learning was how and seeing how much the bottoms-up approach worked at Walmart was actually very encouraging because I realized that you have to convince an engineer to see this for themselves. So it is very, that’s why I think opinion leaders are not necessarily VPs or they could be, it could be someone who’s well-respected in an area. It could be someone who is, um, like a distinguished engineer, uh, right, whose word carries a lot of value within an organization. Those are the, those are the people who, who tend to be those key opinion leaders, right? Uh, so top-down also doesn’t work. You can’t just be like, uh, your VP is ambitious, but you are not. That, that, that doesn’t work either.
Kovid Batra: Makes sense. Makes sense. All right. So I think when you have defined the team priority problem that you need to solve, then you start hustling, start building, of course, that phase has to be of a lot of to and fro, patience, transition, MVPs. Anything from that phase of implementation that came out to be a great learning for you that you would like to share?
Vilas Veeraraghavan: I’m thinking there was obviously a lot of learning. Uh, we, it was not, it is never a straight path, right, uh, when, when you’re doing something like this. But I think one thing that I, uh, evolved, uh, during that time was at the start, uh, I was definitely operating in a bit of a, “But this is the best way to do it.” Like I was, we were so convinced that there is no other way, but this to do it. That, uh, slight arrogance sometimes leads you down a path where you’re not listening to what people are saying, right? If people are saying, “Hey, I’m facing this pain.” And you’re hearing that across different organizations, different areas, and you dismiss it as, “Oh, it’s just a small thing. Don’t worry about it.” Right? That small thing can snowball into a very big problem that you cannot avoid, eventually. What I learned over time was I used to go into meetings being very defensive about what we already created and what, because the way I would look at it is, “Oh, well, that team can do it. Why can’t you?” And, uh, that was very naive at that time. But then I realized, uh, one of those meetings I went to, I, for some reason, I basically said, “Okay, fine. Tell me exactly how you would have solved the problem.” Maybe I was annoyed. I don’t know what, but I said, “Okay, how would you solve the problem if you were doing this?” And that person was so happy to hear that. And that person actually sat down with me for the next two hours and designed exactly how things could have been better, all of that. Like they, and I went, I was happy to go into detail, but it made me realize these are actually all allies that I should be adding to my list, right, as opposed to saying, “No, no, you have to use this. Like, what? Go away.” I, I, that was a big mistake I did. I probably did that for like six months. I, I will say that that was a bad idea. Uh, don’t do it. Uh, but after that it was, I, I was able to, the team was able to flourish because everyone saw us as partners in this thing, right?
So then we would go and we would say, “Okay, fine. You have this tool that we built, but don’t think about that. Think about what is the ideal tool that you need and let’s find out how much of this, this satisfies, right. And then whatever it doesn’t, we will accept that as feedback. And then we’ll go back and we’ll see and think about it and all that. And we will share with you what our priorities are. You tell us if this is making sense to you or not, and then we’ll keep this communication going.” That is a big evolution.
Kovid Batra: I totally relate to that. But I haven’t been like being back and forth on this thought of bringing in opinions and then taking a decision rather than just taking a decision and then like pushing it. I think it’s the matter of the kind of people you’re working with. You have to make a wise choice that whom you want to listen to and whom you don’t want to. Both things can backfire. I’ve actually experience both, uh, the same happened.
Vilas Veeraraghavan: Oh yeah. You don’t want to. Yeah, obviously, what, it goes without saying that there is gonna be some people who are, uh, giving you the right advice, right? And some people are just complaining because they are complaining. That’s it.
Kovid Batra: Yeah.
Vilas Veeraraghavan: Right? Uh, oh yeah, you have to separate that. But I’m saying there’s two ways to do this, right? Like when you, when you find that initial adoption starts hitting and all that, you can’t go into your shell and be like, “Okay, that’s it. My job is done. People will keep.” So that is what we, I felt like over a brief amount of time, right? When we said, “No, it’s all working just fine. Like, why do you, what are you complaining about?” And then I realized, I don’t know if maybe other folks in my team realized it earlier, but I realized it as a strategy. We needed to change that. And that put a very different face on our team because our team then started getting welcomed into meetings, which we originally were never a part of. It allowed us to see, uh, into their decision process because they were like, “Oh no, it’s important for you to know this because there is a lot of dependency on tools. We can’t change this process, but maybe we can adjust the tools and the settings to help us with this.” Right? So it was a very different perspective. And that learning, I was able to carry it into like other, uh, other initiatives, projects, companies, all of that. It has definitely served me well. Even now, if I’m listening to someone, I’ll usually say, “What would you do if you were in this space?” Right. And then let’s talk about it. Right. Very open. Um, but it is, it is important to have ego outside.
Kovid Batra: Yeah, totally. So I think it’s a very good point you just mentioned, like, uh, taking that constant feedback in some or the other form. But when you’re dealing with large teams, large systems, uh, I have got a sense that you need to have a system in place along with 1-on-1s and discussions with the people. So I’m sure you are focusing on making the delivery, uh, more efficient, faster, the quality should be better, less of failures, right? At the beginning of a journey, let’s say, any project, there must be something, some metrics that you define that, “Okay, this is what the current scenario is. And during the phase, these are our KPIs which we need to like look at every time, every 15 days or 30 days.” And then finally, when you are putting an accomplishment mark to your change that you have brought in, there is a goal that you must be hitting, right? So during this whole journey, what were your benchmarks? What were your ways of evaluating that system data? So that you are always able to like, most of the time it’s like, it’s for our own benefit. Like we know things are working or not. And at the same time you’re working with so many teams, so many stakeholders, you have some factual things in front of you saying, “Okay, this is what has changed.”
Vilas Veeraraghavan: Sure. Um, I’ll say this, um, we, the team used to do regular road shows, which means we would go around to different teams. We would have weekly and monthly meetings where we would showcase what’s coming, what’s happened, how this is a fit for, and we would try to always do something where you would demo this with the team that you’re talking to. We will demo it with something that they are doing, right, saying, “Hey, look, this is a build that you wanted to run. You want it to slow down all that. So you wanted it to speed up and it’s slow right now. This is how much we sped it up and all that.” So that is a roadshow thing. The reason I’m mentioning that is because that brings me to the metrics, right? Metrics, when we started, um, in the sense of day-to-day metrics, um, evolved over time, uh, till like, when I left, right? In the sense that at the very start, our metric was adoption, obviously, when we started creating the tool and sending it out. So for us, for us, it was an option. The mission statement for us was we wanted to get code into production in less than 60 minutes. So this was, when I say ‘code to production’, it is not just any code. It’s code that is tested. So, uh, which means we, we had to build it fast. We had to run unit tests. We had to run integration tests. We’ve also, uh, intended to run performance evaluation, performance testing, right? And then deploy it without having to go trouble the, the, the team again for details, right? Deploy it or, or at least make it ready to deploy. And then you obviously, have some gate that will say, “Okay, ready to deploy. Check.” Someone checks it and then it goes to product, right? We wanted this process to take 60 minutes or less. So that was the very mission statement kind of thing.
Kovid Batra: Got it, got it, yeah.
Vilas Veeraraghavan: But the metrics evolved over time. So initially, it was adoption, like how many people are using this tool? Um, it was about, uh, some common things, for example, um, a lot of folks within Walmart were using different code repositories, right? All of them, because they’re maintained by different parts of the organization. But because we unified those, we started checking, okay, is everything in one place? What is this amount of code that is maybe not in a secure space? Or something like that. Like that became an open thing to share. And we got a lot of partnership from our sister teams in InfoSec, in, uh, like all of these compliance areas, they started helping us a lot because they established policies that became metrics for us to measure. So just like I said, how secure is the code base? That is a great policy saying, “We need to have secure codebases that do not have high-level and medium-level vulnerabilities.” That meant we could measure those by doing code scans and saying, “Okay, we still have these many to go. We can point out exactly what teams need to do what.” And then we would slide in our tool saying, “Hey, by the way, this tool can do it for you if you just did this.” And so, immediately, it affected adoption, right? So, so that is how we started off with metrics.
Uh, but over time, uh, as we consolidated our, the space, we realized that, uh, I mean, once adoption was at like a 75, 80 percent kind of thing, we realized that we didn’t need to track it. I mean, then it’s like diminishing returns. It’ll take its time. The long tail is long. It’ll take time. Uh, at that time we switched, uh, to looking at more efficiency metrics. So which means we wanted to see how much is the scale costing us as a team. Like, are we scaling well to handle the load of builds that are coming to us, right? Are we, are the builds slowing down week over week for other teams, right? Things like that. So that is how we started seeing it because we wanted to get a sense of how much is the developer spending on things like long builds. So if you’re spent, if you’re like, “Oh, I start this build and I have to go away for an hour and come back.” It is a serious loss of productivity for that person. The context switch penalty is high, right? And when you come back, you’re like, “I forgot what I was even doing.” So we wanted to minimize that. So it became about efficiency metrics and that led to the goals and the strategy that we had to decide for the next year. Okay, we need to fix this one next time. So it was an adoption as much as saying, “Okay, make sure that we are still continuing on the, uh, what is the roadshows and things like that, but we’ll shift our attention to this.” So in the roadshows, we will call out those metrics. So you would start the discussion with saying, “Here is where we are right now.” There were publicly accessible dashboards, which is another thing that we believed truly as a DevEx team or a dev enablement team is every action that we take is very public. In a sense, it should be to all the organizations, public to the organization because that’s our customer, right? So we need to tell them exactly where we do, what we’re doing. The investment in money comes from these people, right? The other VPs or the execs are sponsoring this. So they need to see where their money is going. And so it was like transparency was key, and that’s why metrics were helpful. We showed them all the way from adoption to tuning to efficiency. That’s how sort of the thing went.
Kovid Batra: Cool. I think this was really, really interesting to know this whole journey, the phases that you have had. Just in the interest of time, I think we’ll have to just take a pause here, but, uh, this was amazing, amazing discussion that I’ve had with you. Would you like to share a parting advice or something for people who are maybe stepping into this role or are into this role for some time, anything you want to share with them?
Vilas Veeraraghavan: I want to, first of all, thanks, Kovid. This is, this is great. Uh, I, I really enjoyed this conversation. Um, and I also appreciate the curiosity you had, uh, to have this discussion in the first place. So, thanks for that. Um, message is simple, right? I don’t know how this happens, but DevEx never used to be cool in the past, right? In a sense that DevEx felt like one of those things that people would say, “Hey, you’re doing DevEx. You’re not necessarily releasing features.” But in reality, there were tons of features that, that the feature teams needed to deliver their features that we had to create before they did this. DevEx teams needed to be three to six months ahead of where the feature teams are so that when it comes to delivery, feature teams are not waiting on tools. We have to be giving it ready. So I believed it was cool back then, but I’m very happy to hear that DevEx is actually turning cooler because there is a lot of industry backing about it, right? Like, so there’s a lot of push, a lot of people talking about it, like yourself, uh, and we, like, we are doing right now. My only advice is, for those who are interested in it, I would suggest at least speaking to the right people so you know what the opportunities look like, right, before you say no. That’s all I ask.
Kovid Batra: Perfect. All right, that’s our time. Bye for now. But we would love to have you on another episode talking more about DevOps, DevX, dev productivity. Thanks, Vilas. Thank you for your time.
Vilas Veeraraghavan: Yeah. Thanks, Kovid. I’m happy to return anytime.
In this DORA exclusive webinar, hosted by Kovid from Typo, notable software engineers Dave Farley and Denis Čahuk discuss the profound impact of DORA metrics on engineering productivity.
Dave, co-author of 'Continuous Delivery,' emphasized the transition to continuous delivery (CD) and its significant benefits, involving systematic quality improvements and efficient software release cycles. Denis, a technical coach and TDD/DDD expert, shared insights into overcoming resistance to CD adoption. The discussion covered the challenges associated with measuring productivity, differentiating between continuous delivery and continuous deployment, and the essential role of team dynamics in successful implementation. The session also addressed audience questions about balancing speed and quality, using DORA metrics effectively, and handling burnout and engineering well-being.
Kovid Batra: All right. So time to get started. Uh, thanks for joining in for this DORA exclusive webinar, The Hows and Whats of DORA session three, powered by Typo. I am Kovid, founding member at Typo and your host for today's webinar. With me today, I have two extremely passionate software engineers. Please welcome the DORA expert tonight, Dave Farley. Dave is a co-author of award-winning books, Continuous Delivery, Modern Software Engineering, and a pioneer in DevOps. Along with him, we have the technical coach, Denis Čahuk, who is TDD, DDD expert, and he is a stress-free high-performance development culture provider in the tech teams. Welcome to the show, both of you. Thank you so much for joining in.
Dave Farley: Pleasure. Thank you for having me.
Denis Čahuk: Thank you for having me.
Kovid Batra: Great guys. So I think we will take it one by one. Uh, so let's, let's, let's start with, uh, I think, uh, Dave first. Uh, so Dave, uh, this is a ritual that we follow on this webinar. You have to tell us about yourself, uh, that your LinkedIn profile doesn't tell. So you have to give us a quick, sweet intro about yourself.
Dave Farley: Okay. Um, I'm a long-time software developer who really enjoys problem-solving. I really enjoy that aspect of the job. I, if you want, if you want to get me, get me to come and work at your place, you tell me that the problem's hard to solve. And that's, that's the kind of stuff that I like, and I've spent much of my career doing some of those hard to solve problems and figuring out ways in which to make that easier.
Kovid Batra: Great. All right. So I think, Dave, uh, apart from that, uh, anything that you love beyond software engineering that you enjoy doing?
Dave Farley: Yeah, my wife says that my hobby is collecting hobbies. So, so I'm, I'm a guitarist. I used to, I used to play in rock bands years ago. Um, I, until fairly recently, I was a member of the British aerobatics team, flying competition aerobatics in a 300 horsepower, plus 10, minus 10 G, uh, aerobatic airplane, which, which was awesome, but, uh, I don't do that anymore. I've stopped very recently.
Kovid Batra: That's amazing, man. That's really amazing. Great. Thank you. Thank you so much for that, uh, intro about yourself and, uh, Denis over to you, man.
Denis Čahuk: Um, like Dave, I really like problem solving, but, but I like involving, uh, I spent the beginning of my career in focusing too much on the compiler and I like focusing on the human problems as well. So how, what, what makes the team tick and in particular with TDD, it really, really scratched an itch about what makes teams resistant and what makes teams a little bit more open to change and improvement and dialogue, especially dialogue. Uh, that has become my specialty since. So yes, I brand myself as a TDD, DDD coach, but that's primarily there to drive engagement. I'm, I'm super interested in engineering leadership and specifically what drives trends and what helps people, what helps, uh, engineers, engineering teams overcome their own resistance, sort of, if they're in their own way, you know, why is that there, how to, how to resolve any kind of, um, blockers, let's say, human blockers, not, not, not the compiler kind, uh, in engineering things. I don't plan any planes, but I do have, I do share, uh, Dave's passion for music. So I do have a guitar and, uh, the drum there behind me. So whenever I'm not streaming or coding, I am jamming out as much as I can.
Kovid Batra: Perfect. Perfect, man. All right. So I think it's time we get started and move to the, to move to the main section. Uh, so the first thing that I love to talk to you, uh, Dave first, uh, so you have this, uh, YouTube channel, uh, and it's not in your name, right? It's, it's Continuous Delivery. Uh, what, what makes Continuous Delivery so important to you?
Dave Farley: Somebody else said to, this to me very recently, which, which I agree with, which is that I think that Continuous Delivery, without seeming too immodest, because my name's associated with it, but I think it represents a step change in what we can do as software developers. I think it's a significant step forward in our ability to create better software faster. If you embrace the ideas of continuous delivery, which includes things like test-driven development, in DDD, as Denis was describing, and is very team-centered as well, which Denis was also talking about. If you, if you embrace those ideas and adopt the disciplines of continuous delivery, which fundamentally, all devolve into one idea, which is working software is always in a releasable state, then you get quite dramatically better outcomes. And I think without too much fear of contradiction, continuous delivery represents the state of the art in software development. It's what the best organizations at software development do. And so, I think it's an important idea and it's as I said, although I sound rather immodest because I'm one of the people that helped at least put the language to it, but people were doing these things, but Jez, Jez and my book define the language around which continuous delivery talking is usually structured these days. Um, and so, so I think it's an important idea and I think that software engineering is one of the most important things that we do in our society and it matters a lot and we ought to be better at it as an industry and I think that this is how we get better at it. So, so I get an awful lot of job satisfaction and personal pleasure on trying to help people on their journey towards achieving continuous delivery.
Kovid Batra: And I think you're being just modest here. Your book just didn't define or give a language there. It did way, way more than that. And, uh, kudos to you for that. Uh, I think my next question would be like, what's that main ingredient, uh, that separates a team following CD and a team not following CD? What do you think makes the big difference there?
Dave Farley: There are some easy answers. Let me just tackle the difficult answer first, because I think the difficulty with continuous delivery is that the idea is simple, but it's so challenging to most people that it's very difficult to adopt. It challenges the way in which we think about software. I think it challenges to some degree. I'm a bit of a pop psychologist. I think in many ways it challenges, um, our very understanding of what software is to some extent, and certainly what software development is. And that's difficult. That means that it changes every person's role in undertaking this. It, as I said already, it's a much more team centered approach, I think, uh, to be able to achieve this permanent releasability of our software. But fundamentally, I think if you want to boil it down to more straightforward concepts to think about, I think that what we're talking about here is kind of applying what I think of as a kind of scientific rationalism to solving problems in software. And so the biggest part of that, the two biggest ideas there, from my point of view, are working in small steps and essentially, treating each of those steps as a little experiment and assuming that we're going to be wrong. So it's always one of the big ideas in science is that you start off assuming that your ideas are wrong, and then you try and figure out how and why they're wrong. I think we do the same thing in continuous delivery and software engineering, modern software engineering. We try to figure out how can we detect where our ideas are wrong, and then we try and detect where they're wrong, in those places and find out if they're wrong or not and then correct them. And that's how we build a better software. And so this, I think that goes quite deep and it affects quite a lot about how we undertake our work. But I think that one of the step changes in capability is that I think that previous thinking about software development kind of started off from the assumption that our job is to get everything perfectly right from the start. And that's simply irrational and impossible. And so, instead of taking a more scientific mindset and starting off assuming that we will be wrong, and so we give ourselves the freedom to be wrong and the ability to um, recover from it easily is almost the whole game.
Kovid Batra: Got it. I think Denis has a question. He wants to, yeah, please go ahead.
Denis Čahuk: Sure. I'm going to go off script. I think I like that distinction of psychologist. Sometimes I feel myself, find myself in a similar role. And I think the core disagreement comes from this idea of a lot of engineers, organizational owners, CTOs don't like this idea that their code is an experiment. They want some like certain assurances that it has been inspected and that it's, it's not, it's not something that we expect to fail. So from their perspective, non-CD adopters think that the scientific rationale is hard inspection towards requirements rather than conducting an experiment. And I see that, um, sort of providing a lot of resistance regarding CD adoption cause it is very hard to do, or it's very hard to come from that rationale and say, okay, we're now doing CD, but we're not doing CD right now. We're adopting CD right now. So we're kind of doing it, but not doing it. And it just creates a lot of tension and resistance in companies. Did you find similar situations? How do you, how do you sort of massage this sort of identity shift identity crisis?
Dave Farley: Yeah. Yeah I think, I think absolutely that's a thing and, and that is the challenge. It is that is to try and find ways to help those people to see the light. So I know I sound like an evangelist. Yeah, but, but I guess I see that as part of my role. But..
Denis Čahuk: You did write the book, so..
Dave Farley: Yeah, so, so, so I think this is in everybody's interest. I mean, the data backs me up. The DORA data says that if you adopt the practices of continuous delivery, you spend 44 percent as an organization more time on building new features than if you don't. That's pretty slam dunk in terms of value as far as I'm concerned, and there's lots more to it than that. But, you know, so why wouldn't anybody want to be able to build better software faster? And this is the best way that we know of so far, how to do that. So, so that seems like a reasonably rational way of deciding that this is a good idea, but that's not enough to change people's minds. And you've got to change people's minds in all sorts of different ways. Um, I think it's important to make these sorts of things, but going back to those people that you said that, you know, engineers who think it's their job to get it right first time, they don't understand what engineering is. Managers who want to build the software more quickly, get more features out. They don't understand what building software more quickly really means because if either of those groups knew those things, they'd be shouting out and demanding continuous delivery, because it's the thing that you need. We don't know the right answers first time. Look at any technology. Let alone any product and its history. Look at the aeroplane. In the first aeroplane that could carry a person under power in a controllable way was the Wright Flyer in 1903. And for the first 20 or 30 years, all aeroplanes were death traps. People were, they were such dangerous devices. But engineering as a discipline adopted an incremental approach to learning and discovery to improve the airplane. And by 2017, two thirds of the planet, the equivalent of two thirds of the population of the planet, flew in commercial airliners and nobody was killed. That's what engineering does. It's an incremental process. It doesn't, we don't, we never ever, ever get it right first time. The iPhone, the first iPhone didn't have an app store, didn't have a camera, didn't have Siri, didn't have none of these things, didn't..
Denis Čahuk: Multitasking.
Dave Farley: Didn't have multitasking, all of these things. And now we have these amazing devices in our pockets that can do all sorts of amazing things that the original designers of the iPhone didn't actually predict. I'm sure that they had vague wishes in their minds, but they didn't predict them ahead of time. That's not how engineering works. So the way that engineering works is by exploration and discovery. And we need to, to be good at it, we need to organize to be good at exploration and discovery. And the way that, you know, so if we want to build things more efficiently, then we would, we need to adopt the disciplines that allow us to make these mistakes and accept that we will and look, you know, detect them as quickly as we can and learn from them as quickly as we can. And that's, you know, that's why, to my mind, you know, the results of the DORA thing, so there's no trade-off between speed and quality because you work in these small steps, you get faster feedback on, on whether your ideas are good or bad. So those small steps are important. And then when you find out that they're a bad idea, you correct them. And that's how you get to good.
Kovid Batra: Totally. I think, uh, one very good point, uh, here, we are sure like now CD and other practices like TDD impact engineering in a very positive way, improving the overall productivity and actually delivering value and the slam dunk like 44 percent more value delivered, right? But when it really comes to proving that number to these teams, uh, do you, like, do you use any framework? Do you use like DORA or SPACE to tell whether implementing CD was effective in a way? How do you measure that impact?
Dave Farley: No, most, mostly I recommend that people use the DORA metrics. Um, I, let me just talk momentarily about that because I think that that's important. I think the work of Nicole and the rest of the team in starting off the DORA was close to genius in identifying, as far as I can think of, the only generic measures in software. If you think about what, what the, the DORA metrics of stability and throughput measure, um, it's, um, the quality of the software that we produce and the rate at which we can produce software of that quality. That stability is the quality. Throughput is the efficiency with which we can produce software of that quality. Those are fundamental. They say nothing at all about the nature of the problem we're solving, the technology we're using, or anything else. If you're writing, if you're configuring SAP to do a better job of whatever it is that you're trying to do, that's still a good measure of success, stability and throughput. Um, if I'm writing some low-level code for an operating system, that's still a good measure of success. It doesn't matter. So, so we have these generic measures. Now they aren't enough to measure everything that's important in software. What they do is that they tell us whether we're building software right. They don't tell us whether we're building the right software, for example. So we need different kinds of experiments to understand other aspects of software. But I don't think there's much else. There's nothing else that I can think of that's in the same category. Stability and throughput in terms of the generosity of those measurements. And so, if you want a place to start of what to measure, start with stability and throughput and then figure out how to measure the other things out because they're going to be dependent on your context.
I'm a big fan of Site Reliability Engineering as a model for this. It talks in terms of, um, um, SLOs and SLIs, Service Level Indicators and Service Level Objectives. So the Service Level Indicator is what measure will determine the success of this service. So you identify, for every single feature, you identify what you should measure to know whether it's good or not. And then you set an objective of what score on that scale you want to achieve for this thing. That's a good way of measuring things, but it's kinda difficult. The huge difference is it's completely contextual, not even application by application, but feature by feature. So one feature might improve the latency, another feature might improve the rate at which we recruit new customers. And we've got to figure out, you know, that's how we get experimental with those kinds of things, by being more specific about and targeted with what we measure. I am skeptical of most of the generic measures. Not because I don't want them, it's just that I don't think that most of the others are generic and do what we want them to. Um, I'm not quite sure what I make of the SPACE framework, which is Nicole's new work on measuring developer, developer productivity. She's very smart and very good at the research-driven stuff. Uh, I spoke to her about some of this stuff on my, my podcast and, um, she had interesting things to say about it. I am still nervous of measuring individual developer productivity because as Denis said in his introduction, one of the really important things is how well a team works. So I think modern software development. unless it's building something trivial usually, is a team game. It's a matter of people coming together and organizing themselves in a way to be able to achieve some goal. And that takes an awful lot, and you can have people working with different levels of skill, experience, diligence, who may be still contributing strongly to the team, even if they're not pulling their weight in other respects. So I think it's a complicated thing to measure, a very human thing to measure. So, so I'm a bit suspect of that, but I'm fairly confident that Nicole will have some data that proves me wrong. But I, you know, that's, that's my position so far.
Kovid Batra: Totally makes sense. I think with almost all the frameworks, there have been some level of challenges and so is with DORA, SPACE, but I think in your experience, when, when you have seen, uh, and you have helped teams implement such practices, uh, what do you think have become the major reasons where they get stuck, not implementing these frameworks, not implementing proper engineering metrics? What, what, what stops them from doing it? What stops them from adopting it?
Dave Farley: I think specifically with using DORA, um, there are some complexities. If you, if you, if you are in a, a regular kind of organization that hasn't been working in the ways in which we've been talking about so far, um, then measuring stuff, just, just measuring stuff is hard. You're not used to doing it. The number of organizations that I talked to that couldn't even tell you how much, excuse me, time was spent on a feature, they don't measure it. They don't know. And so just getting the basics in, the thinking in, to be able to start to be a little bit more quantitative on these things is hard. And that's hard for people like us probably to get our heads around a little bit because when you've got a working deployment pipeline, this stuff is actually pretty easy because you just instrument your deployment pipeline and it gives you all the answers pretty much. So I think that there's that kind of practical difficulty, but I don't think that's the big ticket problem. The big ticket problem is just the mindset, my, I am old enough and comfortable enough in my shoes to recognize that I'm a grumpy old man. Um, and part of my grumpy old manness is to look at our industry and think that our industry is largely a fashion industry. It's not a technical industry. And there's an awful lot of mythology that goes on in the software industry. That's simply nothing to do with doing a good job. It's just what everybody thinks everybody else is doing. And I think that's incredibly common. And you've got to overcome that because if you're talking to a team, I'm going to trample on some people's sacred cow right now, but if you're talking to a team that works with feature branching, the evidence is in. Feature branching doesn't work as well as trunk-based development. That's more learning that we got from the DORA metrics, measuring those. Teams that work with feature branches build slightly lower quality code and they do it slightly more slowly than teams working on trunk. Now the problem is, is that it's almost inconceivable how you can do trunk-based development safely to people that buy into the, what I would think of as the mythology of feature branching. The fact that it, it, you can do it safely and you can do it safely at scale with complicated software, they start to deny because they assume that, that, that you can't, because they can't think of how you would do it. And that's the kind of difficulty that, that you face. It's not that it's a rational way of thinking about it, because I, I think it's very easy to defend why trunk-based development and continuous integration are more true, more, more, more accurate. You know, you, you organize things so that there's one point of truth. And in feature branching, you don't have one point of truth, you have multiple points of truth. And so it's clear that it's easier to determine whether the one point of truth is correct than deciding that multiple points of truth, that you don't know how you're going to integrate them together yet, is correct. You can't tell.
So it's, it's, it's tricky. So I think that there are rational ways of thinking that help us to do this, which is why I started, I've started to think about and talk about what we do as engineering more than as craft or just software development. If we do it well, uh, it's engineering and if we do it well and use engineering, we get a better result, which is kind of the definition of what engineering is in another discipline. If we work in certain ways, we do get better results. I think that's important stuff. So it's very, very hard to convince people and to get them away from their, what I would think of as mythologies sometimes. Um, and it's also difficult to be able to have these kinds of conversations and not seem very dogmatic. I get accused of being dogmatic about this stuff all of the time. Being arrogant for a moment. I think there's a big difference between being dogmatic and being right. I, I think that if we talk about, you know, having evidence like the DORA metrics, having a model like the way that I describe how these things stitch together and the reasons why they work and just having a favorite way of doing things, there's a difference between those things. I don't like continuous integration because it's my favorite. I like continuous integration because it works better than anything else. I like TDD not because I think it's my ideal for designing software. It's just that it's a better way of designing software than anything else. That's my belief. And, and so it's difficult to have these kinds of conversations because inevitably, you know, my viewpoints are going to be covered, colored by my experiences and what I've seen. But I try hard to be honest myself as an aspiring engineer and scientific rationalist. I try to be true to myself and try to critique my own ideas to find the holes in them. And I think that's the best that we can do in terms of staying sane on these things.
Kovid Batra: Sure. I think on that note, I think Denis would also resonate with that fact, because last time when Denis and I were talking, he mentioned about how he's helping teams implement TDD and like taking away those roadblocks time to time. So I'm sure Denis has certain questions around that, and he would like to jump in. Denis, uh, do you have any questions?
Denis Čahuk: I have a few, actually, I need your help a little bit to stay on topic. Um, so Dave mentioned something really important that sort of touched me more than the rest, which is this sort of concern for measuring individual performance. And I've been following Nicole's work as well, um, especially with SPACE metrics and what the team topology community is doing now with flow engineering. Um, there, there is a, let's say, strong interest in the community and the engineering intelligence community to measure burnout, to measure.
Dave Farley: Mm-Hmm.
Denis Čahuk: So, so the, so to clarify, do we have a high-performing team that's burnt out or do we have a healthy team that's low-performing? And to really, and to really sort of start course correct in the right areas is very difficult to measure burnout without being individual because of the need for it to be a subjective experience. Um, and I share Dave's concern where the productivity metrics are being put in the same bucket as the psychological safety and burnout research. So, I'm wondering when you're dealing with teams, because I see this with product engineering, I see this with TDD, I see this with engineering leaders who are just resistant to this idea of, you know, are we burned out? Are we just tired and we're following the right process? Or is the process correct, but it's being implemented incorrectly? How do you, how do you navigate this rift? I mean, specifically, do you find any quick, uh, lagging indicators from the DORA metrics to help you a little bit, like to cajole the conversation a little bit more? Um, or do you go to other metrics, like SPACE metrics, et cetera, to sort of, or surveying to help you start some kind of continuous delivery initiative? So a lot of teams who are not doing CD, they do complain about burnout when they're sort of being asked to start just measuring everything, just out of, um, out of, I would say, fatigue.
Dave Farley: Yeah, and, and, uh, and, uh, it gets to the, uh, Matt and Manuel's thing from the team, the Team Topologies guys, you know, uh, uh, description of cognitive load. I know it's not their, their, their idea originally, but, but, but applying it to software teams. It's, it, I, I think burnout is primarily a matter of, a mix of cognitive load and excessive cognitive load and the freedom to direct your own destiny within a team, you know? You need, you need kind of the Daniel Pink thing, autonomy, mastery and purpose. You need freedom to do a good job. You need enough scope to be, and, and that those are the kinds of things that I think are important in terms of measuring high-performance teams. I think that it's a false correlation. Um, I know that recent versions of the, the DORA reports have thrown up some, what seemed to me to be, um, counterintuitive findings. So people saying things like working with continuous integration has, is correlated with increased levels of burnout. That makes no sense to me. I put this to, to Nicole when I spoke to her as well, and she was a little skeptical of that too, in terms of the methodology for collecting the data. That's no, it's no aspersion on the people. We all get these things wrong from time to time, but I'm distrustful of that result. But if that is the result, you know, I've got to change my views on things. But my experience, and that's in the absence of, of hard data, except that previous versions of DORA gave us hard data and now the finding seems to have changed. But my experience has been that teams that are good at continuous delivery don't burn out, because it's, it's sustainable. It's long-term sustainable. The LMAX team that, that I led in the beginning of that team have been going, how long is it now? Uh, about 15 years. And those, those people weren't burning, people weren't burning out, you know, and they're producing high-quality software still, um, and their process is working still. Um, so I I'm not, I, I think that mostly burnout is a symptom of something being wrong. Um, and something being wrong in terms of too much cognitive load and not enough control of your own destiny within the team. Now, that's complicated stuff to do well, and it gets into some of the, for want of a better term, softer things, the less technical aspects of organizing teams and leading teams and so on. So we need leaders that are inspirational, that can kind of set a vision and a direction, and also demonstrating the, the right behavior. So going home on time, not, not working all hours and, you know, not telling people off if things go wrong, if it's not their fault, and all these kinds of things. So we need.. The best teams in my experience, take a lot of personal responsibility for their work, but that's, that's doing it themselves. That's not externally forced on them, and that's a good thing because that makes you both be prouder of the things that you do and more committed to doing a good job, which is in everybody's interest.
So, so I think there's, I think there's quite a lot to this. And again, it's, none of it's easy, but I think that shaping to be able to keep our software in a releasable state and working in small steps, gathering feedback, focusing on learning all of those techniques, the kind of things that I talk about all the time are some of the tools that help us to at least have a better chance of reducing burnout. Now that, there are always going to be some individuals in any system that get burnt out for other reasons. You get burnt out because of pressures from home or because your dog died or whatever it might be. Um, but, you know, we need, we need to treat this stuff seriously because we need to take care of people even if that's only for pragmatic commercial reasons, that we don't want to burn people because that's not going to be good for us long term as an industry. I, I, I, that's not more the primary reason why I would do it. But if I'm talking to a hard-nosed commercial person, I still think it's in their interest to treat people well. And so, and so we need to be cautious of people and more caring of people in the workplace. It's one of the things that I think that ensemble programming, whether it's pairing or mobbing, are significantly better for, and probably that's counterintuitive to many people, because there's a degree to which pair programming in particular applies a bit of extra pressure. You're a bit more on your game. You get a bit more, more tired at the end of each day's work, but you also build better friendships amongst your, your, your team workers and you learn from one another more effectively and you can depend on one another. If you're having a bad day, your, your, your pair might pick up the pace and be, you know, sustaining productivity or whatever else. There are all these kinds of subtle complex interactions that go on to producing a healthy workspace where, where people can keep at it for a long, you know, a long time, years at a time. And I, I think that's really important.
I worked at a company called ThoughtWorks in, in the early 2000s, and during that period, ThoughtWorks and ThoughtWorks in London in particular where I worked, where I think some of the thought leaders in agile thinking, we were pushing the boundaries of agile projects at that time and doing all sorts of interesting things. So we experimented a lot. We tried out lots of different, you know, leading edge, bleeding edge, often ideas in, in development. One of those, I worked on one of the early teams in London that was doing full-blown lean and applying that to software development. Um, and one of the things that we found was that that tended to, to, to burn us out a little bit over months because it just started to feel a bit like a treadmill. There was no kind of cadence to it because you just pick up a feature off the Kanban board, you'd work on that feature, you'd deliver the feature, you'd showcase the feature, you'd pick the next feature and you'd, and so on and so on and so on, and that was it. And you did that for months on end. And we were, we were, we were building good software. We were mostly having a good time, but over, over time it made us tired. So we started to think about how to make more social variants in the way in which we could do things. And we ended up doing the same thing, but also having iterations or most people would call them 'sprints' these days, of two weeks so that we could have a party at the end and celebrate the things that we did release, even though we weren't committing to what we'd release in the next two weeks. And, you know, we'd have some cake and stuff like that at the end, and all of those sorts of human things that just made it feel a little bit more different. We could celebrate our success and forget about our losses. Software development is a human endeavor. Let's not forget that and not try and talk, turn us into cogs in a machine. Let's treat us like human beings. Sorry. I'm off-road. I'm not sure if I answered your question.
Denis Čahuk: This is great. This is great, Dave. No need to apologize. We're enjoying this and I think our audiences as well.
Kovid Batra: I'm sure. All right. So, Denis, uh, do you have any other question?
Denis Čahuk: Well, I would like to follow up with what the story with the, with the ThoughtWorks story that Dave just mentioned You know, you mentioned you had evidence of high performance in that team. You know, we tend to forget that lean is primarily a product concern, not an engineering concern. So it sort of has to go through the ringer and to make sure, you know, does it apply to software engineering as well? And I have similar findings with things like lean, things like Kanban, particularly Scrum or the bad ways of doing Scrum is that it is, it can, it can show evidence of high performance, but not sustainably due to its lack of social component. And the retrospectives are a lame excuse at social components. It's just forcing people to judge each other and usually produces negative results rather than positive ones. So I'm wondering, you just mentioned this two-week iteration cycle for increments, but also you're leaning towards small batches. Are you still adamant on like this two-week barrier for social engagement? So, so, so what we There does seem to be a difference.
Dave Farley: Yeah, so, so, so what we did is that we retained the lean kind of Kanban style planning. We just kept that as it was, but we kind of overlaid a two-week schedule where we would have a kickoff meeting at the start of an iteration, and we would have a little retrospective at the end of an iteration and we, you know, we would talk about the work that we did over that period. So, so we had this, this kind of different cycle and that was purely human stuff. It wasn't even visible really outside of the team. It was just the way that we organized our work so that we could just look ahead for, for, for what's coming downstream as far as our Kanban board said today, and look back at what, what, what we'd, you know, what we delivered over the pre, you know, the previous iteration. It was just that kind of thing. And that was enough to give us this more human cycle, you know, because we could be, we could be looking forward to, so I'm releasing this feature, we're nearly at the end, you know, we'll talk about that tomorrow or whatever else it is, you know, and it was just nice to kind of reconnect with the rest of the team in that way. And it just, we used it essentially, I suppose you could pragmatically look at it as just as a meeting schedule for, for, for the team-level stuff. I suppose you could look at it like that, but it was, it felt like a bit more, more than that to us. But I've, by default, if I'm in a position to control these things, that's how I've organized teams ever since. And that, that's how, that's how we worked at LMAX where we built our financial exchange. That's the organization that's been going for 15 odd years, um, doing this real high-performance version of continuous delivery.
Denis Čahuk: But to pick your brain, uh, Dave, sorry to interject. When you said, you separated out the work cycles from the social cycles, that does involve daily deployments, right? Like daily pairing, daily deployments. So the releases were separate from the meeting, uh, routine.
Dave Farley: Yes. Yeah, so, so, so we, we were, we were doing the, we were doing the, the, the, the Kanban continuous delivery kind of thing of when a feature was finished, it was ready to go. So, so we were working that way. Um, there was some limitations on that sometimes, but, but, but pretty much that, that's a very close approximation have been an accurate statement, at least. Um, so, so we, we were working that way. Yeah. So we'd really, we'd essentially release on demand. We'd, we'd release when, you know, at every point when we were ready. And that was more often, usually, than once every two weeks. So the releases weren't, weren't forced to be aligned with those two week schedules. So it wasn't a technical thing at all. It was, uh, it was primarily a team social thing, but, but it worked. It worked very well.
Denis Čahuk: I really liked the brief mention about SPACE and Nicole's other work. Kovid and I are very active in the Google community. It's sort of organizing DORA-related events. And Google does have a very heavy interest in measuring well-being, measuring burnout, or just, you know, trying to figure out whether engineers and managers are actually really contributing or whether they're just slowing things down. And it's very hard to just judge from DORA metrics alone, or at least to get a clearer picture. Um, is there anything else you use for situational awareness? What would you recommend for either evidence of micromanagement, or maybe the team wants to do TDD, but there's sort of an anti-pairing stigma, if you have to, how would you approach, um, the sort of more survey-oriented, SPACE-oriented?
Dave Farley: From my experience, and I'm saying that with reservations, not with not, not, not boasting. I'm not saying because I've got great experience, but, but from my experience, I, I'm a little bit wary of trying to find quantity of ways of evaluating those things. These are very human things. So stuff like some of the examples that you mentioned, I, I've spent a significant proportion of my career as a leader of technical teams and I've always thought that it was a failure on my part as a leader of a technical team if I don't know, notice that somebody's struggling or that somebody's not pulling their weight or, or I haven't got the kind of relation, relationship where the team, if I, if I don't, if I don't know something, the team doesn't come and tell me and then I can help. I'm kind of in a weird position, for example, I'm in a slightly weird position in terms of career reviews. I think that as a manager or a leader, if you don't know the stuff that you find out in a review, you're not doing your job. You should be knowing that stuff all of the time. And it's kind of the Gemba thing. It's kind of walking around and being with the team. It's it's spending time and understanding the team as a member of the team because that's what you are. You're not outside it. You're not different. You're a member of the team, so you should feel part of that and you should be there to help, help people guide their careers and steer them in the right direction of doing better and doing, doing good things from their point of view and from the organization's point of view. But to do that, you've got, you've got to understand a little bit about what's going on. And that feels like one of those very, very human things. It's about empathy, and it's about understanding. It's about communication, and it's about trust between, between the people. And I'm not quite sure how well you can quantify that stuff.
Denis Čahuk: I coach teams primarily through this kind of engagement, to rebuild trust.
Dave Farley: Yes.
Denis Čahuk: So I have found I have zero success rate in adopting TDD if the team isn't prepared to pair on it.
Dave Farley: Yeah.
Denis Čahuk: Once the team is pairing, once the team is assembling, TDD, continuous delivery, trunk-based\ development, no problem. Once they're prepared to sort of invest time into each other, just form friendships or if nothing else, cordial acquaintances, sort of, we can sort of, bridge that gap of, well, I want you to write a test so that he can go home and spend time with his kids without worrying about deployment. So that, that is the ulterior motive, not that there is some like, you know, fairytale fashion metric to tick a box on.
Dave Farley: Yeah.
Denis Čahuk: Um, since you mentioned quantitative metrics, to sort of backtrack a little bit on that and tie it together with TDD, did you find any lagging indicators of a team that, that did adopt TDD after you came in that, you know, what, what are the key metrics that are getting better, different after TDD adoption, or maybe leading indicators or perhaps leading indicators that say, hey, this more than anything else needs attention?
Dave Farley: So, so, so, so I think, I think, I think mostly, uh, stability. So, so it's a lagging indicator, but I, I think that's the measure that, you know, tells us whether you're doing a good enough job on quality. And if you're not doing TDD, mostly the data says you're not doing a good enough job on quality. There's a lot of other measures that kind of reinforce that picture, but fundamentally in terms of monitoring our performance day-to-day, I think stability is the best tool for that. Um, and, you know, so, so some, you know, so there's, I, I, I'm interested as a technologist from a technical point of view in some of the work that, um, Adam Thornhill, uh, uh, and code scene are doing in terms of red code and things like that. So patterns of use in code, the stuff that changes a lot and monitoring the stuff that changes a lot versus this stuff that, you know, where, where defects happen and all that kind of stuff. And so, you know, the crossover between sort of cyclomatic complexity and other measures of complexity in code and the need to change it a lot and all that kind of stuff. I think that's all interesting and kind of, but I see that as reinforcing this view of how important quality is. And fundamentally, we need to find ways of doing less work, managing our cognitive load to achieve higher quality, and that's what TDD does. So TDD isn't the end in itself. It's, it's a tool that gives us, that pushes us in the direction of the end that matters, which is building high-quality software and maintaining our ability to change it. And that's, again, that's what TDD does. So, so, so I think that TDD influences software in some deep ways that people that don't practice TDD miss all of the time.
And it's linked to lots of other practices. Like you said, um, you know, pairing is a great way of helping to introduce TDD, uh, particularly for our people that already know how to do TDD in the team. That's, that's the way that you spread it, certainly, but it's, I can't, I can't think of many things that, that, as I say, I'm wary of measures. I tend to either use tactical measures that just seem right in the context of what we're doing now, sort of treating each thing as an experiment and trying to figure out how to experiment on this thing and what do I need to measure to, to do that, or I use stability and throughput primarily.
Kovid Batra: Uh, I'll just, uh, take a pause here for all of us because, uh, we have a QnA lined up for the audience. And, uh, we will try to take like 30, 30 seconds of a break here and, uh, audience, you can get started, posting your questions. Uh, we are ready to take them.
Denis Čahuk: We already have a few comments and we had, uh,
Kovid Batra: Okay. I think, uh, we can start with the questions.
Denis Čahuk: Before we go into Paul's question. Paul has a great question. I just want to preface that by saying that not this one, the DORA-related one.
Kovid Batra: But I like this one more.
Denis Čahuk: Yes.
Kovid Batra: Dave, I think you have to answer this one. Uh, where do you get your array of t-shirts?
Dave Farley: So, so, so mostly I buy my t-shirts off a company based in Ireland called QWERTEE. "QWERTEE". And if you go to, if you go to any of my videos, there's usually a link underneath them where you can get a discount off the t-shirts because we did a deal with QWERTEE because, because so many people commented on my t-shirts.
Denis Čahuk: Great t-shirts. Well done.
Kovid Batra: Yeah. Denis.
Denis Čahuk: I just wanted to, I just wanted to preface Paul's other question regarding how to measure that, you know, Kovid and I are very active in the DORA communities on the Google, Google group, and by far the most asked questions are, how do I precisely measure X? How do I correctly measure this? My team does not follow continuous delivery. We have feature branches. How do I correctly measure this metric, that metric? Before we go into too much detail, I just wanna emphasize that if you're not measuring, if you're not doing continuous delivery, then the metrics will tell you that you should probably be doing continuous delivery. And..
Dave Farley: Yeah.
Denis Čahuk: The ulterior motive is how can we get to continuous delivery sooner? Not how can we correctly measure DORA metrics and continue doing feature branching. Yeah, that's that is generally the most trending conversation topic on these groups. And I just want to take a lot of time to sort of nail, like the, it's about the business. It's about continuous delivery, running experiments quickly, smoother, safely, sustainably, rather than directly measuring any kind of dysfunctional workflow. Or even if you can judge that your workflow is bad because the metrics don't track properly, which is usually where people turn towards DORA metrics.
Dave Farley: Yeah, I would add to that as well is that even if you, even if you get the measures and you use the measures, you're still not going to convince people it's the measures enough alone aren't enough. You need, you need to approach this from a variety of different directions to start convincing people to change their minds over things, and that's without being disrespectful from those, of those people that differ in terms of their viewpoints, because it's hard to change your mind about something if you've, if you've made a career working in a certain way, it's hard to change the things that from the things that you've learned. Um, so this is challenging, and that's the downside of continuous delivery. It works better than anything else. It's the most fun way of organizing our work. It does tend to eliminate, in my experience, burnout in teams, all of these good things. You build better software more quickly working this way. But it's hard to adopt when you're not, when you've not done it before. Everybody that I know that's tried likes it better, but it's hard to make the change.
Denis Čahuk: It's a worthwhile change that manages a lot of stress and burnout, but that doesn't mean there aren't difficult conversations along the way.
Dave Farley: Sure.
Kovid Batra: All right, uh, moving on to the next one. Uh, how do you find the right balance between speed and quality while delivering software?
Dave Farley: The DORA metrics answer this question. There is no trade off, so there is no need to balance. If you want more speed, you need to build with higher quality. If you want more quality, you need to build faster. So let's just, let's just explain that a little bit because I think it's useful to just have this idea in mind because, because we have to defend ourselves because it seems, it seems like a reasonable idea that there's a trade off between speed and quality. It's just not true. But it seems like a reasonable idea. So, so if I build bad software this week and then next week, I've got a load more pressure on me to build next week's work, next week, I'm going to have all of that pressure plus all of the cost of the bad software that I wrote this week. So it's obviously more efficient if I build good software this week and then I don't have that work next week and then I could build good software next week as well. And what that plays out to is that that's where the 44 percent comes from. That's where the increase in productivity comes from. If we concentrate and organize our work to build higher quality software, we save time. We don't, we don't waste, we don't, it doesn't cost time.
Now there's a transition period. If you're busy working in a poor software development environment, that's building crap software, then, you know, it's going to take you a while to learn some of these things. So there's, there's an activation energy to get better at building software. But once you do, you will be going faster and building higher quality software at the same time because they come together. So what do we mean by fast when we talk about going fast if you want high quality software? Fundamentally, that's about working in smaller steps. So we want to organize our work into much smaller steps so that after each small step, we can evaluate where we are and whether what, whether that step that we took was, was a good one. And that's in all kinds of ways. Does my software do what I think it does? Does it do what the customer wants it to do? Is it making money in production or whatever else it is? So, so all of these things, you know, these are learning points and we need to build that more experimental mindset into the, in deep, into the way that we work.
And the smart thing to do. To optimize all of this is to make it easy to do the right things. It makes it, make it easy for us to carry out these small steps in these experiments. And that's what continuous delivery does. That's what the deployment pipeline fundamentally is for. It's an experimental platform that will give us a definitive statement on the releasability of our software multiple times per day. And that makes it easier then to, to work, to work in these small steps and do that quickly and, and get high quality results back.
Kovid Batra: Totally makes sense. Moving on, uh, Agustin, uh, why is it so, why is it so important in your opinion to differentiate between continuous delivery, continuous deployment, and how that affects the delivery process performance, also known as the DORA metrics?
Dave Farley: So, so, so, so let me first differentiate between them and then explain why I think it matters. So, so continuous delivery is working so that our software is always in a releasable state. Continuous deployment is built on top of continuous delivery. And if all of your tests pass, you just push the change out automatically into production. And that's a really, really good thing. If you can get, if you can get to that point where you can release all of the time small changes, that's probably the best way of getting this, optimising to get this really fast feedback, all the way out to your end users. Now the problem is, is that there are some kinds of software where that doesn't make any sense. There are some kinds of software for a variety of different kinds of reasons, depending on the technology, the regulation, um, real practical limitations for some reason, why we can't do that. So, Tesla are a continuous delivery company. But part of what they are continuously, continuously delivering is software embodied as silicon burnt into devices in the car. There's physics involved in burning the silicon. So you can't always release every change immediately that the software is, the software is done. That's not practical. So you have to manage that slightly differently. Uh, one of my clients, um, Siemens build medical devices and so, within the regulatory framework for medical devices that can kill people, you're not allowed to release them all of the time into production. And so, continuous delivery is the foundational idea but continuous deployment is kind of the, the limit, I suppose of where you can get to. If you're Amazon, continuous, continuous deployment makes a huge amount of sense. Amazon are pushing out changes. I think it's currently 1. 5 changes per second. It might be more than that. It might be five changes per second. Something like that. Something ridiculous like that. But that's what they're doing. And so they're able to move ridiculously fast and learn ridiculously quickly. And so build better software. I think you can think of it from a more internally focused viewpoint as that they each optimize for slightly different things.
Continuous delivery gives us feedback on whether we are, um, building things right and continuous deployment gives us feedback on whether we're building the right things. So we learn more about our product from continuous deployment by getting it into the hands of real users, monitoring that and understanding their impact. We get, and we can't get that kind of feedback any other way really than getting out to real users. We don't learn those lessons until real users are really using it. Continuous delivery though, gives us feedback on, does this do what we think it's doing? Um, is it good quality? Is it fast enough? Is it resilient enough? All of those kinds of things. We can measure those things. And we can know those before we release. So, they are slightly different things. And they do, they do balance off in different ways. They give us different levels of value. There's an excellent book that's recently been released on continuous deployment. Um, I've forgotten the name of the author. Valentina, somebody, I think. Um, but I wrote the foreword, so I should remember the name of the author. I'm very embarrassed, but it's, it's, it's a really good book, and it goes into lots of detail about continuous deployment as distinct from continuous delivery. I think, but I suppose I would say this, wouldn't I? I think that continuous delivery is the more foundational practice here, and I think that depending on your viewpoint, I think this is one of the very, very few ideas where, where Jez Humble and I would, would come at this from slightly different perspectives. I tended, I've tended to spend the latter part of my career working in environments where continuous deployment wasn't practical. I couldn't, I was never going to get my clients to, to, to do it in, in, in the environments in which they were building things. And sometimes they couldn't even if they wanted to. Um, I think Jez has worked in environments where continuous deployment was a little easier. And so that seems more natural. And so I think that kind of is why, um, some of the DORA metrics, for example, measure the efficiency based on assumptions, really, of continuous deployment.
Um, so I think, I think continuous deployment is the right target to aim for. You want to be able to release as frequently as is practicable, given the constraints on you, and you want to kind of push at the boundaries of those constraints where you can. So, for example, working with Siemens, we weren't allowed to release software into production of medical systems in clinical settings, but we could release much more frequently to non-clinical settings. So we did that, so we identified some non-clinical settings, and we released frequently to those places, in university hospitals, for example, and so on.
Kovid Batra: So I think it's almost time. Uh, and, uh, we do have more questions, but just because the stream is for an hour, uh, it's going to end. So we'll take those questions offline. Uh, I'll email the answers to you. Uh, audience, please don't be disappointed here. It's just in the interest of time that we'll have to stop here. Thank you so much, Dave, Denis, for this amazing, amazing session. It was nice talking to you and learning so much about CD, TDD, engineering metrics from you. Thank you so much once again.
Dave Farley: It's a pleasure. Thank you. Bye-bye. Thanks everyone.
Denis Čahuk: Thanks!
In this episode of the groCTO Originals podcast, host Kovid Batra is joined by Carlos Neves, the Head of Engineering at Vitality, as they explore the often challenging transition from an individual contributor (IC) to an Engineering Manager (EM).
With over 15 years of experience in engineering and leadership, Carlos shares his journey from Portugal to the UK, his initial interest in computer science influenced by a cousin, and his passion for salsa dancing. The discussion delves into the importance of gaining horizontal exposure within an organization, understanding the nuances of management beyond technical skills, and building confidence to overcome imposter syndrome. Carlos emphasizes the significance of proactive communication, trusting the team through delegation, and seeking mentorship. He shares insights into making a conscious decision to transition into management, highlighting the need for self-assessment regarding technical passions and people management skills.
The episode concludes with advice for those considering this career path and the introduction of groCTO Connect, a mentoring initiative aimed at helping technical leaders advance.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO podcast. And today with us, we have our special guest, Carlos. He is Head of Engineering at Vitality, having more than 15 plus years of engineering and leadership experience. Welcome to the show, Carlos. Happy to have you here.
Carlos Neves: Thank you. It’s a pleasure to be here and share my experience with you today.
Kovid Batra: Of course, we are looking forward to a lot of learning. And before we get started on our today’s topic, which is the ‘Not-so-easy transition from an IC to an EM role’, uh, we would love to know a little bit more about you. Uh, I, I, I had a very brief intro here, but I would love to know more about you, uh, your hobbies, uh, your childhood, your teenage and how you transitioned into who you are today. So, over to you. Uh, tell us about yourself, something that probably social media doesn’t know.
Carlos Neves: Well, there’s a lot of that, but, um, so first of all, actually I’m Portuguese, um, moved to the UK about eight years ago. Um, it was a, an interesting transition, a new culture, a new way of living, but very happy with that move, um, so far, at least. Uh, in terms of how I got to this, um, to what I got to today, I guess it was mainly influenced by one of my cousins. Uh, I saw him as a little bit of a mentor. When I was a teenager, he was very much keen into computers and computer science and programming. And I was like, “Oh, that looks interesting. So, uh, it’s just something that I will actually enjoy doing.” I remember that I was a little bit on the fence between, uh, following a computer science degree or, uh, going into, um, physical education at the time. So being a PE teacher, but, uh, yeah, in the end, computer science won, um, and I never looked back and it’s been so far a very rewarding journey, if I may say so. And something personal that no one, my friends know about it, uh, but social media doesn’t know is that I’m a very avid salsa dancer. Uh..
Kovid Batra: Oh, nice!
Carlos Neves: Yeah, sort of my, my hobbies outside of work.
Kovid Batra: Perfect. So you have a partner with you?
Carlos Neves: Uh, well, usually when, whenever you go to these social events, you tend to find multiple partners there, but yeah, sometimes I do go with, uh, with friends and, uh, not necessarily, uh, a set partner. So you get to swap, uh, partners during, during the event and it’s a lot of fun. It’s a good way to actually interact and socialize with people. I do recommend for anyone that hasn’t tried before.
Kovid Batra: Perfect. Perfect. I think that was really interesting. But you mentioned about, uh, it was between physical education and, uh, computer science, right? So like from childhood, teenage, like you had any sport that you were really interested in, you were playing something or it was just, uh, out of curiosity or you like physical education in general?
Carlos Neves: No, I was very active as a kid. Um, so when I was, uh, six, seven, my, my parents put me into swimming. So I’m, until I was 15, did some competition, then transitioned to, uh, athletics. I did athletics from the age of 12 until I was 18. Again, did competition and I really did enjoy the competition side of it. Again, the training with colleagues and, um, that was also a lot of fun. And because I did enjoy that, like that, that part, and it made me feel really, really well about myself, so I did think that maybe this is something that I actually want to do full time. But then, uh, looking at all the options and all the alternatives, I guess that’s, computer science just won in the end. Uh, I can, I’m still very physically active. I do try to hit the gym, uh, multiple times a week. I’m not saying that I’m a hundred percent, a hundred percent successful at that, but I did try my best. Uh, but, um, yeah, I still like to keep myself like fit and healthy as much as possible.
Kovid Batra: No, I think that’s, that’s really great. I think, um, childhood, uh, then when you are, uh, as a kid involved in sports and, uh, I’ve, I’ve seen a lot of my, my peers also who have been there, uh, played state-level, national-level competitions. Ultimately, in their careers, professionally also, came out to be very good leaders in general somehow and I am sure there is some linkage to that where you are more motivated, you’re more, uh, like a fighter spirit is there basically. So I think maybe that really impacts, uh on overall journey as, professionally also, if you see. So yeah, cool. I think that’s, that’s really interesting. So I think, uh, from there, moving into present as a Head of Engineering for Vitality, right? Tell us something about the company. What’s your role here? What do you do as a head of engineering? What kind of responsibilities you have? And, uh, of course we would love to know when you transitioned from the point where you were into engineering and then moving into, uh, you’re at an IC and you are moving into a management role. How did that transition happen?
Carlos Neves: Sure. So currently, as you said, I’m Head of Engineering for Vitality, uh, for those that don’t know Vitality is an insurance company that operates within the health and life space, uh, I’m responsible for the systems that support our members in their both health and life claims journey. Uh, there’s a big focus right now for us in terms of increasing our digital capability, so allowing the members to service themselves mostly digitally. Of course, there’s going to be the need to, uh, sometimes reaching by email or call, uh, but trying to minimize that as much as possible. Um, there’s also been a lot of focus in terms of, uh, after you get, uh, treatment or consultation to allow you, to allow you, the member to, uh, continue that, uh, continuous care, like online, as I said, as much as possible. I did a lot of modernization in terms of our systems that comes as part of the data engineering role, a lot of engagement with a lot of other departments, like the product department, um, eventually sales, um, it’s, I think it’s one of the things that I do enjoy the most as part of my role is that I tend to talk to a lot of different people that do a lot of different things. Uh, there’s a lot of forward-looking in terms of what we want to do in the future. What’s the plan for the next two, three years, where do we want to take our products? Um, and this is something that we’ll get into more detail after, but it’s one of the big differences that I put that I see in the role that you have as an IC versus, uh, an EM or a head of specifically where the, the vision that you have, it’s more shorter term as an IC versus a medium to long term vision for someone that operates at, uh, at this level, to be more specific.
Um, specifically about my, my transition. So, let me think. This was a while back. Uh, so, uh, before as a individual contributor, uh, so I started with Microsoft technologies doing C sharp, uh, messing with SQL databases, uh, mainly full stack at the time, which was actually a very good learning opportunity because you do get the opportunity to, uh, learn how the, how an application works full stack, messed a little bit with the back end, a little bit with the front end, a little bit with the, uh, your data store. And that allows you to understand the effort that goes into each of the different components to have an application up and running. This was still in the times where monoliths were the, the trend, not, uh, as it is today where everything is, well, microservices, not everything, but it’s, it seems that that’s the, the trend right now, even if I’ve seen that some, uh, corporations are, uh, depending the, going back to monoliths, which is, uh, something that, that’s, that’s, that would be a completely different podcast, and, uh, we would spend enough time just discussing that, but that’s, yeah, that’s a different conversation. But in terms of transitioning to, um, an EM or a people, uh, team leader, to be more specific, it happened where my manager at the time actually had to leave the business for personal reasons and I was invited to replace him. Um, it was a surprise, a good surprise, because it’s something that I really, really wanted to do, but still a surprise. It was, um, interesting because when I transitioned, I was told that I could choose the, some of the team members that I would want to work with, which in my opinion, actually helped quite a lot because having people that you can trust with you, people that you actually have worked with before, also does, does help in that transition. But I did feel at the time that I did have a little bit of, uh, an imposter syndrome and said, “Well, why am I doing this? And why isn’t, uh, someone else doing this?” Or, “Why was I invited when there’s people that have been here maybe for longer than I have, uh, and are as good or even better than I am?” But then, after going through that process, I said, “Well, if they chose me, there must be a reason why. So let’s trust the process.” And then I tried to use that to build my confidence, um, because it is, it is, it is a shift, it is a change, and it is something that, um, you need to start thinking differently. So for example, when I was working as a software engineer, it was very much focused on my tasks. What do I need to do today? Uh, I, I did have to interact with colleagues and understand what they were doing, but it was very much, um, not siloed, but focused on, on what I had to do, whilst when I went through this transition, it became, okay, what does my team need to do? What do they need to, uh, to perform their tasks? How can I help them? How can I support them to achieve their goals, their objectives, our common goals are common objectives? And that was one of the, the shifts and one of the changes that I, that I had to face. Um, the fact that you were no longer as close to the detail as before was something that I actually struggled with quite a lot, uh, in the beginning, and I remember a situation where I went to my manager at the time. I said, “ How do you know everything that’s going on around you? Because I’m struggling to provide support to my team and knowing what they need to do, but knowing everything that the other teams are working on.” And he said, “Well, sometimes you just have to trust the people that you work with, trust the process and wait for them to come to you with problems. So if no news, so the premise of no news is good news, try to apply that as much as possible. Only focus on what you really need to focus on.” And with that, with that, uh, example, actually it did help quite a lot because you do, if you do trust the people that you work with, I’m using the word ‘trust’ a lot because that’s one of the core values that I believe that I need to have when working, uh, with a team or with multiple teams, as it is my case today. Um, but going back to what I was saying, by doing that, by just focusing on the problems, you allow them to operate how they need to operate and you say, “Okay, I’m here to help you. I’m here to support you. I’m here for what you need, and if what you need is actually just to go out for coffee, for example, let’s do that. Let’s let’s talk.” And sometimes it’s not necessarily just about work.
Kovid Batra: Yeah. I think for you, um, it happened coincidentally that the manager left and you got the opportunity to move into this role.
Carlos Neves: Um, yeah.
Kovid Batra: Uh, I think, uh, now when you are here into this journey for maybe more than a few years, uh, let’s say, if there is someone, uh, who is actually at the point where they can consciously make a choice of transitioning, uh, into a technical role then a management role or a management role then a technical role, uh, what do you think are the core, uh, beliefs that that person should have, uh, to be doing great, uh, in this management side of, uh, the technical vertical, I would say? And what all it takes, the change, I think you have already highlighted a few points that the change, changes are really, really drastic because initially you are just not siloed exactly, but you are working on specific things that are bound to be with you and the impact is like here in front of you and you, you do things and you see changes. So, the changes are there, but at the core, I think when you’re making a conscious choice, you need to know who you are, right? And what are those things one should identify in themselves to do good in this journey?
Carlos Neves: Um, the first thing that I would say is how much do you love being a technical-minded person?
Kovid Batra: Okay.
Carlos Neves: To me, that’s the, the, the fundamental thing. Um, if you love, so talking about engineering specifically, if you love coding, if you love being part of the technical discussions, if you, if it’s something that you know that you’re going to miss, maybe being an engineering manager or a team leader is not for you because the higher up you go, the less opportunity you’re going to have to, to do that. Uh, there are some, some exceptions, of course, where there are some, um, Head of Engineering roles or even, uh, CTO roles that are hands-on, but that’s in my, in my experience, that’s the exception. So if you do really enjoy, um, that aspect of the, of the job, so being technical, being hands-on, maybe moving into that, uh, Engineering Manager role is not necessarily for you. Also, how much do you enjoy managing people? And this is also something that is very, very important because you are no longer focusing just on, on you, on yourself as an individual, you’re supposed to, uh, nurture, guide, mentor, find the opportunity for the people that, uh, you’re responsible for to, to grow. So if you don’t like that aspect of the job, then again, maybe it’s not for you.
Um, so, but if you do, and if you do enjoy talking to other people, if you do enjoy learning more about the, the wider aspect of the, of the business that you’re trying to, uh, to support and you work for, if you’re, if you do enjoy, um, guiding, showing, giving people direction, tell them, uh, show them how their day-to-day work is influencing positively the goals of the company, then yes, by all means go for it. Um, be intentional about it. Try to find within your, your team opportunities to take some of the tasks that your current team leader does. So one of the things that I always tried to do, uh, was to identify within my teams if there were people that actually wanted to take in that step, uh, in the near future and try to expose them to some of the activities that were delegated, that were my responsibility. So I would delegate to them, uh, let’s say, uh, talking to, uh, architects or talking to, uh, some of the, the people from, from the, from the product, uh, teams and by doing that, you can actually assess, “Okay, do I enjoy doing this or is it something that I actually I had in my mind, but it’s not something that I actually do, uh, see myself doing every single day?” Because that’s the thing, uh, doing it every single day, it’s different from doing it every now and then.
Kovid Batra: Yes.
Carlos Neves: The good thing is you can also try it for a while and if it doesn’t work out, you can always refer back to the, the, the, the role that you had before. And I think that’s the, one of the things that people sometimes need to consider is that a choice that you make today is not necessarily a choice for life.
Kovid Batra: Yeah. I think that’s a very good advice and I feel, uh, if someone wants to even try that, uh, one can actually get the taste of it at a technical leader role, right? A team lead role, basically, where you are involved technically, and I have seen most of the team leaders, tech leaders are coding also, and at the same time coding their teams in every possible way. So, I think for anyone who wants to see how things would look like, can get a taste of it as soon as they step into a team lead kind of a role. But the thing is like, uh, most of the people, uh, are driven by two primary reasons to make those career moves. One is, of course, uh, what you like to do, what aligns with your character, your identity, your personality. And the second is, of course, uh, how it is going to progress financially also, right? That, that also becomes a concern for people. So in, in your opinion, how do you think, uh, in, in a futuristic way, uh, things can impact someone financially, they’re taking the technical route or, uh, a management route in, in any company, for say? Maybe you can’t generalize it, but I am asking a general question. You can, of course, answer it the way you feel about this.
Carlos Neves: Well, I guess it all depends where you want to get to. So, um, when you get to that, um, Senior Software Engineer, Principal Software Engineer role or Principal Test Engineer role, so where you are considered to be a specialist that people can look for with any guidance, right? Someone that’s going to help shape a technical decision. Someone that’s going to help define the best technical standards for software engineering and test engineering. Um, from there, eventually the part can become of, of being an architect, solutions architect, enterprise architect, uh, chief enterprise architect. So I think there are ways to progress where you can actually keep being, um, very close to what you enjoy and also seeing that financial benefit. But if you, uh, would rather be a people, people manager, where you go through the Engineering Manager, Head of, CTO, uh, role, then again, there are, there’s different, there are different parts, but you can still get the benefits, the financial benefits that you were talking about. It’s just making sure that at the end of the day, that you still enjoy what you’re doing. Um, in my case, one of the things that actually made me, uh, make this shift wasn’t necessarily, well, of course, the financial, the financial gains are important, but it was actually the fact that I, I enjoy working with people and enjoy working as part of a team and try to expand my, uh, my remit in terms of, uh, who I was interacting with day-to-day. Um, I like to understand or get a better understanding of what I’m doing, how it’s impacting the wider business, and I think that’s where this, uh, want, want came from. It wasn’t necessarily just the, the financial benefits.
But just going back to what I was saying, try to understand, uh, which part makes more sense to you, but I wouldn’t say necessarily that one would be, uh, detrimental in terms of the financial benefit or not. And there’s been, there’s plenty of situations where even software engineers are quite well paid if the skills that they have are quite uncommon in the market. So if that’s the case, if you’re a specialist in an area that there’s not a lot of offer, then you also get that benefit of being, well, financially rewarded and still doing what you love.
Kovid Batra: Makes sense. So let’s, let’s talk about, uh, the point where let’s say, I have taken the decision to move from an IC to a management role. Uh, now what should I start doing today? Let’s say, today I’m a Senior Software Engineer, or let’s say I’m a, I’m a Tech Lead. What should I start doing to get to the next step? Uh, what kind of, uh, uh, impact should I be, uh, reflecting on the team on the things that I’m doing so that the managers, the leaders of the teams are feeling that, okay, I am the right person to be pulled up to this particular, uh, profile? So it happened for you coincidentally, but I’m sure in retrospect, you tell what they saw in you and how, how it turned out. So what do you think, uh, one should start doing today?
Carlos Neves: So I think the first thing is look at the people that, uh, you report into and let them know that that’s something that you do want to do. First thing that’s, that should be the first, the first step. Second is if you feel that the person that you report into is not given the opportunities to, um, get exposed to some of the activities that normally would be given to, to them, then again, ask them, “Is it okay if next time I do this presentation?”, “Is it okay if next time I get the data for this report?” For example, one of the things that an engineer manager has to do is to look at their team metrics, uh, to understand how they’re progressing, if things are going according to plan. Okay, “Is that something that I can do on my own even if my Engineering Manager or my, my Team Lead is actually doing it?” I have access to the information so I can actually go and have a look and understand how is my team performing, if there’s something that is not necessarily right, how, what can I do to, um, to change things? I guess all this summarizes into being intentional. Identify the areas where you, you know, that your Team Lead needs to operate in and try to go in, have a look at what you need to do. Um, but again, it all comes on to being supported by, by that person that it’s, uh, that you’re reporting to. So your, your Line Manager. Uh, if that’s not really an option, then sometimes you need to look for that opportunity elsewhere, even though it’s more difficult because people don’t tend to hire based on the belief that you can do a job. You need to prove that you can do the job itself. So it’s usually easier to find that opportunity, um, within the organization that you’re already working with. But I guess it’s just trying to find that opportunity, if not in your team, within the business, but in a different team. Don’t be afraid of moving horizontally because that can bring benefits. It’s also going to actually give you exposure to other parts of the business that, uh, is going to give you more knowledge, become well-rounded across the, the business, and that’s something that is really valued, uh, when you go and do higher, more, in more senior roles, I would say.
Kovid Batra: Makes sense. I think, um, this is one, uh, very good way, like going out and explicitly mentioning, uh, it to your manager that you want to move into that role. Of course, that really, really helps in terms of highlighting. Okay. For the manager also, it becomes easier to align people, make sure that they stick because their role is to keep people happy, right? And when they know what they are wanting, it’s much easier for them to deliver that. But let’s say, there are situations where the opportunity is not being given by the manager. What else can someone do on their own? What they can do in their day-to-day routine, uh, to actually reflect those traits? And maybe the manager themselves come asking for it, or maybe, let’s say, you are working with a cross-functional team, the other people appreciate that trait of yours, uh, and they start looking at you from that point of view that, oh, yeah, this person could be, uh, moved into a management role or a Tech Lead role and, uh, moving forward. So what, what, what are those kinds of things that probably a Senior Software Engineer or a Tech Lead should start doing from today on their own?
Carlos Neves: Uh, so one of the things that you mentioned that is very, very important is being, uh, someone that is good technically, that a team can rely on and support for guidance, but it’s also trying to be a leader underneath your leader, if it makes sense. So what do I mean by that? Someone that, uh, your team can go to and trust if they feel that they need some, some support. It’s someone that people from outside your team can go to if they have any questions, you need to be seen as someone that knows what they’re doing, that understands, uh, the, the benefit that the team brings, that understands other parts of the business, someone that is seen as an expert in their field, I think that would be the first thing. But it’s also putting yourself out there, and what I said before, in terms of putting yourself out there and telling, telling your manager that you have this, this want and this objective, but talk to other people about it. One, one thing that actually I did indirectly that I think also helped when people thought about me at the time was looking for guidance and mentors outside of my most immediate circle, because when you do that, people, they do realize that you do want, you’re doing more, that you’re ambitious, that you’re trying to, uh, get outside of what you do now and you want to step into a more senior role. And not only that, people get to know you, and that’s one very important thing that is, if people don’t know you, they’re not going to think about you, uh, when an opportunity comes because there’s going to be someone else they’re going to think of first. So put yourself out there.
Kovid Batra: Makes sense. Totally makes sense. So moving on from, uh, what one should be doing at this point of time when they’re wanting to be there, uh, next step is like foreseeing the challenges that are coming on them. I, you briefly talked about it already, but I think, uh, I want to deep dive into what are those experiences? Like, if you could just give me some examples that as soon as you moved into that role, what was the first experience which made you realize where am I, what should I be doing now? Something of that sort, so that people who are really looking up to that should know, okay, what’s on their way now.
Carlos Neves: Well, I guess it depends on the team that you’re going to be looking after. But one thing that, well, two things actually that I think might, might happen, uh, in a way that kind of happened to me. Uh, one is trust yourself, otherwise that imposter syndrome that I mentioned before, it might consume you and then you’re going to be so focused in trying to prove to others that you can actually do it, that you’re going to forget how you should actually be focusing on the job itself. Um, I’ll explain a little bit more on that. So there’s two things that you actually, uh, that I faced, actually. One was the, that imposter syndrome that, uh, in the beginning kind of affected my, my confidence and I got so concerned about what others were thinking that I forgot about doing the, the, the job itself. I was so concerned about, but what if they think that I’m not good enough? What if they, uh, think that I’m not the best person for the job? Don’t, don’t, don’t fall into that trap. As I said before, if you’re appointed to do something, trust that you’re the right person for the job, focus on your skills, focus on the benefits that you believe that you can bring to the team because we’re all different. Different people will manage differently. There’s not necessarily one, uh, size fits all when it comes to management.
And then, I guess the other thing is the fact that some people will, again, try and question. So it’s the same thing, but in coming from others, actually, you get to experience people coming to you and not necessarily asking, “Why are you my manager now when two weeks ago we were peers?”
Kovid Batra: Yeah.
Carlos Neves: But there are some things that you can pick up where actually you can sense that people are almost trying to test you and don’t fall into the trap again of trying to convince them that you’re the right person for the job. So focus on what you think the job is. Look upwards for guidance. Look, not necessarily your Line Manager, but other people that are, uh, that you tend to work with, as long as they have, they have more experience than you, it might be another Team Lead or another Engineering Manager that has done, has done it for a lot longer than you, and you can look at them for guidance and say, “Well, I’m doing this. Do you think this is something that is working or do you have any advice for me to do something slightly differently?” So, try to use that as a, as a sounding board, but don’t fall into the trap of trying to convince others that you’re the right person for the job. So, focus on you.
Kovid Batra: And, um, just to add to it, I think, uh, I have a few friends who have moved into this role and they’re mostly, uh, uh, being troubled, uh, with the fact that now they are not actually doing something related to engineering. They’re mostly managing people, right? And you also mentioned in the beginning that it becomes more about that. And, uh, of course, it doesn’t come, uh, very naturally to a lot of people, uh, who have been into the tech space for, let’s say, a good 5 to 8 to 10 years. And, uh, And then, uh, they’re moving into this role. So now in that situation, I think, uh, what, what would be that right piece of advice for people to change that core belief system? Because it, you become like that, right? You, you tend to be more, I wouldn’t say introvert, introvert could be a wrong word here, but something of that sort where, uh, right communication, uh, handling things proactively so that they don’t end up messed up, end up getting messed up. So things like that happen and, and I think the core thing lies within the frame of having the right communication style, right communication. So how, how one should learn to do that? Because that’s very evident that one needs to do that. How, how should one be doing that in that role?
Carlos Neves: So just, just a few things on that, that is in terms of letting go, I think the best thing that you can do is actually just delegate. And by delegating, I don’t mean delegating your new tasks into your team. Delegate the tasks that you believe that you still, that you should still be doing, to your team, because in the first few months, what’s going to happen is your mindset is going to be, “Oh, I need to go and look at the code.”, “I need to go and check that, that pull request to make sure that it’s following the standards.” No, I’m not saying let it go completely, but if you know the people that you’re working with, you know that you can trust them, just delegate it to them. Don’t, try not to think about it. Again, tell them that if there’s anything that is wrong, if there’s a problem, come to me. Leave that to the side and focus on what does my team need? How are they performing? What does my team require to perform this task? Are they blocked by something? Are they, is there something that I can do differently that would benefit them? I think that’s when things start to, uh, settle down from, from that shift from, uh, an Engineering Manager role, when you start thinking about the team first.
Kovid Batra: Got it.
Carlos Neves: And in terms of communication, one of the things that I do even today is talk to everyone individually, of course, make time to talk to your team individually. Try to understand what their motivations are. Try to understand what drives them. Try to understand how things are going even outside of work, because we’re, we don’t, we’re not just employees. We have a life outside of work.
Kovid Batra: Yeah.
Carlos Neves: That is more important, I would say, at least for me, it’s more important than going into the office nine to five and then that’s, that’s, that’s all of your life. So, and that has a big influence on how you perform at work. So, if there’s anything that is happening, try to be available if they want to talk to you. Um, and finding that space where people start to trust you and they, they come to you for problems, they come to you for good things, and that, that’s when you actually, the communication is flowing. The communication is good between us. They trust me. They feel like I’m here to help them. They feel like I’m here to guide them and do what’s best for them. And it takes, it takes a lot of time to get to that point, but the main thing is stop thinking about what you can do, how, uh, how your own individual work is going to impact you, but try to think more about this is what my team needs. This is what the group of people that I’m responsible for can drive and can succeed because your success comes from their success.
Kovid Batra: Cool. I think, uh, the last line you said is the most impactful one for this role probably, like their success is my success and that’s how one should be progressing, and that’s the mind shift one would need when they’re moving from the role, from the IC role to an EM kind of a role. So cool, Carlos. I think, uh, there is a lot more to talk about this topic, but I am sorry, we can’t cover it in one, one session that we’re having with you. We’d love to have you for another session, maybe seeing how you progress from an EM role to a Head of Engineering role. That could be another discussion totally. And, uh, happy to have you again, uh, anytime, whenever you, you, you think you have time to discuss about it.
And, uh, talking about the mentoring piece, uh, just for our audience to, uh, let them know, uh, groCTO has come up with the, uh, groCTO Connect, uh, initiative where we are helping these EMs, ICs, technical leaders connect with leadership people for their mentorship to grow to the next level. So it’s groCTO Connect. Uh, we’d be happy if people want to send in requests. I’ll share the link of our groCTO Connect page in the comments. And with that, Carlos, thank you so much for your time. Loved having you here, really insightful talk. See you soon.
Carlos Neves: Thank you very much for the opportunity again. It was a pleasure. And reach out, I’ll be always available.
Kovid Batra: Thank you. Thank you so much, Carlos.
In this episode of the groCTO Originals Podcast, Kovid Batra talks with Jagannath Kintali, former Head of Engineering at Dojo and ex-startup co-founder, about building impactful engineering teams focused on customer delight.
Jagannath shares his extensive experience of over 18+ years in engineering, discussing the importance of building what is needed rather than overshooting with extravagant systems. He emphasises creating high-performance teams through trust, purpose, and customer empathy. Jagannath highlights his journey, the learnings from his startup, and how he implemented these insights at Dojo, including stories about curtain ordering systems and observability projects. This episode provides valuable insights on leadership, team building, and aligning engineering efforts towards solving real customer problems.
Kovid Batra: Hi everyone. This is Kovid, back with another episode of groCTO Podcast. And today with us, we have a very special guest. He’s Ex-Head of Engineering, Dojo. He has been an ex startup co-founder. Welcome to the show, Jag.
Jagannath Kintali: Thank you very much, Kovid. It’s, uh, it’s been a pleasure and thank you for having me on your show.
Kovid Batra: Great. So for the audience, uh, Jag is short for Jagannath and on this show, I think we’ll be calling you Jag. Is that okay with you?
Jagannath Kintali: Oh, that’s absolutely fine. Thank you. Yes, uh, Jagannath, it’s usually not the most common name in the Western world. So short form is Jag.
Kovid Batra: Yeah, that’s, that’s really cool. I think, uh, be a Roman when you are in Rome. So, that works. Yeah.
Cool. So, uh, on that note, like for the audience, um, today’s topic is. How to build impactful engineering teams that really build for the customer delight and I think Jag has, uh, really good hands-on experience with nurturing such teams. But before we dive deep into that part, I think we would love to know more about you, Jag. You have been a startup co-founder and I think it’s been a long journey of 18 years in the engineering world. Tell us something about yourself so that audience, audience, gets, gets to know you a little more. Um, your personal life, your hobbies, what you have been doing, uh, maybe about your startup.
Jagannath Kintali: Oh, absolutely. Uh, I am, my name is Jagannath. Uh, I actually do come from Orissa where Jagannath Puri, uh, Lord Jagannath Puri hails from. So after, uh, being there in Orissa, I’ve done my engineering, uh, I decided to come for a master’s degree in the UK and that’s where I started my software engineering career, uh, so to say, started as a, a software engineer, but once you come from, uh, this background of engineering and add a world to explore, but obviously the Western world was, uh, and especially UK was completely new to me, and the opportunities that you see over here was, uh, so many, I always wanted to go into building something of my own and having something of my own and to start something which will serve the community and, and a certain customers segment in general. And so, I ended up doing after several years of doing software engineering roles and especially my expertise is in solution architecture. But after several years, I decided to take the plunge, like everybody else wants to do that. But yes, I got to warn everybody and the audience that my startup does belong to the 9 failures out of 10 that all the startup happens. But I’ve done that and I have no regrets in giving it a try and doing that, but it is the most, uh, beautiful experience I had during the startup time, and we tried to do it for just over two years. Um, but yes, it was all about, uh, hyper local services, providing services to, um, customers within a certain community. But yes, ever since then, um, I’m still very much passionate about engineering and what I’m very passionate about is building or engineering beautiful products for customers who, you know, have a need for it, a particular challenge that it solves. Solving the customer problems is my main aim in life, and I’ve grown up in a, um, you know, I’ve grown up with the ethos or the principle is that, uh, to service, you know, uh, godliness. That’s where all it comes from. But yes, learning to be a, a pilot, which has been a dream of mine for a very long time. So let’s see how that goes. So hopefully I will get that license in this lifetime.
Kovid Batra: All the best to you for that.
Jagannath Kintali: Thank you.
Kovid Batra: Uh, you, like you said that, uh, you had this beautiful experience of, uh, being a co-founder and having that startup experience particularly. Um, what, what was your major learning from it? Like if I have to say like when you came out of it, I’m sure, uh, it’s never a failure, obviously. I mean, I have been..
Jagannath Kintali: Absolutely.
Kovid Batra: So what you learn out of it is something which is very different from what you do in a job. You get such a holistic experience of solving problems and building solutions when you are doing things as a co-founder or probably as in the leadership of a startup also, for that matter. So what was your learning from that journey? If you could, uh, like highlight that for us.
Jagannath Kintali: My total learning, as you said, it’s never a failure, and actually based on the learnings from the startup, I’ve had many successful jobs based on the learning from, uh, from the startup and, uh, I’ve had many, uh, many times, uh, uh, tried to think about and summarize what, what were the things that I could have completely done, uh, differently, and that’s what I keep on using in my future roles. And I boiled it down to basically three, uh, different learnings. First of all, it was the product. Then second comes the, uh, people aspect of it and how you execute it. Those were the three areas that I, I think, uh, were the three main learnings. First, it was the product, that service that we were trying to provide. It was a very simple concept. It was a matchmaking process where somebody as a service holder can provide the service to a person who is in need of that service and a very hyper local at that point. So within, um, 15, uh, 20 minutes, you get your service, uh, sorted, whether it is, uh, looking for a cleaner, whether you’re looking for a locksmith, or whether you want to, uh, wanted somebody to get some, uh, grocery from the store, uh, to you. Now, nowadays, it sounds like it’s so common. It wasn’t that common in 2012, 2013 when we, uh, started this. But, uh, the first learning was we, the opportunity was so big, we got a little lost, in my opinion, as to which area we should concentrate on. So there were just so many avenues we wanted to go down on. We should have, uh, probably own down in a, kind of set of services and tried to build that platform and repeatedly perfected or make it much more efficient, the process of end-to-end, somebody requesting for a service and somebody getting a service and the feedback loop going back and forth and repeatedly doing that through our systems, through customer feedback and through the service, services that we provided, particularly one or two. We tried to widen it straight away with 10 to 12 different services. And what happens is every service type has, uh, different kinds of needs that the need of a, uh, a cleaner or a maid, uh, you’re looking for a maid is completely different than looking for a locksmith, or, uh, you know, looking for, uh, a nanny’s, uh, completely different and trying to, uh, funnel all of those requirements and make it efficient into one single channel was the most difficult thing. What we should have done is just pick one particular vertical, try to get some traction on it and then you will realize and you will have your learning and then use that learning in other services. Slowly added that.
So being in a particular and it is very behavioral because this is not a Uber, uh, type concept where you have the service being provided outside your house. The service we were trying to provide was within the house. So there’s a big trust factor that needed to come in. And every country that you go to, we were trying to do it in the Middle East, where, uh, it’s a service Mecca. Um, and we want to get some traction over there, but I was in London at that time. I did not spend enough time, uh, I’ve been there quite often, but I do not spend enough time. Be there, be emerged into the local community and try to figure that out by yourself. Going back to the first principles of totally immersing yourself into finding out where the needs are, what the actual requirements are, where the actual inefficiencies are and how to join the dots. Trying to sit completely away and trying to, uh, uh, totally imagine the inefficiencies and, and not looking at the reality was probably one of the, uh, challenges, uh, uh, we faced and the biggest learning, uh, I’ve had in, in, in doing that. And second, uh, on the people side. That was on the product side. People side, it brings me, uh, uh, to the, it’s very related to the topic that we’ll be talking about. It’s building that very strong team.
When you are a startup, it is very difficult to get the right set of people and, uh, you’re looking for funding, you’re looking for finances, you don’t, uh, uh, you are not going to get, uh, you know, the star players that, uh, you wanted on your team from day one, it is very difficult to do that and also trying to build a, uh, build a team, which is totally dedicated for the purpose. What we did was, okay, let’s go out and find a team, whether it is a third-party software provider, uh, or software consultancy, a small outfit somewhere, and try to bring them in. What we didn’t do, that would have also worked, but what we didn’t fail to do, in my opinion, is, is, uh, giving them that purpose. So they always worked as a consultant. They were not integrating. They were not, uh, bought into the product that they were trying to build or the company. Uh, company had a mission, company was trying to solve a particular customer challenge. We did not expose that particular team to that area, and they were just literally taking instructions and building a software system. They didn’t have the direct interaction with the customers or trying to understand the customer problem that we were trying to solve. Uh, that, that, that was the biggest gap, and this is where the impactful engineering comes into play. I’m a true believer in building teams which are totally exposed to the customer challenges. That doesn’t mean that you have to go and talk to the customer every single day, but you’ve got to understand the customer problem that you’re trying to solve on a single, every single day. Find out why, why it is that you are doing and everything that you’re building, how it is impacting the challenge you are trying to solve. If you don’t have that, if you don’t have that purpose, if you don’t have that, uh, you know, the belief that you are actually doing something, which solves a customer problem, you have lost the interest, the engagement of a particular team, and that’s where it goes downhill.
We’ll talk about many different things, and, uh, I’m sure we’ll go in-depth into it. But, uh, those were the biggest learnings and the execution of it. Obviously, being in 3 different geographical locations, we were trying to coordinate and do that. If you want to do a startup, be there, be in the location, be amongst your customers, understand the problem, even be the person who is even delivering that service and, uh, and try to understand the entire life cycle of a product. It’s not about building a software system, which you think will be very useful. It is, uh, if there are no customers who are using it and customers are not willing to pay for it, it’s not going to work out for you. It’s always going to end up in a, uh, well, 9 out of the 10, uh, do fail as starters because of that reason. So, you know, those were my biggest learnings from doing a startup, but I wouldn’t change, uh, this experience, uh, ever. I mean, it was, it was probably the hardest two and a half years of, of my life, we lost a lot of money also, uh, but wouldn’t change the experience for, uh, for any amount of money, for sure.
Kovid Batra: Perfect. I think, uh, the best part about such journeys, uh, are that in those hardships, in those times, you actually see a significant change in your mindset, how you think about things. It’s more like reality coming to you. Uh, it’s, it’s more like reality slapping you, saying that, okay, this is how things should be working, right?
Jagannath Kintali: Yeah, absolutely.
Kovid Batra: So, uh, I think that’s when you, you evolve the most. I mean, according to my understanding of how one should be, um, leading life in this universe is understanding more of world concepts, how reality works, the more you become empathetic and compassionate towards people, nature, how things are working around you, the better decision-making you bring into your, yeah. So I think startup has done that to me at least, and I feel the same when you are talking about, uh, realizing that it’s about building great teams also who focus on customer empathy, like customer delight, so that they can bring out those solutions which really solve the problem. You just don’t become a feature factory delivering features, taking instructions, delivering features. You actually deliver value. That’s how the mindset changes. And on that note, I think, uh, which is, of course, the topic for today, now when you are like four or five years ahead in that journey, you have been leading an engineering team for Dojo, I’m sure you would have incorporated some level of, uh, framework or some level of practices which inculcate this customer empathy or, uh, teams that are fundamentally aligned towards solving problems rather than just building features. So can you tell us about some of your experiences in your journey, how things worked out for you after that, and how you implemented this learning in your, in your teams?
Jagannath Kintali: I’ll start with the story this, uh, while having this conversation, it just came to my mind, previous to Dojo, I worked for it, uh, I was working for a software consultancy and I was working for it, uh, one of the biggest retailers in, uh, in the UK, and, uh, uh, I’ll tell you my first, uh, foray into, or the first time I ever was so delighted, uh, with the work I was doing. So the story goes as if that, so this biggest retailer, they, so it’s a super, um, what is it called? A superstore. They sell from food to clothing to anything, you name it, and they sell it, and they also sell curtains. So this is early into my career, and I’m in this, and I’ve been given this responsibility to design a curtain ordering system. Like, I have no knowledge about curtains. I didn’t even know that there were so many types of curtains that existed in this world, there’s so many textures, the type of cloths, and how the look will be, how to hang it, and all of those, but again, never interacted with any of the actual users. It was a consultancy. So, you know, you went into a dark room, you designed a system, and, and you deliver it to this, uh, retailer. It took my time trying to understand that the business, how the curtain, curtain ordering system works and how it goes from A to B, and when customer orders and it goes to the manufacturer, it comes back, uh, to the retailer and how they deliver it. Everything was beautifully fine, and, and went in, you designed to the best of your ability, right? Uh, trying to understand what the customer might need or, or the shop, the shop assistant who’s using your system to provide this service to the, uh, customer, but somehow we managed, we had a conversation, the system was delivered on, well on time and, and so. But, uh, I never felt like I, uh, so proud of, uh, this project, you know, it’s, it’s, I always used it as a job, okay? I went to work, I did some coding, I built some systems, it’s running absolutely fine, it is delivering what it’s supposed to deliver, you input A and the output B comes out, and those were the right input and output everybody was looking for. Job done. But then I was, in my off day, I visited one of these retailers and I went to one of the stores and I was with my partner at that time. So we were both visiting the store and I was trying to figure out how could I use this system that I built. I wanted to show, okay, I built a system, but I actually went and ordered some curtains at, at this store and the lady who was, uh, uh, serving us in, in the store, she pulls out, uh, an, an, the device, that were hand-held devices that they were doing, and she pulls out the system that the UI that, uh, was built by me and, uh, and two other engineers. And as soon as I saw that, uh, a UI and the ways she was using it, the satisfaction I got and the joy, that the happiness that I got just looking at, uh, and you know, your, uh, hard work is being utilized by somebody, and, and it is being very useful to somebody. On that day forward, onwards, I’m telling that something completely changed in the way I think and the way I approach and, uh, approach my work and the way I try to find that delight every single time I do something in my professional career, it completely changed.
And the best learning, uh, we were talking about in the introduction is the best learning from my 19 or 18, 19 years of engineering, uh, leadership, one thing that I have learned from, uh, uh, some of my senior engineers, I was in a project, one sentence that sums up all of it, ‘Build what you need, not what you want’, because there is this thing that we always overshoot. It’s, it feels like we should be building this, uh, uh, wonderful system, the most efficient, the most effective and do that. But no, you just need to build something which you need and the customer needs, that’s the most delightful thing that you can do for a customer and providing that talent. So that’s one of the best things that has ever happened. And from that moment onwards, this is what, how it has changed my, my perspective on software engineering in general, and how even in engineering leadership.
So coming back to the, I know it’s a roundabout way, but then coming back to the original question about how I’ve done this in my, uh, you know, my, my stint or my, uh, my work at, at Dojo, I tried to find the purpose or, or even build this purpose within a team. Building a high-performance team, in my opinion, it’s nothing to do with tech. It’s nothing to do with what you are trying to achieve. It’s about building that trust and finding that purpose every single, you will find, uh, a star, uh, engineers. You will find all the, uh, uh, right people in the, uh, uh, right places. But if they don’t have a purpose, if they don’t have a goal, they don’t have a direction to go towards, none of this works. And bringing that trust factor is the clue that will bind the team together in moving towards that goal, moving towards that ultimate aim of delivering that customer delight or the impact, customer impact that I keep going back to. And my way of doing it, there was no framework. There is, I know this might be very controversial and there’s nothing to do with frameworks or there’s nothing to do with, you know, reading books or, uh, uh, engineering leadership, it was pure and simple, uh, people’s relationship and building relationship and understanding each and every person within your team that you have. And the more you do it, the more it trickles. I started with a simple team of five when I started, I ended up, uh, when I finished with Dojo, finished at Dojo, I was looking more than 60, 70 engineers at a time. But once you build this environment where you build relationships, you build, you play the long game, not, never a short game for, for the purpose, you build relationships, try and understand each and every person who is within your team, what is that purpose and give them that purpose, give them that direction, give them the, uh, validation and recognition, which is the most undervalued aspect of software engineering. You provide them the right scenarios and the right environment, you will have a high-performing team every single time. I can guarantee you that.
That’s, that has been my mantra. It’s about personal relationships and building relationships and understanding people and going back to the first principles, and why we are doing it, give them the same input. Usually, I mean, it’s almost like if anybody replaces you as well, every team member within a particular team should be able to reiterate the same purpose within the team. So that’s how I always see it. Everybody having the same mentality and, uh, you know, the collective high mentality and trying to achieve that same goal, does a lot of good in a longer run. Uh, you might not see that in a shorter term, but for a longer run, it is the most, uh, the best thing you can do.
Kovid Batra: I think I absolutely agree with you. And in fact, uh, you said there is no framework as such. This is what you do and how you achieve things to build better teams. But I think this is the framework, according to me. Like on your behalf, I would just say that if you really want to build a team that cares for the customer and you are the one who is leading the teams, you build that relation, you build that trust with your team members, and every discussion, every sprint or every procedure that you are following to build something, if you’re putting that out in your thoughts, putting that out in your documents, maybe even if there are some PRDs where you are mentioning why we are solving this along with what needs to be built, I think that’s when you crack the things, because every day, if there is a discussion in the room where we are talking about solving the problems for the customer, automatically everyone starts thinking like that. Of course, there has to be a first-level trust built to be, uh, to be there where everyone looks up to that mindset which you are adopting or if you are preaching that. So this is the key, I believe. Like in every team, whether big or small, you just need to make sure that whatever you are following as a philosophy while building products for the, for the customers, that needs to propagate in every discussion, every document that’s going out from you and people would automatically start following it, and I think that’s how things over a long term would, uh, get imbibed fundamentally, uh..
Jagannath Kintali: Fundamentally. It’s the basic fundamentals that you, uh, uh, that you target and everything, uh, everything falls in place afterwards. And one of the things I’ll tell you for sure, like once you have this, your work becomes a side effect because you are building that, uh, mentality. Are you building that mindset across? The team, you move like a single unit and move and try to target, you know, what you were aiming for. The one thing I actually forgot to mention, or I wanted to bring up is that, you know, people talk about resolving conflict. How do you resolve conflict if there are two competing ideas and which is having, you know, you are having heated arguments or discussions about what is the best way to move it forward? I ask simply the question, which one, which solution will have the biggest impact? For our customer, the problem we are trying to solve, can it, which one does have, and there is always a single solution, there is never a multiple solution which says, okay, this will have, whether you count that as a, uh, how beneficial it will be for the customer, the cost impact of it, or how long-term effect it will have, how it will even have, uh, reduced tech debt, also in the longer run, you will find that asking that question, which one will have the better impact or most, most impact for the challenge that we are trying to solve, then you will, in terms there, there is a resolution always, most of the time.
Kovid Batra: Okay. Yeah, yeah, yeah. I totally get it.
Jagannath Kintali: And every sprint, what we used to do, uh, we do use the uh, uh, you know, the sprinting method as well, in every sprint, we will reiterate. We follow this OKR process, the, you know, and the key results and objectives and key results. Every sprint, we will try and make sure that the objectives and key results are pretty aligned to the needs of the company. First of all, you have your customer, then you also have your company goals to meet as well. So you have to keep this in balance in trying to go through. Make sure that it is still very much valid. It’s still very much aligned to what we are trying to move towards. It’s, it’s, it’s a pyramid kind of structure, if we were to talk about frameworks that we are doing, each and every team needs to do, set their own objectives and key results that they want to try and achieve. But those objectives and key results, need to also come from top-down. So we meet in the middle. So you have very strategic goals set by the founders of the company, Execs, right from the beginning, and then they will say, these are the different areas that we will be targeting on. And, you know, the squads and basically the teams will set their objectives accordingly from an engineering perspective, from the product perspective, and they meet at the middle. That’s how we have always looked into doing that. So it is very aligned. It is very, very much towards the company and the customer aims, uh, or the customer challenges that we are aiming for. And that’s how, uh, in my opinion, that’s, it is not, it is never going to be perfect, but the best results we have got so far is by this OKR framework.
Kovid Batra: Got it. Got it. I think, um, one more thing that I realized, like setting up these objectives and key results definitely brings that structural angle to solving the problems and doing something as a team. But going back to the first point from where you started with a story, I really loved that. And as a, as a, let’s say, as a team member, let’s say, you have been a, an, a leader for the team, if this is something how you would explain something to the, uh, the team members, the developers that how one should be thinking about things, I think that can also go a very long way, right?
Jagannath Kintali: Long way. Absolutely.
Kovid Batra: So basically, getting those team meetings sometimes around, uh, sharing such stories where they actually, uh, experienced what customers feel like, getting into their shoes and experiencing something, and then going back to your desktop or laptop and coding, I think that also is a big, uh, big-time need for, at least for the developer space, because it’s most of the time they’re coding in their own zones and there is a very big disconnect, but if, if we propagate this thought and we incentivize this thought, I think that can also go, as I said, long-term, in terms of building teams that are able to think with empathy, compassion for the customers.
Jagannath Kintali: There’s another story I would like to, uh, tell you. It’s, uh, in, in Dojo, we wanted to, um, introduce, uh, a particular engineering paradigm regarding, uh, observability, right? So the whole idea is that every single system that is, that exists in, in Dojo, we should be, uh, it should be totally observable. Uh, we should know about how it is performing, where it is, how, how much traffic it is coming through, how much CPU or memory, the whole shebang. But it, it was a very, uh, nice, a niche, a concept that we were trying to introduce in Dojo. Dojo was in, in, in its journey to, in its scale of journey. So how do we do that, uh, impact? How do we even, uh, build this, talk about this story, how to, how useful this is going to be, right? So what we did is that we did a very small project and we put it out regarding observability and we called it the ‘architectural pane of glass’. We used to, well, Dojo has a massive, uh, TV screens within the engineering floor, where we are displaying numbers and Grafana dashboards and, uh, you know, all stats flying around. What we did is we took a complete product and every component of that product, we devised it. So it was basically a Grafana dashboard, and every, we broke it down to different parts of the, all the components that builds that system and the system basically builds the product. And we showed everything pictorially on this Grafana dashboard, and every time any problem that would happen within these particular components or systems, it flashes, right? It’s saying, hey, there’s an error, uh, and there’s a metric failure or all the, uh, SLAs and SLIs that you have set, which is dropping down. You have the variants and all of that. It’ll start flashing. What happened, uh, by doing that is, is that every person who passed that, uh, screen, uh, and we have multiple products in Dojo, so any other product members who were passing that, including our CTO and founders, so every time they will pass this screen, they would stop by this screen, right? And they would say, Oh, what’s this about? This is something that we haven’t seen. And this is and ‘red, green’ is a, you know, universal language. You know, if it is showing red, that there’s a problem. It is green, then it is all going well. Oh, why is there a problem? And it became a conversation starter.
Kovid Batra: Got it.
Jagannath Kintali: And what we were trying to push for is, is, is the effective way of operation, uh, of all the different systems. And what we did is building that team who would say, and it was right next to where the team was sitting down, right? So every time somebody came around and talked about, uh, this big screen, the team would really feel, uh, very good about what they have built. They can see the usefulness of this product that we were trying to push for. And what that resulted in, we got the funding to build a team, we got the funding to afford and take that even further and spread it across entire Dojo Engineering. And I, last time I checked, I haven’t been to Dojo in a while, but, uh, the observability system that we have built is uh, I can put my hand on heart and say, probably one of the best in the UK market or in, in, in the FinTechs. I’d go even further in the world, but I haven’t seen many of the other systems, but it’s one of the best systems that we have built. It’s been a journey of two years.
So what I was trying to get to is that even doing small little things and having that customer delight, in this case, it was an internal community of engineers that we were trying to do. But you can see how you can capture the imagination of the customer and uses that you are trying to solve the problem for and get them engaged. And it’s a two-way street. Because the customers are getting engaged, the team is now getting engaged, and they are finding that, oh, uh, you know, that people are talking about this particular product. I was meeting with this person from that particular team and they were saying, hey, how can we, get that system built for us? And it becomes a starting point and starting conversation point, and it spreads all by itself. What about there was no company direction or a top-down approach in doing that? This is doing things very organically and trying to capture the imagination and showing that, hey, this is also possible, this is something that can be done. And, and of course, the product was very useful. We didn’t have as much observability into our systems as, you know, previously, this allowed us to observe our systems even better. So it worked out beautifully and it’s a story that I will probably never forget for as long as I am in this profession. It’s how all of the observability team started from there.
Kovid Batra: Got it. Got it. Amazing. Amazing. I think, uh, this is really a good example where not just thinking about customers who are business customers, but these developers, these people are your internal customers who you have to cater. And as a leader, if you become compassionate and empathetic about how you can actually make them, uh, push towards success metrics and think, think about things which they would align with and bringing this at such large scale, ultimately, would impact your customers also. So I think a very good example shared here and it was a really, really good session.
As we are moving out of time, now I would like to take this to a close end. Thanks a lot, Jag, for bringing such beautiful, beautiful insights on how you can actually build great engineering teams and sharing your experiences at Dojo. It was a lovely, lovely experience for sure.
Jagannath Kintali: Thank you very much for having me on. And it’s always nice to go back to, we, we as engineers, as professional, we don’t usually do this enough where we, uh, stop and, uh, take a pause and look back in our previous experiences, and, and it brings me great joy to even talk about all the different experiences and it, it brings a smile to my face as well. So it was very delightful and, uh, delightful for me as well. Thank you very much for the opportunity.
Kovid Batra: Great. Um, we would definitely love to have you back sometime again, uh, talking about more such engineering challenges and how things work out in the engineering world.
Jagannath Kintali: 100%.
Kovid Batra: Thank you for today. Thank you, Jag.
Jagannath Kintali: Thank you. Have a good day. Bye.
Kovid Batra: Thank you. Bye.
Sign up now and you’ll be up and running on Typo in just minutes
