The DORA Lab EP #03 | Ben Parisot - Engineering Manager at Planet Argon

In the third episode of ‘The DORA Lab’ - an exclusive podcast by groCTO, host Kovid Batra has an engaging conversation with Ben Parisot, Software Engineering Manager at Planet Argon, with over 10 years of experience in engineering and engineering management.

The episode starts with Ben offering a glimpse into his personal life. Following that, he delves into engineering metrics, specifically DORA & the SPACE framework. He highlights their significance in improving the overall efficiency of development processes, ultimately benefiting customers & dev teams alike. He discusses the specific metrics he monitors for team satisfaction and the crucial areas that affect engineering efficiency, underscoring the importance of code quality & longevity. Ben also discusses the challenges faced when implementing these metrics, providing effective strategies to tackle them.

Towards the end, Ben provides parting advice for engineering managers leading small teams emphasizing the importance of identifying & utilizing metrics tailored to their specific needs.


  • 00:09 - Ben’s Introduction
  • 03:05 - Understanding DORA & Engineering Metrics
  • 07:51 - Code Quality, Collaboration & Roadmap Contribution
  • 11:34 - Team Satisfaction & DevEx
  • 16:52 - Focus Areas of Engineering Efficiency
  • 24:39 - Implementing Metrics Challenges
  • 32:11 - Ben’s Parting Advice

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo, and today's episode is a bit special. This is part of The DORA Lab series and this episode becomes even more special with our guest who comes with an amazing experience of 10 plus years in engineering and engineering management. He's currently working as an engineering manager with Planet Argon. We are grateful to have you here, Ben. Welcome to the show. 

Ben Parisot: Thank you, Kovid. It's really great to be here. 

Kovid Batra: Cool, Ben. So today, I think when we talk about The DORA Lab, which is our exclusive series, where we talk only about DORA, engineering metrics beyond DORA, and things related to implementation of these metrics and their impact in the engineering themes. This is going to be a big topic where we will deep dive into the nitty gritties that you have experienced with with this framework. But before that, we would love to know about you. Something interesting, uh, about your life, your hobby and your role at your company. So, please go ahead and let us know. 

Ben Parisot: Sure. Um, well, my name is Ben Parisot, uh, as you said, and I am the engineering manager at Planet Argon. We are a Ruby on Rails agency. Uh, we are headquartered in Portland, Oregon in the US but we have a distributed team across the US and, uh, many different countries around the world. We specifically work with, uh, companies that have legacy rails applications that are becoming difficult to maintain, um, either because of outdated versions, um, or just like complicated legacy code. We all know how the older an application gets, the more complex and, um, difficult it can be to work within that code. So we try to come in, uh, help people pull back from the brink of having to do a big rewrite and modernize and update their applications. 

Um, for myself, I am an Engineering Manager. I'm a writer, parts, uh, very, very non-professional musician. Um, I like to read, I really like comic books. I currently am working on a mural for my son, uh, he's turning 11 in about a week, and he requested a giant Godzilla mural painted on his bedroom wall. This is the first time I've ever done a giant mural, so we'll see how it goes. So far, so good. Uh, but he did tell me that, uh, he said, "Dad, even if it's bad, it's just paint." So, I think that.. Uh, still trying to make it look good, but, um, he's, he's got the right mindset, I think about it. 

Kovid Batra: Yeah, I mean, I have to appreciate you for that and honestly, great courage and initiative from your end to take up this for the kid. I am sure you will do a great job there. All the best, man. And thanks a lot for this quick, interesting intro about yourself. 

Let's get going for The DORA Lab. So I think before we deep dive into, uh, what these metrics are all about and what you do, let's have a quick definition of DORA from you, like what is DORA and why is it important and maybe not just DORA, but other metrics, engineering metrics, why they are important. 

Ben Parisot: Sure. So my understanding of DORA is sort of the classical, like it's the DevOps Research and Assessment. It was a think tank type of group just to, I can't remember the company that they started with, but it was essentially to improve productivity specifically around deployments, I believe, and like smoothing out some deployment, uh, and more DevOps-related processes, I think. That's, uh, but, uh, it's essentially evolved to be more about engineering metrics in a broader sense, still pretty focused on deployment. So specifically, like how, how fast can teams deploy code, the frequency of those deployments and changes, uh, to the codebase. Um, and then also metrics around failures and response to failures and how fast people can, uh, or engineering teams respond to incidences. 

Beyond DORA, there's of course the SPACE framework, which is a little bit more broader and looks at some of the more day-to-day processes involved in software engineering, um, and also developer experience. We at Planet Argon, we do a little bit of DORA. We focus mainly on more SPACE-related metrics, um, although there's a bunch of crossover. For us, metrics are very important both for, you know, evaluating the performance of our team, so that we can, you know, show value to our clients and prove, you know, "Hey, this is the value that we are providing beyond just the deliverable." Sometimes because of the nature of our work, we do a lot of work on like the backend or improvements that are not necessarily super-apparent to an end user or even, you know, the stakeholder within the project. So having metrics that we can show to our clients to say, "Hey, this is, um, you know, this is improving our processes and our team's efficiency and therefore, that's getting more value for your budget because we're able to move faster and accomplish more." That's a good thing. Also, it's just very helpful to, you know, keep up good team morale and for longevity sake, like, engineers on our team really like to know where they stand. They like to know how they're doing. Um, they like to have benchmarks on which they can, uh, measure their own growth and know where in sort of the role advancement phase they are based on some, you know, quantifiable metric that is not just, you know, feedback from their coworkers or from clients. 

Kovid Batra: Yeah, I think that's totally making sense to me and while you were talking about the purpose of bringing these metrics in place and going beyond DORA also, that totally relates to the modern software development processes, because you just don't want to like restrict yourself to certain part of engineering efficiency when you measure it, you just don't want to look at the lead time for change, or you just don't want to look at the deployment frequency. There are things beyond these, which are also very important and become, uh, the area of inefficiency or bottlenecks in the team's overall delivery. So, just for example, I mean, this is a question also, whether there is good collaboration between the team or not, right? If there is no good code collaboration, that is a big bottleneck, right? Getting reviews done in a proper way where the quality, the base is intact, that really, really matters. Similarly, if you talk about things like delivery, when you're delivering the software from the planning phase to the actual feature rollout and users using it, so cycle time probably in DORA will cover that, but going beyond that space to understand the project management piece and making sure how much time in total goes into it is again an aspect. Then, there are areas where you would want to understand your team satisfaction and how much teams are contributing towards the roadmap, because that's also how you define that whether you have accumulated too much of technical debt or there are too many bugs coming in and the team is involved right over there. 

And an interesting one which I recently came across was someone was measuring that when new engineers are getting onboarded, uh, how much time does it take to go for the first commit, right? So, these small metrics really matter in defining how the overall efficiency of the engineering or the development process looks like. So, I just wanted to understand from you, just for example, as I mentioned, how do you look at code collaboration or how do you look at, uh, roadmap contribution or how do you look at initial code quality, deliverability, uh, when it comes to your team. And I understand like you are a software agency, maybe a roadmap contribution thing might not be very relevant. So, maybe we can skip that. But otherwise, I think everything else would definitely be relevant to your context. 

Ben Parisot: Sure. Yeah, being an agency, we work with multiple different clients, um, different repos in different locations even, some of them in GitHub, Bitbucket, um, GitLab, like we've got clients with code everywhere. Um, so having consistent metrics across all of like the DORA or SPACE framework is pretty difficult. So we've been able to piecemeal together metrics that make sense for our team. And as you said, like a lot of the metrics, they're for productivity and efficiency sake for sure, but they also then, if you like dig one level deeper, there is a developer experience metric below that. Um, so for instance, PR review, you know, you mentioned, um, like turnaround time on PRs, how quickly are people that are being assigned to review getting to it, how quickly are changes being implemented from after a review has been submitted; um, those are on the surface level, very productivity- driven metrics. We want our team to be moving quickly and reviewing things in a timely manner. But as you mentioned, like a slow PR turnaround time can be a symptom of bad communication and that can lead to a lot of frustration, um, and even like disagreement amongst team members. So that's a really like developer satisfaction metric as well, um, because we want to make sure no one's frustrated with any of their coworkers, uh, or bottlenecked and just stuck not knowing what to do because they have a PR that hasn't been touched. 

We use a couple of different tools. We're luckily a pretty small team, so my job as a manager and collecting all this data from the metrics is doable for now, not necessarily scalable, but doable with the size of our team. I do a lot of manual data collection, and then we also have various third-party integrations and sort of marketplace plugins. So, we work a lot in GitHub, and we use some plugins in GitHub to help us give some insight into, for instance, like you said, like commit time or number of commits within a PR size of those commits you know, we have an engineering handbook that has a lot of our, you know, agreed upon best practices and those are generally in place so that our developers can be more efficient and happy in their work, so, you know, it can feel a little nitpicky to be like, "Oh, you only had two commits in this giant PR." Like, if the work's getting done, the work's getting done. However you know, good commit, best practice. We try to practice atomic commits here at Planet Argon. That is going to, you know, not only like create easier rollbacks if necessary, there's just a lot of reasons for our best practices. So the metrics try to enforce the best practices that we have in mind already, or that we have in place already. And then, yeah, uh, you asked what other tools or? 

Kovid Batra: So, yeah, I mean talking specifically about the team satisfaction piece. I think that's very critical. Like, that's one of the fundamental things that should be there in the team so that you make sure the team is actually productive, right? From what you have explained, uh, the kind of best practices you're following and the kind of things that you are doing within the team reflect that you are concerned about that. So, are there any specific metrics there which you track? Can you like name a few of them for us? 

Ben Parisot: Sure, sure. Um, so for team satisfaction, we track a number of following metrics. We track build processes, code review, deep work, documentation, ease of release, local development, local environment setup, managing technical debt, review turnaround, uh, roadmap and priorities, and test coverage and test efficiency. So these are all sentiment metrics. I use them from a management perspective to not only get a feeling of how the team is doing in terms of where their frustrations lie, but I also use it to direct my work. If I see that some of these metrics or some of these areas of focus are receiving like consistently low sentiment scores, then I can brainstorm with the team, bring it to an all-hands meeting to be like, "Here's some ideas that I have for improving these. What is your input? What's a reasonable timeline look like?" And then, show them that, you know, their continued participation in these, um, these surveys, these developer experience surveys are leading to results that are improving their work experience. 

Kovid Batra: Makes sense. Out of all these metrics that you mentioned, which are those top three or four, maybe? Because it's very difficult to, uh, look at 10, 12 metrics every time, right? So.. 

Ben Parisot: Yes. 

Kovid Batra: There is a go-to metric or there are a few go-to metrics that quickly tell you okay, what's going on, right? So for me, sometimes what I basically do is like if I want to see if the code, initial code quality is coming out good or not I'm mostly looking at how many commits are happening after the PRs are being raised for review and how many comments were there. So when I look at these two, I quickly understand, okay, there is too much to and fro happening and then quality initially is not coming out well. But in the case of team satisfaction, of course, it's a very feeling, qualitative-driven, uh, piece we are talking about. But still, if you have to objectify it with, let's say three or four metrics, what would be those three or four important metrics that you think impact the developer's experience or developer's satisfaction in your team? 

Ben Parisot: Sure. So we actually have like 4 KPIs that we track in addition to those sentiment metrics, and they are also sort of sentiment metrics as well, but they're a little higher level. Um, we track weekly time loss, ease of delivery, engagement, uh, and perceived productivity. So we feel like those touch pretty much all of the different aspects of the software development life cycle or the developer's day-to-day experience. So, ease of delivery, how, you know, how easy is it for you to be, uh, deploying your code, um, that touches on any bottlenecks in the deployment pipelines, any issues with PRs, PR reviews, that sort of thing. Um, engagement speaks to how excited or interested people are about the work that they're doing. So that's the more meat of the software development work. Um, perceived productivity is how, you know, how well you think you are being productive or how productive you feel like you are being. Um, and that's really important because sometimes the hard metrics of productivity and the perceived productivity can be very different, and not only for like, "Oh, you think you're being very productive, but you're not on paper." Um, oftentimes, it's the reverse where someone feels like they aren't being productive at all and I can go, and I know that from their sentiment score. Um, but then I can go and pull up PRs that they've submitted or work that they've been doing in JIRA and just show them a whole list of work that they've done. I feel like sometimes developers are very in the weeds of the work and they don't have a chance to step back and look at all that they've accomplished. So that's an important metric to make sure that people are recognizing and appreciating all of the work and their contributions to a project and not feeling like, "Oh, this one ticket, I haven't been very productive on. So, therefore, I'm not a very good developer." Uh, and then finally, weekly time loss is a big one. This one is more about everything outside of the development work. So this also focuses on like, how often are you in your flow? Are you having too many meetings? Do you feel like, you know, the asynchronous current communication that is just the nature of our distributed team? Is that blocking you? And are you being, you know, held up too much by waiting around for a response from someone? So that's an important metric that we look at as well. 

Kovid Batra: Makes sense. Thanks. Thanks for that detailed overview. I think team satisfaction is of course, something that I also really, really care about. Beyond that, what do you think are those important areas of engineering efficiency that really impact the broader piece of efficiency? So, uh, just to give you an example, is it you're focusing mostly in your teams related to deliverability or are you focusing more related to, uh, the quality of the work or is it something related to maybe sprints? I'm really just throwing out ideas here to understand from you how you, uh, look at which are those important areas of engineering efficiency other than developer satisfaction. 

Ben Parisot: Yeah. I think, right. I think, um, for our company, we're a little bit different even than other agencies. Companies don't come to us often for large new feature development. You know, as I mentioned at the top of the recording, we inherit really old applications. We inherit applications that have, you know, the developers have just given up on. So a lot of our job is modernizing and improving the quality of the code. So, you know, we try to keep our deployment metrics, you know, looking nice and having all of the metrics around deployment and, uh, post-deployment, obviously. Um, but from my standpoint, I really focus on the quality of the code and sort of the longevity of the code that the team is writing. So, you know, we look at coding practices at Planet Argon, we measure, you know, quality in a lot of different ways. Some of them are, like I said earlier, like practicing atomic commits size of PRs. Uh, because we have multiple projects that people are working on, we have different levels of understanding of those projects. So there's like, you know, some people that have a very high domain knowledge of an application and some people that don't. So when we are submitting PRs, we try to have more than one person look at a PR and one person is often coming with a higher domain knowledge and reviewing that code as it, uh, does it satisfy the requirements? Is it high-quality code within the sort of ecosystem of that existing application? And then, another person is looking at more of the, the best practices and the coding standards side of it, and reviewing it just from a more, a little more objective viewpoint and not necessarily as it's related to that.

Let's see, I'm trying to find some specific metrics around code quality. Um, commits after a PR submission is one, you know, if where you are finding that our team is often submitting a PR and then having to go back and work a lot more on it and change a lot more things; that means that those PRs are probably not ready or they're being submitted a little earlier. Sometimes that's a reflection of the developer's understanding of the task or of the code. Sometimes it's a reflection of the clarity of the issue that they've been assigned or the requirements. You know, if the client hasn't very clearly defined what they want, then we submit a PR and they're like, "Oh, that's not what I mean." so that's an important one that we looked at. And then, PR approval time, I would say is another one. Again, that one is both for our clients because we want to be moving as quickly with them as we can, even though we don't often work against hard deadlines. We still like to keep a nice pace and show that our team is active on their projects. And then, it's also important for our team because nobody likes to be waiting around for days and days for their PR to be reviewed. 

Kovid Batra: Makes sense. I think, yeah, uh, these are some critical areas and almost every engineering team struggles with it in terms of efficiency and what I have felt also is not just organization, right, but individual teams have different challenges and for each team, you could be looking at different metrics to solve their problems. So one team would be having a low deployment frequency because of maybe not enough tooling in place and a lot of manual intervention being there, right? That's when their deployments are not coming out well or breaking most of the time. Or it could be for another team, the same deployment frequency could be a reason that the developers are actually not writing or doing enough number of like PRs in a defined period of time. So there is a velocity challenge there, basically. That's why the deployment frequency is low. So most of the times I think for each team, the challenge would be different and the metrics that you pick would be different. So in your case, as you mentioned, like how you do it for your clients and for your teams is a different method. Cool. I think with that, I.. Yeah, you were saying something. 

Ben Parisot: Oh, I was, yeah. I was gonna say, I think that, uh, also, you know, we have sort of across the board, company best practice or benchmarks that we try to reach for a lot of different things. For instance, like test coverage or code coverage, technical debt, and because we inherit codebases in various levels of, um, quality, the metric itself is not necessarily good or bad. The progress towards a goal is where we look. So we have a code coverage metric, uh, or goal across the company of like 80, 85%, um, test coverage, code coverage. And we've inherited apps, big applications, live applications that have zero test coverage. And so, you know, when I'm looking at metrics for tests, uh, you know, it's not necessarily, "Hey, is this application's test coverage meeting our standards? Is it moving towards our standards?" And then it also gets into the individual developers. Like, "Are you writing the tests for the new code that you're writing? And then also, is there any time carved out of the work that you have on that project to backfill tests?" And similarly, with, uh, technical debt, you know, we use a technical debt tagging tool and oftentimes, like every three months or so we have a group session where we spend like an hour, hour and a half with our cameras off on zoom, just going into codebases that we're currently working on and finding as much technical debt as we can. Um, and that's not necessarily like, oh, we're trying to, you know, find who's not writing the best code or what the, uh, you know, trying to find all the problems that previous developers caused. But it's more of a is this, you know, other areas for like, you know, improvements? Right. And also, um, is there any like potential risks in this codebase that we've overlooked just by going through the day-to-day? And so, the goal is not, "Hey, we need to have no technical debt ever." It's, "Are we reducing the backlog of tech debt that we're currently working within?" 

Kovid Batra: Totally, totally. And I think this again brings up that point that for every team, the need of a metric would be very different. In your case, the kind of projects you are getting by default, you have so much of technical debt that's why they're coming to you. People are not managing it and then the project is handed over to you. So, having that test coverage as a goal or a metric is making more sense for your team. So, agreed. I think I am a hundred percent in line with that. But one thing is for sure that there must be some level of, uh, implementation challenges there, right? Uh, it's not like straightforward, like you, you are coming in with a project and you say, "Okay, these are the metrics we'll be tracking to make sure the efficiency is in place or not." There are always implementation challenges that are coming with that. So, I mean, with your examples or with your experience, uh, what do you think most of the teams struggle with while implementing these metrics? And I would be more than happy to hear about some successes or maybe failures also related to your implementation experiences. 

Ben Parisot: Yeah. So I would just say the very first challenge that we face is always, um. I don't want to see team morale, but, um, the, somewhat like overwhelming nature depending on the state of the codebase. Like if you inherit a codebase, it's really large and there's no tests. That's, you know, overwhelming to think about, having to go and write all those tests, but it's also overwhelming and scary to think, "Oh, what if something breaks?" Like, a test is a really good indicator of where things might be breaking and there's none of that, so the guardrails are off. Um, and that's scary. So helping people get used to, especially newer developers who have just joined the team, helping them get used to working within a codebase that might not be as nice and clean as previous ones that they've worked with is a big challenge. In terms of actual implementation, uh, we face a number of challenges being an agency. Like I mentioned earlier, some codebases are in, um, different places like GitHub or Bitbucket. You know, obviously those tools have generally the same features and generally the same, you know, sort of dashboard type of things. Um, but if we are using any sort of like integrated tool to measure metrics around those things, if we get it, um, a repo that's not in the platform, it's not on the platform where we have that integration happening, then we don't get the metrics on that, or we have to spin up a new integration. 

Kovid Batra: Yeah. 

Ben Parisot: Um, for some of our clients, we have access to some of their repos and not others, and so, like we are working in an app ecosystem where the application that we are responsible for is communicating and integrated with another application that we don't, we can't see; and so that's very difficult at times. That can be a challenge for implementing certain metrics, because we need to know, like, especially performance metrics for the application. Something might be happening on this hidden application that we don't have any control over or visibility into. 

Um, and then what else? Just I would say also a challenge that we face is the, um, most of our developers are working on 2 to 3 applications at a time, and depending on the length of the engagement, um, sometimes people will switch on and off. So it can be difficult to track metrics for just a single project when developers are working on it for like maybe a few weeks or a few months and then leaving. Sometimes we have like a dedicated developer who's lead and then, have a support developer come in when necessary. And so that can be challenging if we're trying to parse out, like why there might've been a shift in the metrics or like a spike in one metric or another, or a drop and be like, "Okay, well, let's contextualize that around who was working on this project, try to determine like, okay, is this telling us something important about the project itself, or is it just data that is displaying the adding or subtracting of different developers to the project?" So that can be a challenge. 

Specifically, I can mention an actual sort of case study that we had. Uh, we were using Code Climate, which is a tool that we still use. We use the quality tool for like audits and stuff. Um, but when I first started applying to Argon, I wanted to implement its velocity tool, which is like the sister tool to quality and it is like very heavily around cycle time. Um, and it was all great, I was very excited about it. Went and signed up, um, went and connected our GitHub accounts, or I guess I did the Bitbucket account at the time cause most of our repos were in Bitbucket. Um, didn't realize at the time at least that you could only integrate with one platform. And so, even though we had, uh, we had accounts and we had clients with applications on GitHub, we were only able to integrate with Bitbucket. So some engineers' work was not being caught in that tool at all because they were working primarily in GitHub application. And again, like I said, sometimes developers would then go to one of the applications in Bitbucket, help out and then drop off. So it was just causing a lot of fluctuations in data and also not giving us metrics for the entire team consistently. So we eventually had to drop it because it was just not a very valuable tool, um, in that it was not capturing all of the activities of all of our engineers everywhere they were working. Um, I wished that it was, but it's the nature of the agency work and also, you know, having people that are, um. 

Kovid Batra: Yeah, I totally agree on that point and the challenges that you're facing are actually very common, but at the same time, uh, having said that, I believe the tooling around metrics observation and metrics monitoring has come way ahead of what you have been using in Code Climate. So, the challenge still remains, like most of the teams try to gather metrics manually, which is time-consuming, or in your case where agencies are working on different projects, it's very difficult or different codebases, very difficult to gather the right metrics for individual developers there also. Somehow, I think the challenges are very valid, but now, the tooling that is available in the market is able to cater to all those challenges. So maybe you want to give it a try and see, uh, your metrics implementation getting in place. But yeah, I think, thanks for highlighting these pointers and I think a lot of people, a lot of engineering managers and engineering leaders struggle with the same challenges while implementing those. So totally, uh, bringing these challenges in front of the audience and talking about it would bring some level of awareness to handle these challenges as well. 

Great. Great, Ben. I think with this, uh, we would like to bring an end to our today's episode. It was really amazing to understand how Planet Argon is working and you are dealing with those challenges of implementing metrics and how well you are actually doing, even though the right tooling or right things are not in place, but the important part is you realize the purpose. You don't probably go ahead and do it for the sake of doing it. You're actually doing it where you have a purpose and you know that this can impact the overall productivity of the team and also bring credibility with your clientele that yes, we are doing something and you have something to show in numbers also. So, I really appreciate that. 

And while, like before we say goodbye, is there parting advice or something that you would like to speak with the audience? Please go ahead. 

Ben Parisot: Oh, wow! Um, yeah, sure. So I think your point about like understanding the purpose of the metrics is important. You know, my team, uh, I am the manager of a small team and a small company. I wear a lot of hats and I do a lot of different things for my team. They show me a lot of grace, I suppose, when I have, you know, incomplete data for them, I suppose. Like you said, there's a lot of tools out there that can provide a more holistic, uh, look. Um, and I think that if you are an agency, uh, if you're a manager on a small team and you sort of struggle to sort of keep up with all of the metrics that you have even promised for your team or that you know that you should be doing, uh, if you really focus on the ones that are impacting their day-to-day experience as well as like the value that they're providing for either, you know, your company's internal stakeholders or external clients, you're going to quickly see the metrics that are most important and your team is going to appreciate that you're focusing on those, and then, the rest of it is going to fall into place when it does. And when it doesn't, um, you know, your team's not going to really be too upset because they know, they see you focusing on the stuff that matters most to them. 

Kovid Batra: Great. Thanks a lot, Ben. Thank you so much for such great, insightful experiences that you have shared with us. And, uh, we wish you all the best, uh, and your kid a very happy birthday in advance. 

Ben Parisot: Thank you. 

Kovid Batra: All right, Ben. Thank you so much for your time. Have a great day. 

Ben Parisot: Yes. Thanks.

‘Evolution of Software Testing: From Brick Phones to AI’ with Leigh Rathbone, Head of Quality Engineering at CAVU

In the latest episode of ‘groCTO: Originals’ (formerly ‘Beyond the Code: Originals’), host Kovid Batra engages with Leigh Rathbone, Head of Quality Engineering at CAVU who has a rich technical background with reputable organizations like Sony Ericsson and The Very Group. He has been at the forefront of tech innovation, working on the first touchscreen smartphone and smartwatch, and later with AR, VR, & AI tech. The conversation revolves around ‘Evolution of Software Testing: From Brick Phones to AI’.

The podcast begins with Leigh introducing himself and sharing a life-defining moment in his career. He further highlights the shift from manual testing to automation, discussing in depth the automation framework for touchscreen smartphones from 19 years ago. Leigh also addresses the challenges of implementing AI and how to motivate teams to explore automation opportunities. He also discusses the evolution of AR, VR, and 3D gaming & their role in shaping modern-day testing practices, emphasizing the importance of health and safety considerations for testers.

Lastly, Leigh offers parting advice urging software makers & testers to always prioritize user experience & code quality when creating software.


  • 00:06 - Leigh’s Introduction
  • 01:07 - Life-defining Moment in Leigh’s Career
  • 04:10 - Evolution of Software Testing
  • 09:20 - Role of AI in Testing
  • 11:14 - Conflicts with Implementing AI
  • 15:29 - Adapting to AI with Upskilling
  • 21:02 - Evolution of AR, VR & 3D Gaming
  • 25:45 - Unique Value of Humans in Testing
  • 32:58 - Conclusion & Parting Advice

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today, we are lucky to have a tech industry veteran with us on our show today. He is the Head of Quality Engineering at CAVU. He has had fascinating 25-plus years of engineering and leadership experience, working on cutting-edge technologies including the world's first smartphone and smartwatch. He was also involved in the development of progressive download and DRM technologies that laid the groundwork for modern streaming services. We are grateful to have you on the show, Leigh. 

Leigh Rathbone: Thank you, Kovid. It's great to be here. I'm really happy to be invited. I'm looking forward to sharing a few experiences and a few stories in order to hopefully inspire and help other people in the tech industry. 

Kovid Batra: Great, Leigh. And today, I think they would have a lot of things to deep dive into and learn from you, from your experience. But before we go there, where we talk about the changing landscape of software testing, coming from brick phones to AI, let's get to know a little bit more about each other. Can you just tell us something about yourself, some of your life-defining experiences so that I and the audience can know you a little more? 

Leigh Rathbone: Yeah. Well, I'm Leigh Rathbone. I live in the UK, uh, in England. I live just North of a city called Liverpool. People might've heard of Liverpool because there's a few famous football teams that come from there, but there's also a famous musical band called the Beatles that came from Liverpool. So, I live just North of Liverpool. I have two children. I'm happily married, been married for over 20 years. I am actually an Aston Villa football fan. I don't support any of the Liverpool football clubs. I'm not a cricket fan or a rugby fan. It's 100 percent football for me. I do like a bit of fitness, so I like to get out on my bike. I like to go to the gym. I like to drink alcohol. Am I allowed to say that, Kovid? Am I allowed to say that? I do like a little bit of alcohol. Um, and like everybody else, I think I'm addicted to Netflix and all the streaming services, which is quite emotional for me, Kovid, because having played a part in the building blocks and a tiny, tiny part in the building blocks of what later became streaming, when I'm listening to Spotify or when I'm watching something on Amazon Video or Netflix, I do get a little bit emotional at times thinking, "Oh my God! I played a minute part of that technology that we now take for granted." So, that's my sort of out-of-work stuff that, um, I hope people will either find very boring or very interesting, I don't know. 

Kovid Batra: No, I definitely relate to it and I would love to know, like, which was the last, uh, series you watched or a movie you watched on Netflix and what did you love about it? 

Leigh Rathbone: So, I watched a film last night called 'No Escape'. Um, it's a family that goes to, uh, a country in Asia and they don't say the name of the country for legal reasons. Um, but they get captured in a hotel and it's how they escape from some terrorists in a hotel with the help of Brosnan who's also in the film. So, yeah, it was, uh, it was high intensity, high energy and I think that's probably why I liked it because from the very almost 5-10 minutes, it's like, whoa, what's going on here? So, it was called 'No Escape'. It's on Netflix in the UK. I don't know whether it'll be on Netflix across the world. But yeah, it's an old film. It's not new. I think it's about three years old. But yeah, it was quite enjoyable. 

Kovid Batra: Cool, cool. I think that that's really interesting and thank you for such a quick, sweet intro about yourself. And of course, your contributions are not minute. Uh, I'm sure you would have done that in that initial stage of tech when the technology was building up. So, thanks on behalf of the tech community there. 

Uh, all right, Leigh, thank you so much and let's get started on today's main topic. So, you come from a background where you have seen the evolution of this landscape of software testing and as I said earlier, also like from brick phones to AI, I'm sure, uh, you have a lot of experiences to share from the days when it all started. So, let's start from the part where there was no automation, there was manual testing, and how that evolved from manual testing to automation today, and how things are being balanced today because we are still not 100 percent automated. So, let's talk about something like, uh, your first smartphone, uh, maybe where you might not have all the automation, testing or sophisticated automation possible. How was your experience in that phase? 

Leigh Rathbone: Well, I am actually holding up for those people that, uh, can either watch the video. 

Kovid Batra: Oh my God! Oh my God! 

Leigh Rathbone: I'm holding up the world's first touchscreen smartphone and you can see my reflection and your reflection on the screen there. This is called the Sony Ericsson P800. I worked on this in 2002 and it hit the market in 2003 as the world's first touchscreen smartphone, way before Apple came to the market. But actually, if I could, Kovid, can I go back maybe four years before this? Because there's a story to be told around manual testing and automation before I got to this, because there is automation, there is an automation story for this phone as well. But if I can start in 1999, I've been in testing for 12 months and I moved around a lot in my first four years, Kovid because I wanted to build up my skillsets and the only way to do that was to move jobs. So, my first four years, I had four jobs. So, in 1999 I'm in my second job. I'm 12 months into my testing career and I explore a tool called WinRunner. I think it was the first automation tool. So, there I am in 1999, writing automation scripts without really knowing the scale of what was going to unfold in front of not just the testing community, but the tech community. And when I was using this tool called WinRunner. Oh, Kovid, it was horrible. Oh my God! So, I would be writing scripts and it was pretty much record and playback, okay? So, I was clicking around, I was looking at the code, I was going, "Oh, this is exciting." And every time a new release would come from the developers, none of my scripts would work. You know the story here, Kovid. As soon as a new release of code comes out, there's bug fixes, things move around on the screens, you know, different classes change, there might be new classes. This just knocks out all of my scripts. So, I'd spend the next sort of, I don't know, eight days, working, reworking, refactoring my automation scripts. And then, I just get to the point where I was tackling new scripts for the new code that dropped and a new drop of code would come. And I found myself in this cycle in 1999 of using WinRunner and getting a little bit excited but getting really frustrated. And I thought, "Where is this going to go? Has it got a future in tech? Has it got a future in testing?" Cause I'm not seeing the return on investment with the way I was using it. So, at that point in time, 1999, I saw a glimpse, a tiny glimpse of the future, Kovid. And that was 25 years ago. And for the next couple of years, I saw this slow introduction, very, very slow back then, Kovid, of manual testing and automation. And the two were very separate, and that continued for a long, long time, whereby you'd have manual testers and automation testers. And I feel that's almost leading and jumping ahead because I do want to talk about this phone, Kovid, because this phone was touchscreen, and we had automation in 2005. We built an automation framework bespoke to Sony Ericsson that would do stress testing, soak testing, um, you know, um, it would actually do functional automation testing on a touchscreen smartphone. Let that sink into 19 years ago. We built a bespoke automation framework for the touchscreen smartphone. Let that sink in folks. 

Kovid Batra: Yeah. 

Leigh Rathbone: Unreal, absolutely unreal, Kovid. Back in the day, that was pretty much unheard of. Unbelievable. It still blows my mind to this day that in 2005, 19 years ago, on a touchscreen smartphone, we had an automation framework that added loads and loads of value. 

Kovid Batra: Totally, totally. And was this your first project wherein you actually had a chance to work hands-on with this automation piece? Like, was that your first project? 

Leigh Rathbone: So, what happened here, Kovid, and this is a trend that happened throughout the testing and tech industry right up until about, I'd say that seven years ago, we had an automation team and a manual team. I'll give you some context for the size. The automation team was about five people. The manual test team was about 80 people. So, you can see the contrast there. So, they were doing pretty much what I was doing in 1999. They were writing some functional test scripts that we could use for regression testing. Uh, but they were mostly using it for soak testing. So in other words, random touches on the screen, these scripts needed to run for 24 hours in order for us to be able to say, "Yes, that can, that software will exist in live with a customer touching the screen for 24 hours without having memory leaks, as an example." So, their work felt very separate to what we were doing. There was a slight overlap with the functional testing where they'd take some of our scripts and turn them into, um, automated regression packs. But they were way ahead of the curve. They were using this automation pack for soak testing to make sure there was no memory leaks by randomly dibbing on a screen. And I say dibbing, Kovid, because you touched the screen with a dibber, right? It wasn't a finger. Yeah, you needed this little dibber that clicked onto the side of the phone in order to touch the screen. So, they managed to mimic random clicks on the screen in order to test for memory leaks. Fascinating. Absolutely fascinating. So at that point, we started to see a nice little return on investment on automation being used. 

Kovid Batra: Got it. Got it. And from there, how did it get picked up over the years? Like, how have teams collaborated? Was there any resistance from, of course, every time this automation piece comes in, uh, there is resistance also, right? People start pointing things. So, how was that journey at that point? 

Leigh Rathbone: I think there's always resistance to change and we'll see it with AI. When we come on to the AI section of the talk, we'll see it there. There will always be resistance to change because people go through fear when change is announced. So, if you're talking to a tester, a QA or a QE and you're saying, "Look, you're going to have to change your skill sets in order to learn this." They're gonna go through fear before they spot the opportunity and come up the other side. So, everywhere I've gone, there's been resistance to automation and there's something else here, Kovid, from the years 1998 to 2015, test teams were massive. They were huge. And because we were in the waterfall methodology, they were pretty much standalone teams and all the people that were in power of running these big teams, they had empires, and they didn't want to see those empires come down. So actually, resistance wasn't just sometimes from testers themselves, it was from the top, where they might say, "Oh, this might mean that the number of testers I need goes down, so, therefore, my empire shrinks." And there were test leaders out there, Kovid, doing that, very, very naughty people. Like, honestly, trying to protect their own, their own job, instead of thinking about the future. So, I saw some testers try and accelerate the use of automation. I also saw test leaders put the brakes on it because they were worried about the status of their jobs and the size of their empires. 

Kovid Batra: Right. And I think fast-forward to today, we won't take much long to jump to the AI part here. Like, a lot of automation Is already in place. According to your, uh, view of the tech industry right now uh, let's say, if there are a hundred companies; out of those hundred, how many are at a scale where they have done like 80 percent or 90 percent of automation of testing? 

Leigh Rathbone: God! 80 to 90 percent automation of testing. You'll never ever reach that number because you can do infinite amounts of testing, okay? So, let's put that one out there. The question still stands up. You're asking of 100 companies, how many people have automation embedded in their DNA? So I would probably, yeah, I would probably say it's in the region of 70 to 80 percent. And I'd be, I wouldn't be surprised if it's higher, and I've got no data to back that up on. What I have got to back that up on is the fact that I've worked in 14 different companies, and I spend a lot of time in the tech industry, the tech communities, talking to other companies. And it's very rare now that you come across a company that doesn't have automation. 

But here's the twist, Kovid, there's a massive twist here. I don't employ automation testers, okay? So 2015, I made a conscious effort and decision not to employ automation testers. I actually employed testers who can do the exploratory side and the automation side. And that is a trend now, Kovid, that really is a thing. Not many companies now are after QAs that only do automation. They want QAs that can do the exploratory, the automation, a little bit of performance, a little bit of security, the people skills is obviously rife. You know, you've got to put those in there with everything else. 

Kovid Batra: Of course. 

Leigh Rathbone: Yeah. So for me now, this trend that sort of I spotted in 2014 and I started doing in 2015 and I've done it at every company I've been to, that really is the big trend in testers and QAs right now. 

Kovid Batra: Got it. I think it's more like, uh, it's an ever-growing evolutionary discipline, right? Uh, every time you explore new use cases and it also depends on the kind of business, the products the company is rolling out. If there are new use cases coming in, if there are new products coming in, every time you can just have everything automated. So yeah, I mean, uh, having that 80-90% testing scale automated is something quite far-fetched for most of the teams, until and unless you are stagnated over one product and you're just running it for years and years, which is definitely not, uh, sustainable for any business. 

So here, my question would be, like, how do you ensure that your teams are always up for exploring that side which can be automated and making sure that it's being done? So, how do you make sure? One is, of course, having the right hires in the team, but what are the processes and what are the workflows that you implement there from time to time? People are, of course, doing the manual testing also and with the existing use cases where they can automate it. They're doing that as well. 

Leigh Rathbone: It's a really good question, Kovid, and I'll just roll back in the process a little bit because for me, automation is not just the QA person's task and not even test automation. I believe that is a shared responsibility. So, quality is owned by everybody in the team and everyone plays their different parts. So for me, the automation starts right with the developers, to say, "Well, what are you automating? What are your developer checks that you're going to automate?" Because you don't want developers doing manual checks either. You want them to automate as much as they can because at the unit test level and even the integration test level, the feedback loops are really quick. So, that means the test is really cheap. So, you're getting some really good, rich feedback initially to show that nothing obvious has broken early on when a developer adds new code. So, that's the first part. So, that now, I think is industry standard. There aren't many places where developers are sat there going, "I'm not going to write any tests at all." Those days are long, long gone, Kovid. I think all, you know, modern developers that live by the modern coding principles know that they have to write automated checks.

But I think your question is targeted at the QAs. So, how do we get QAs involved? So, you have to breed the curiosity gene in people, Kovid. So, you're absolutely right. You have to bring people in who have the skills because it's very, very hard to start with a team of 10 QAs where no one can automate. That's really hard. I've only ever done that once. That's really hard. So, what I have done is I've brought people in with the mindset of thinking about automation first. The mindset of collaborating with developers to see what they're automating. The curiosity and the skill sets to grow and develop and learn more about the tools. And then, you have to give people time, Kovid. There is no way you can expect people who don't have the automation skills to just upskill like that. It's just not fair. You have to support, support, and support some more. And that comes from myself giving people time. It's understanding how people learn, Kovid.

So, I'll give you an example. Pair learning. That's one technique where you can get somebody who can't automate and maybe you get them pairing with someone else who can't automate and you give them a course. That's point number one. Pair learning could be pairing with someone who does know automation and pairing them with someone who doesn't know automation. But guess what? Not everyone likes pairing because it's quite a stressful environment for some people. Jumping on a screen and sharing your screen while you type, and them saying, "No, you've typed that wrong." That can be quite stressful. So, some people prefer to learn in isolation but they like to do a brief course first, and then come back and actually start writing something right in the moment, like taking a ticket now that they're manually testing, and doing something and practising, then getting someone to peer review it. So, not everyone likes pair learning. Not everybody likes to learn in isolation. You have to understand your people. How do they like to learn and grow? And then, you have to understand, then you have to relay to them why you are asking them to learn and grow. Why am I asking people to change? 'cause the skill bases that's needed tomorrow and the day after and in two years time are different to the skill bases we need right now or even 10 years ago. And if people don't upskill, how are they going to stay relevant? 

Kovid Batra: Right. 

Leigh Rathbone: Everything is about staying relevant, especially when test automation came along, Kovid, and people were saying, "Hey, we won't need QAs because the automation will get rid of them." And you'd be amazed how many people believed that, Kovid, you'd be absolutely gobsmacked how many tech leaders had in their minds that automation would get rid of QAs. So, we've been fighting an uphill struggle since then to justify our existence in some cases, which is wrong because I think the value addition of QAs and all the crafts when they come together is brilliant. But for me, for people who struggle to understand why they need to upskill in automation, it's the need to stay relevant and keep adding value to the company that they're in.

Kovid Batra: Makes sense. And what about, uh, the changing landscape here? So basically, uh, you have seen that part where you moved to phones and when these phones were being built, you said like, that was the first time you built something for touchscreen testing, right? Now, I think in the last five to seven years, we have seen AR, VR coming into the picture, right? Uh, the processes that you are following, let's say the pair learning and other things that you bring along to make sure that the testing piece, the quality assurance piece is in place as you grow as a company, as you grow as a tech team. For VR, AR kind of technologies, how has it changed? How has it evolved? 

Leigh Rathbone: Well, massively, because if you think about testing back in the day, everybody tested on a screen. And most of us are still doing that. And this is why this phone felt different and even the world's first smartwatch, which is here. When I tested these two things, I wasn't testing on a screen. I was wearing it on my wrist, the watch, and I was using the phone in my hand in the environment that the end user would use it in. So, when I went to PlayStation, Kovid, and I was head of European Test Operations for Europe with PlayStation, we had a number of new technologies that came in and they changed the way we had to think about testing. So, I'll give you some examples. Uh, the PlayStation Move, where you had the two controllers that can control the game, uh, VR, AR, um, 3D gaming. Those four bits of technology, and I've only reeled off four, there was more. Just in three years at PlayStation, I saw how that changed testing. So, for VR and 3D, you've got to think about health and safety of the tester. Why? Because the VR has bugs in it, the 3D has bugs in it, so it makes the tester disorientated. You're wearing.. They're not doing stuff through their eyes, their true eyes, they're doing it through a screen that has bugs in it, but the screen is right up and close to their eyes. So there was motion sickness to think about. And then, of course, there was the physical space that the testers were in. You can't test VR sat at a desk, you have to stand up. Look, because that's how the end users do it. When we tested the PlayStation Move with the two controllers, we had to build physical lounges for testers to then go into to test the Move because that's how gamers were going to use the game. Uh, I remember Microsoft saying that they actually went and bought a load of prompts for the Kinect. Um, so wigs and blow-up bodies to mimic different shapes of people's bodies because the camera needed to pick up everybody's style of hair, whether you're bald like me, or whether you have an afro, the camera needed to be able to pick you up. So all of a sudden, the whole testing dynamics have changed from just being 2 plus 2 equals 4 in a field, to actually can the camera recognize a bald, fat person playing the game. 

Everything changed. And this is what I mean. Now, it's performance. Uh, for VR, for augmented reality, mixed reality glasses, there's gonna be usability, there's gonna be performance, there's gonna be security. I'll give you one example if I can, Kovid. I'm walking down the road, and I'm wearing, uh, mixed reality glasses, and there's a person coming towards me in a t-shirt that I like, and all of a sudden, my pupils dilate, a bit of sweat comes out my wrist, That's data. That's collected by the wearable tech and the glasses. They know that I like that t-shirt. All of a sudden, at the top right-hand corner of those glasses, a picture of me wearing that t-shirt appears, and a voice appears on the arm and goes, "Would you like to purchase?" And I say, "Yes." And a purchase is made with no interaction with the phone. No interaction with anything except me saying 'yes' to a picture that appeared in the top right-hand corner of my phone. Performance was key there. Security was really key because there's a transaction of payments that's taken place. And usability, Kovid. If that picture appeared in the middle of the glasses, and appeared on both glasses, I'm walking out into the road in front of a bus, the bus is going to hit me, bang I'm dead because of usability. So, the world is changing how we need to think about quality and the user's experience with mixed reality, VR, AR is changed overnight.

Kovid Batra: I think I would like to go back to the point where you mentioned automation replacing humans, right? Uh, and that was a problem. And of course, that's not the reality, that cannot happen, but can we just deep dive into the testing and QA space itself and highlight what exactly today humans are doing that automation cannot replace? 

Leigh Rathbone: Ooh! Okay. Well, first of all, I think there's some things that need to be said before we answer that, Kovid. So, what's in your head? So, when I think of AI, when I think of companies, and this does answer your question, actually, every company that I've been into, and I've already mentioned that I've worked in a lot, the culture, the people, the tech stack, the customers, when you combine all of those together for each company, they're unique, absolutely unique to every single company. When you blend all of those and the culture and make a little pot of ingredients as to what that company is, it's unique. So, I think point number one is I think AI will always help and assist and is a tool to help everyone, but we have to remember, every company is unique and AI doesn't know that. So, AI is not a human being. AI is not creative. I think AI should be seen as a member of the team. Now if we took that mindset, would we invite everybody who's a member of the team into a meeting, into an agile ceremony, and then ignore one member of that team? We wouldn't, would we? So, AI is a tool and if we see it as a member of the team, not a human being, but a member of the team, why wouldn't we ask AI its opinion with everything that we do as QAs, but as an Agile team? So if we roll right back, even before a feature or an epic gets written, you can use AI for research. It's a member of the team. What do you think? What happened previously? It can give you trends. It can give you trends on bugs with previous projects that have been similar. So, you can use AI as a member of the team to help you before you even get going. What were the previous risks on this project that look similar? Then when you start getting to writing the stories, why wouldn't you ask AI its opinion? It's a member of the team. But guess what? Whatever it gives you, the team can then choose whether they want to use it, or tweak it, or not use it, just like any other member of the team. If I say this is my opinion, and I think we should write the story with this, the team might disagree. And I go, "Okay, let's go with the team." So, why don't we use AI as exactly the same, Kovid, and say, "When we're writing stories, let's ask it. In fact, let's ask it to start with 'cause it might get us into a place where we can refactor that story much quicker." Then when we write code, why aren't we as devs using AI as a member, doing pair programming with it? And if you're already pair programming with another developer, add AI as the third person to pair program with. It'll help you with writing code, spotting errors with code, peer reviews, pull requests. And then, when we come to tests, use it as a member of the team. " I'm new to learning Cypress, can you help me?" Goddamn right, it can. "I've written my first Cypress test. What have I done wrong?" It's just like asking another colleague. Right, except it's got a wider sort of knowledge base and a wider amount of parameters that it's pulling from. 

So for me, will AI replace people? Yes, absolutely. But not just in testing, not just in tech, AI has made things easily accessible to more people outside of tech as well. So, will it replace people's jobs? I'm afraid it will. Yes. But the people who survive this will be the ones who know how to use AI and treat it as a member of the team. Those people will be the last pots of people. They will be the ones who probably stay. AI will replace jobs. I don't care what people say, it will happen. Will it happen on a large scale? I don't know. And I don't think anyone does. But it will start reducing number of people in jobs, not just in tech. 

Kovid Batra: That would happen across all domains, actually. I think that that's very true. Yeah. 

So basically, I think it's more around the creativity piece, wherein if there are new use cases coming in, the AI is yet not there to make sure that you write the best, uh, test case for it and do the testing for you, or in fact, automate that piece for the coming, uh, use cases, but if the teams are using it wisely and as a team member, as you said, that's a very, very good analogy, by the way, uh, that's a great analogy. Uh, I think that's the best way to build that context for that team member so that they know what the whole journey has been while releasing an epic or a story, and then, probably they would have that creativity or that, uh, expertise to give you the use case and help you in a much better way than it could do today, like without hallucinating, without giving you results that are completely irrelevant. 

Leigh Rathbone: Yeah, I totally agree, Kovid. And I think this is, um, if you think about what companies should be doing, companies should be creating new code, new experiences for their customers, value add code. If we're just recreating old stuff, the company might not be around much longer. So, if we are creating new stuff, and let's make an assumption that, I don't know, 50 percent of code is actually new stuff that's never been out there before. Well, yeah, AI is going to struggle with knowing what to do or what automation test it could be. It can have a good stab because you can set parameters and you can say, you can give it a role, as an example. So, when you're working with chatGPT, you can say, as a professional tester or as a, you know, a long-term developer, what would be my mindset on writing JavaScript code for blah, blah, blah, blah? And it will have a good stab at doing it. But if it's for a space rocket that can go 20 times the speed of light, it might struggle because no one's done that yet and put the data back into the LLM, yet. 

Kovid Batra: Totally. Totally makes sense. Great. I think, Leigh, uh, with this thought, I think we'll bring our discussion to an end for today. I loved talking to you so much and I have to really appreciate the way you explain things. Great storytelling, great explanation. And you're one of the finest ones whom I have brought on the show, probably, so I would love to have another show with you, uh, and talk and deep dive more into such topics. But for today, I think we'll have to say goodbye to you, and before we say that, I would love for you to give our audience parting advice on how they should look at software quality testing in their career. 

Leigh Rathbone: I think that that's a really good question. I think the piece of advice, regardless of what craft you're doing in tech, always try and think quality and always put the customer at the heart of what you're trying to do because too many times we create software without thinking about the customer. I'll give you one example, Kovid, as a parting gift. Anybody can go and sit in a contact centre and watch how people in contact centres work, and you'll understand the thing that I'm saying, because we never, ever create software for people who work in contact centres. We always think we're creating software that's solving their problems, but you go and watch how they work. They work at speed. They'll have about three different systems open at once. They'll have a notepad open where they're copying and pasting stuff into. What a terrible user experience. Why? Because we've never created the software with them at the heart of what we were trying to do. And that's just one example, Kovid. The world is full of software examples where we do not put the customer first. So we all own quality, put the customer front and center. 

Kovid Batra: Great. I think, uh, best advice, not just in software testing or in general or any aspect of business that you're doing, but also I think in life you have to.. So I believe in this philosophy that if you're in this world, you have to give some value to this world and you can create value only if you understand your environment, your surroundings, your people. So, to always have that empathy, that understanding of what people expect from you and what value you want to deliver. So, I really second that thought, and it's very critical to building great pieces of software, uh, in the industry also. 

Leigh Rathbone: Well, Kovid, you've got a great value there and it ties very closely with people that write code, but leaders as well. So, developers should always leave the code base in a better state than they found it. And leaders should always leave their people in a much better place than when they found them or when they came into the company. So, I think your value is really strong there. 

Kovid Batra: Thank you so much. All right, Leigh, thank you. Thank you so much for your time today. It was great, great talking to you. Talk to you soon. 

Leigh Rathbone: Thank you, Kovid. Thank you. Bye. 

‘Team Building 101: Communication & Innovation’ with Paul Lewis, CTO at Pythian

In the latest episode of the ‘groCTO: Originals’ podcast (formerly Beyond the Code), host Kovid Batra welcomes Paul Lewis, CTO at Pythian and board member at the Schulich School of Business, who brings extensive experience from companies like Hitachi Vantara & Davis + Henderson. The topic for today’s discussion is ‘Team Building 101: Communication & Innovation’.

The episode begins with an introduction to Paul, offering insights into his background. During the discussion, Paul stresses the foundational aspects of building strong tech teams, starting with trusted leadership and clearly defining vision and technology goals. He provides strategies for fostering effective processes and communication within large, hybrid, and remote teams, and explores methods for keeping developers motivated and aligned with the broader product vision. He also shares challenges he encountered while scaling at Pythian and discusses how his teams manage the balance between tech and business goals, emphasizing the need for innovation & planning for future tech.

Lastly, Paul advises aspiring tech leaders to prioritize communication skills alongside technical skills, underscoring the pivotal role of 'code communication' in shaping successful careers.


  • 00:05 - Paul’s introduction
  • 02:47 - Establishing a collaborative team culture
  • 07:01 - Adapting to business objectives
  • 10:00 - Aligning developers to the basic principles of the org
  • 12:57 - Hiring & talent acquisition strategy
  • 17:31 - Processes & communication in growing teams
  • 22:15 - Communicating & imbibing team values
  • 24:33 - Challenges faced at Pythian
  • 26:00 - Aligning tech innovation with business requirements
  • 30:24 - Parting advice for aspiring tech leaders

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has more than 25 years of engineering leadership experience. He has been a CTO for organizations like Hitachi Vantara and today, he's working as a CTO with Pythian. Welcome to the show. Great to have you here, Paul. 

Paul Lewis: Hi there. Great to be here. And sadly, it's slightly more than 30 years versus 25 years. Don't want to shame you. 

Kovid Batra: My bad. All right, Paul. So, before we dive into today's topic, by the way, today's topic, audience for you, uh, it's building tech teams from scratch. But before we move there, before we hear out Paul's thoughts on that, uh, Paul, can you give us a quick intro about yourself? Or maybe you would like to share some life-defining moments of your life. Can you just give us a quick intro there? 

Paul Lewis: Sure. Sure. So I've been doing this for a long time, as we just mentioned. Uh, but I've, I've had the privilege of seeing sort of the spectrum of technology. First 17 years in IT, like 5, 000 workloads and 29 data centers. You know, I was involved in the purchase of billions of dollars of hardware and software and services, and then moving to Hitachi, a decade of OT, right? So, I get to see what technology looks like in the real world, the impact to, uh, sort of the human side of the world and nuclear power plants and manufacturing and hospitals.

Uh, and then, the last three years at Pythian, uh, which is more cloud and data services. So, I get to see sort of the insight side of the equation and what the new innovation and technology might look like in the real future. I do spend time with academics. I'm on the board of Schulich School of Business, Masters of Technology Leadership, and I spend time with the students on Masters of Management and AI, Masters of Business Analytics. 

And then, I spend at least once a quarter with a hundred CIOs and CTOs, right? So, we talk about trends, we talk about application, we talk about innovation. So, I get to see a lot of different dimensions of the technology side. 

Kovid Batra: Oh, that's great. Thanks for that quick intro. And of course, I feel that today I'm sitting in front of somebody who has immense experience, has seen that change when there was internet coming in to the point where AI is coming in. So, I'm sure there is a lot to learn today from you. 

Paul Lewis: That sounds like a very old statement. Yes, I have used mainframe. I have used AS400. 

Kovid Batra: I have no intentions. Great, man. Great. Thank you so much. So, let's get started. I think when we are talking about building teams from scratch. I think laying the foundation is the first thing that comes to mind, like having that culture, having that vision, right? That's how you define the foundation for any strong tech team that needs to come in. So, how do you establish that? How do you establish that collaborative, positive team culture in the beginning? And how do you ensure the team aligns with the overall vision of the business, the product. So, let's hear it from you. 

Paul Lewis: Sure. Well, realistically, I don't think you start with the team and team culture. I think you start with the team leadership. I know as recent in the last three years, when we built out the Pythian software engineering practice, well, I started by bringing in somebody who's worked for me and with me for 15 years, right, somebody who I trusted, who has an enterprise perspective of maturity, who I knew had a detailed implementation of building software, who has built, you know, hundreds of millions of dollars worth of software over a period of time, and I knew could determine what skill set was necessary. But in combination with that person, I also needed sort of the program management side because this practice didn't exist, there was no sense of communications or project agility or even project management capability. So, I had to bring in sort of a program management leadership and software delivery leadership, and then start the practice of building the team. And of course, it always starts with, well, what are we actually building? You can't just hire in technologists assuming that they'll be able to build everything. It's saying, what's our technology goal? What's our technology principles? What do we think the technology strategy should be to implement? You know, whatever software we think we want to build. And from that, we can say, well, we need at least, you know, these five different skill sets and let's bring in those five skill sets in order to coordinate sort of the creation of at the very least, you know, the estimates, the foundation of the software. 

Kovid Batra: Makes sense So, I think when you say bringing in that right leadership that's the first step. But then, with that leadership, your thought is to bring in a certain type of personality that would create the culture or you need people who align with your thoughts as a CTO, and then you bring those people in? I think I would want to understand that. 

Paul Lewis: I'm less sure you need to decide between the two. I know my choices usually are bringing in somebody to which already knows how to manage me. Right? As you can imagine, CTOs, CIOs have personalities and those personalities sometimes could be straining, sometimes can be motivational, sometimes could be inspirational, but I knew I need to bring somebody in that didn't have to, that already knew how to communicate with me effectively, that I already know knew my sort of expectations of delivery, expectations of quality, expectations of timeliness, expectations of adhering to technology principles and technology maturity. So, they passed that gate, right? So now, I had sort of right out of the gate trust between me and the leadership that was going to deliver on the software which is sort of the first requirement. From then, then I expect them to both evolve the maturity of the practice, in other words, the documentation and technology principles and build out the team itself from scratch. 

So, determine what five skills are necessary and then acquire those skills and bring them into the organization. It doesn't necessarily mean hiring. In fact, the vast majority of the software, which I've built over the time, we started with partnerships with ecosystems, right? So, ecosystems of QA partnerships and development partnerships. Bring those skill sets in and as we determine, we need sort of permanent Pythian resources like software architecture resources or DevOps architecture resources or, you know, skilled senior development that we start to hire them in our organization as being the primary decision-makers and primary implementers of technology. 

Kovid Batra: Makes sense. And, uh, Paul, does this change with the type of business the org is into or you look at it from a single lens, like if the tech team is there, it has to function like this, uh, does it change with the business or not? 

Paul Lewis: I think it changes based on the business objectives. So, some businesses are highly regulated and therefore, quality might be more important than others. The reality is, you know, the three triangles of time, cost, and quality. For the most part, quality is the most fungible, right? There are industries where I'm landing a plane where quality needs to be, you know, near zero bugs and then tech startups where there's an assumption that there'll be severe, if not damaging bugs in production, right, cause I'm trying to deploy a highly agile environment. So, yes, different organizations have different sort of, uh, appetites for time, cost, and quality. Quality being the biggest measure that you can sort of change the scale on. And the smaller the organization, the more agile it becomes, the more likelihood that you can do things quickly with, I'll call it less maturity, out of the gate, and assume that you can grow maturity over time. 

So, Pythian is an example. Out of the gate, we had a relatively zero sense of maturity, right? No documentation, no process, no real sort of project management implementation. It was really smart people doing really good work. Um, and then we said, "Wow, that's interesting. That's kind of a superhero implementation which just has no longevity to it because those superheroes could easily win the lottery and move on." Right? So, we had to think about, well, how do we move away from the superhero implementation to the repeatable scalable implementation, and that requires process, and I know development isn't a big fan of process holistically, but they are a fan of consistency, right? They are a fan of proper decision-making. They are a fan of documented decisions so that the next person who's auditing or reviewing or updating the code knows the purpose and value of that particular code, right? So, some things they enjoy, some things they don't, uh, but we can improve that maturity over time. So, I can say every year we want to go from 0 to 1, 1 to 2, 2 to 3, never to pass 3, right, because we're not, like Pythian, for example, isn't a bank, right, isn't an insurance company, isn't a telco, we're not landing planes, we're not solving, uh, we're not solving complex, uh, healthcare issues, so we don't have to be as mature as any one of those organizations, but we need to have documents at least, right, we need to ensure that we have automation, automated procedures to push to production instead of direct access, DBA access to the database in a production environment. So, that's kind of the evolution that we had. 

Kovid Batra: So, amazing to hear these kinds of thoughts and I'm just trying to capture how you are enabling your developers or how you are ensuring that your developers, your teams are aligned with a similar kind of thought. What's your style of communicating and imbibing that in the team? 

Paul Lewis: We like to do that with technology principles, written technology principles. So, think of it as a, you know, top 10 what the CTO thinks is the most important when we build software. Right? So what the top 10 things are, let's mutually agree that automation is key for everything we do, right? So, automation to move code, automation to implement code, uh, automation to test, automation in terms of reporting, but that's key. Top 10 is also we need to sort of implement security by design. We need to make sure that, um, it has a secure foundation because it's not just internal users, but we're deploying the software to 2,000 endpoints, and therefore, I need to appreciate endpoints to which I don't control, there I need, therefore I need a sort of a zero trust implementation. I need to make sure that I'm using current technology standards and architectural patterns, right? I want to make sure that I have implemented such a framework that I can easily hire other people who would be just as interested in seeing this technology and using technology, and we want to be in many ways, a beacon to new technologies. I want the software we build to be an inspirational part of why somebody would want to come to work at Pythian because they can see us using an innovating current practical architectural standards in the cloud, as an example.

So, you know, you go through those technology principles and you say, "This is what I think an ideal software engineering outcome, set of outcomes look like. Who wants to subscribe to that?" And then, you see the volunteers putting up their hands saying, "Yeah, I believe in these principles. These principles are what I would put in place, or I would expect if I was running a team, therefore I want to join." Does that make sense? 

Kovid Batra: Yeah, definitely. And I think these are the folks who then become the leaders for the next set of people who need to like follow them on it. 

Paul Lewis: Yeah, exactly. 

Kovid Batra: It totally makes sense. 

Paul Lewis: And if you have a set of rules, you know, I use the word 'rules', you know, loosely, I really just mean principles, right? To say, "Here are the set of things we believe and want to be true even if there's different maturities to them. Yes, we want a fully automated system, but year one, we don't. Year three, we might." Right? So, they know sometimes it's a goal, sometimes it's principle, sometimes it's a requirement. Right? We're not going to implement low-quality code, right? We're not going to implement unsecured code, but if you have a team to buy in those principles, then they know it's not just the outcome of the software they're building, but it's the outcome of the practice that they're building. 

Kovid Batra: Totally, totally. And when it comes to bringing that kind of people to the team, I think one is of course enabling the existing team members to abide by that and believe in those principles, but when you're hiring, there has to be a good talent acquisition strategy there, right? You can't just go on hiring, uh, if you are scaling, like you're on a hiring spree and you're just bringing in people. So how do you keep that quality check when people are coming in, joining in from the lowest level, like from the developer point, we should say, to the highest leadership level also, like what's your strategy there? How do you ensure this team-building? 

Paul Lewis: Well, on the recruiting side, we make sure we talk about our outcomes frequently, both internally in the organization and externally to, uh, you know, the world at large. So internally, I do like a CTO 'ask me anything', right? So, that's a full, everybody's, you know, full board, everybody can access it, everybody can, and it's almost like a townhall. That's where we do a couple of things. We disclose things I'm hearing externally that might be motivating, inspiring to you. It's, "Here's how we're maturing and the outcomes we've produced in software over this quarter.", let's say. And then, we'll do a technology debate to say, "You know what, there's a new principle I need to think about, and that new principle might be generative AI. Let's all jump in and have a, you know, a reasonably interesting technology debate on the best implications and applications of that technology. So, it's almost like they get to have a group think or group input into those technology principles before we write it down and put it into the document. And then if I present that, which I do frequently externally, then I gavel, you know, whole networks of people to say, "Wow, that is an interesting set of policies. That's an interesting set of, um, sort of guiding principles. I want to participate in that." And that actually creates recruiting opportunities. I get at least 50 percent of my LinkedIn, um, sort of contributions and engagements are from people saying, "I thought what you said was interesting. That sounds like a team I want to join. Do you have openings to make that happen?" Right? So, we actually don't have in many ways a lack of opportunity, recruiting opportunity. If anything, we might have too much opportunity. But that's how we create that engagement, that excitement, that motivation, that inspiration both internally and externally. 

Kovid Batra: And usually, like when everyone is getting hired in your team like, do you handpick, like at least one round is there which you take with the developers or are you relying mostly on your leadership next in line to take that up? How does that work for your team? 

Paul Lewis: I absolutely rely on my leadership team, mostly because they're pretty seasoned and they've worked with me for a while, right? So, they fully appreciate what kind of things that I would expect. There are some exceptions, right? So if there are some key technologists to which I think will drive inspirational, motivational behavior or where they are implementing sort of the core or complex patterns that I think are important for the software. So, things like, uh, software architecture, I would absolutely be involved in the software architecture conversations and recruiting and sort of interviewing and hiring process because it's not just about sort of their technology acumen, it's also about their communication capabilities, right? They're going to be part of the architectural review board, and therefore, I need to know whether they can motivate, inspire, and persuade other parts of the organization to make these decisions, right? That they can communicate both verbally and in the written form, that when they create an architectural diagram, it's easy to understand, sort of that side, and even sort of DevOps-type architects where, you know, automation is so key in most of the software we develop and that'll lead into, you know, not just infrastructure as code, but potentially even the AI deployment of infrastructure as code, which means not only do they need to have, you know, the technical chops now, I need them to be well read on what the technical jobs are needed for tomorrow. Right? That also becomes important. So, I'll get involved in those key resources that I know will have a pretty big impact on the future of the organization versus, you know, the developers, the QAs, the BAs, the product owners, the project managers, you know, I don't necessarily involved in every part of that interview process.

Kovid Batra: Totally, totally. I think one good point you just touched upon right now is about processes and the communication bit of it. Right? So, I think that's also very critical in a team, at least in large-scale teams, because as you grow, things are going hybrid, remote, and even then, the processes are, and the communication is becoming even more critical there, right? So, in your teams, how do you take up or how do you ensure that the right processes are there? I mean, you can give some examples, like how do you ensure that teams are not overloaded or in fact, the work is rightly distributed amongst the team and they're communicating well wherever there is a cross-functional requirement to be delivered and teams are communicating well, the requirements are coming in? So, something around process and communication which you are doing, I would love to hear that. 

Paul Lewis: Good questions. I think communication is on three fronts, but I'll talk about the internal communication first, the communication within the teams. We have a relatively unique set of sort of development processes that are federated. So, think of it as there is a software engineering team that is dedicated to do software engineering work, but for scale, we get to dip into the billable or the customer practices. So, if I need to deliver an epic or a series of stories that require more than one, uh, Go developer or data engineer or DevOps practitioner, then I have the ability to dip into those resources, into those practices, assign them temporarily to these epics and stories, uh, or just a ticket that they, that I want them to deliver on and then they can deliver on them as long as it's all, as long as everybody's already been trained on how to implement the appropriate architectural frameworks and that they're subscribing to the PR process that is equivalent, both internally and externally to the team. We do that with standard agile processes, right? We do standups on a daily basis. We break down all of our epics in the stories and we deliver stories in the tickets and tickets get assigned people, like this is a standard process with standard PM, with standard architectural frameworks, standard automation, deployments, and we have specific people assigned to do most of the PRs, right? So not only PR reviews, but doing sort of code, code creation and code deployment so that, you know, I rely on the experts to do the expert work, but we can reach out into those teams when we need to reach out to those teams and they can be temporary, right? I don't need to assign somebody for an entire eight-week journey. Um, I could just assign them to a particular story to implement that work, which is great. So, I can expand any one particular stream from five people to 15 people at any one period of time. That's kind of the internal communication.

So, they do standups. We do, you know fine-tuned documentation, uh, we have a pretty prescriptive understanding of what's in the backlog and how and what we have to deliver in the backlog. We actually detail a one-year plan with multiple releases. So, we actually have a pretty detailed, we'll call it 'product roadmap' or 'project roadmap' to deliver in the year, and therefore, it's pretty predictable. Every eight weeks we're delivering something new to production, right? But that's only one of those communication patterns. The other communication patterns all to the other internal technology teams, because we're talking about, you know, six, seven hundred internal technologists, and we want them to be aware of not just things that we've successfully implemented in the past and how it's working in production, but what the future looks like and how they might want to participate in the future functions and features that we deliver on. 

But even those two communication patterns arguably isn't the most important part. The most important part might actually be the communication up. Right? So now, I have to have communication on a quarterly basis with my peers, with the CEO and the CFO to say not only how well we're spending money, how well we're achieving our technological goals and our technological maturity, but even more importantly, are we getting the gain in the organization? So, are we matching the revenue growth of the organization? Are we creating the operational efficiency that we expect to create with the software, right? Cause I have to measure what I produce based on the value created, not just because I happen to like building software, and that's arguably the most difficult part, right, to say, "I built software for a purpose, an organizational purpose. Am I achieving the organizational goals?" Much more difficult calculus as compared to, "I said I was going to do five features. I delivered five features. Let's celebrate." 

Kovid Batra: But I think that's the tricky part, right? And as you said, it's the hardest part. How do you make sure, like, as in, see, the leaders probably are communicating with the business teams and they have that visibility into how it's going to impact the product or how it's going to impact the users, but when it comes to the developers particularly, uh, who are just coding on a day-to-day basis, how do you ensure that the teams are motivated that way and they are communicating on those lines of delivering the outcomes, which the leaders also see? So, that's.. 

Paul Lewis: Well, they get to participate in the backlog prioritization, right? So, in fact, I like to have most of the development team consider themselves in many ways, owners of the software. They might not have the Product Owner title, or they might not be the Product Manager of the product, but I want them to feel like it's theirs. And therefore, I need them to participate in architectural decisions. I want them to buy-in to what the priority of the next set of features are going to be. I want to be able to celebrate with them when they do something successful, right? I want them to be on the forefront of presenting the value back to the rest of the team, which is why that second communication to the rest of the, you know, six or seven hundred technologists that they're the ones presenting what they created versus I'm the one presenting their credit. I want them to be proud of the code that they've built, proud of the feature that they've implemented and talk about it as if it's something that they, you know, had to spend a good portion of their waking hours on, right? That there was a technology innovation or R&D exercises that they had to overcome. That's kind of the best part. So, they're motivated to participate in the, um, in the prioritization, they're motivated to implement good code, and then they're motivated to present that as if it was an offering they were presenting to a board of decision-makers, right? It's almost as if they're going and getting new money to do new work, right? So, it's a dragon's den kind of world, which I think they enjoy. 

Kovid Batra: No, I think that's a great thought and I think this makes them feel accountable. This makes them feel motivated to whatever they are doing, and at the end of the day, if the developers start thinking on those lines, I think you have cracked it, probably. That's the criteria for a successful engineering, for sure. 

Apart from that, any other challenges while you were scaling, any particular example from your journey at Pythian that you felt is worth sharing with our audience here?

Paul Lewis: The challenge is always the 'what next?'. Right? So let's say, it takes 24 months to build a substantial piece of software. Part of my job, my leadership's job is to prepare for the next two years, right? So, we're in deep dive, we're in year one, we're delivering, we're halfway delivering some interesting piece of software, but I need to prep year three and year four, right? I need to have the negotiations with my peers and my leaders to say, "Once we complete this journey, what's the next big thing on the list? How are we going to articulate the value to the organization, either in growth or efficiency? How are we going to determine how we spend? Is this a $1m piece of software, or is this a $10m piece of software?" And then, you know, preparing the team for the shift between development to steady state, right? From building something to running something. And that's a pretty big mindset, as you know, right? It's no longer focused on automation of releases between dev, QA & production. It's saying, "It's in production now. It's now locked down. I need you to refocus on development on something else and let some other team run this system." So, both sides of that equation, how do I move from build to run in that team? And then, how do I prepare for the next thing that they build? 

Kovid Batra: And how do you think your tech teams contribute here? Because what needs to be built next is something that always flows in, in terms of features or stories from the product teams, right? Or other business teams, right? Here, how do you operate? Like, in your org, let's say, there is a new technology which can completely revamp the way you have been delivering value so that tech team members are open to speak and like let the business people know that this is what we could do, or it's more like only the technical goals are being set by the tech team and rest of the product goals are given by the product team. How does it work for the, for your team here? 

Paul Lewis: It's pretty mutual in fairness, right? So, when we determine sort of the feature backlog of a piece of software, there's contribution for product management, think of that as the business, right? And the technology architecture team, right? So, we mutually determine what our next bet in terms of features that will both improve the application, functionally improve the application technically. So, that's good. 

When it comes to the bigger piece of software, so we want to put this software in steady state, do minor feature adjustments instead of major feature adjustments, that's when it requires much more of a, sort of a business headspace, right? Cause it's less about technology innovation at that point. However, sometimes it is, right? Sometimes I'll get, "Hey, what are we doing for generative AI? What new software can we build to be an exemplar of generative AI?" And I can bring that to the table. So, I have my team bringing to the decision-making table of, "Here's some technology innovation that's happening in the world that I think we should apply." And then, from the business saying, "Here's a set of business problems or revenue opportunities that we can match." So now, it's a matching process. How can I match generative AI, interesting technology with, you know, acquiring a new customer segment we currently don't acquire now, right? And so, how do I sort of bring both of those worlds together and say, "Given this match program, I'm going to circle what I think is possible within the budget that we have."? 

Kovid Batra: Right. Right. And my question is exactly this, like, what exactly makes sure that the innovation on technology and the requirements from the customer end are there on the same table, same decision-making table? So, if I'm a developer in your team, even if I'm well aware of the customer needs and requirements and I've seen certain new technologies coming up, trending up, how do I make sure that my thought is put on the right table in front of the right team and members? 

Paul Lewis: Well, fortunately, like most organizations, but definitely Pythian, we've created like an architectural review board, right? So, that includes development, architecture, product management, but it's not the executive team, right? It's the real architectural practitioners and they get to have the debate, discussion on what they think is the most technologically challenging that we want to solve or innovation that we think matters or evolution of technology that we think we want to implement within our technologies, moving from, you know, an IaaS to a PaaS to a Saas, as an example, those are all decisions that in many ways we let the technology practitioners make, and then they bring that set of decisions to the business to say, "Well, let's match this set of architectural principles with a bunch of business problems." Right? So, it's not top-down. It's not me saying, "Thou shalt build software. Thou shalt use Gen AI. Make it so." It rarely is that. It's the technology principle saying, "We think this innovation is occurring. It's a trend. It's important. We think we should apply it knowing its implications. Let's match that to one of a hundred business problems to which we know the business has, right? The reality is the business has an endless amount of technology problems, of business problems. Technology has an endless amount of innovation, right? 

Kovid Batra: Yeah, yeah. 

Paul Lewis: There's no shortlist in either of those equations. 

Kovid Batra: Correct. Absolutely. Perfect, perfect. I think this was great. I think I can go on talking with you. Uh, this is so interesting, but we'll take a hard stop here for today's episode and thank you so much for taking out time and sharing these thoughts with us, Paul. I would love to have you on another show with us, talking about many more problems of engineering teams. 

Paul Lewis: Sure. 

Kovid Batra: But thanks for today and it was great meeting you. Before you leave, um, is there a parting advice for our audience who are mostly like aspiring engineering managers, engineering leaders of the modern tech world? 

Paul Lewis: Um, the gap with most technologists, because they tend to be, you know, put their glasses on, close the lights in the room, focus on the code, that's amazing. But the best part of the thing you develop is the communication part. So, don't be just a 'code creator', be a 'code communicator'. That's the most important part of your career as a developer, is to present that wares that you just built outside of your own headspace. That's what makes the difference between a junior, an intermediate, senior developer and architect. So, think about that. 

Kovid Batra: Great, great piece of advice, Paul. Thank you so much. With that, we'll say, have a great evening. Have a great day and see you soon! 

Paul Lewis: Thank you.

‘Enhancing DevEx, Code Review and Leading Gen Z’ with Jacob Singh, CTO in Residence, Alpha Wave Global

In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Jacob Singh, Chief Technology Officer in Residence at Alpha Wave Global. He brings extensive experience from his roles at Blinkit, Acquia, and Sequoia Capital. The heart of their conversation revolves around ‘Enhancing DevEx, Code Review and Leading Gen Z’. https://youtu.be/TFTrSjXI3Tg?si=H_KxnZGlFOsBtw7Y The discussion begins with Jacob's reflection on India and his career break. Moving on to the main section, he explores the evolving definition and widespread adoption of developer experience. He also draws comparisons between tech culture in Indian versus Western companies and addresses strategies for cultivating effective DevEx for Gen Z & younger generations. Furthermore, he shares practical advice for tech leaders to navigate the ‘culture-market fit’ challenge and team structuring ideas from his hands-on experience at Grofers (now ‘Blinkit’). Lastly, Jacob offers parting advice to developers and leaders to embrace AI tools like Copilot and Cursor for maximizing efficiency and productivity, advocating for investing in quality tooling without hesitation.


  • 00:06 - Jacob’s introduction
  • 00:39 - Getting candid
  • 04:22 - Defining ‘Developer Experience’
  • 05:11 - Why is DevEx trending?
  • 07:02 - Comparing tech culture in India & the West
  • 09:39 - How to create good DevEx for Gen Z & beyond?
  • 13:37 - Advice for leaders in misaligned organizations
  • 17:03 - How Grofers improved their DevEx
  • 22:04 - Measuring DevEx in multiple teams
  • 25:49 - Enhancing code review experience
  • 31:51 - Parting advice for developers & leaders

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He's currently a CTO in Residence with Alpha Wave Group, which is a VC group. He comes with 20-plus years of engineering and leadership experience. He has worked with multiple startups and orgs like Blinkit as a CTO. He's the guest whom I have met and he's the only guest whom I have met in person, and I really liked talking to him at the SaaSBoomi event. Welcome to the show, Jacob. Great to have you here.Jacob Singh: Thanks. Good to be here, to chat with you.Kovid Batra: Cool. I think, let's start with something very unique that I've seen experienced with you, that is your name. It's Jacob Singh, right? So, how did that fusion happen?Jacob Singh: Just seemed like fun, you know? Just can't, since I was living in India anyway, I figured Smith is harder to pronounce, so.. I'm just kidding. My dad's from here. My dad's Punjabi. So, you know, when a brown boy and a white girl, they love each other a lot, then, you know, you end up with a Jacob Singh. That's about it. There's not much else to it. I grew up in the States, but I've lived in India on and off for the past 20 years.Kovid Batra: Great, great. Perfect. That's rare to see, at least in India. Most of the generation, maybe half-Indian, half-American are in the U.S. But what did you love about India? What made you come here?Jacob Singh: Good question. I was trying to escape my tech stuff. So, I sort of started very early. I taught myself to code as a teenager and started my first business when I was 18 and I'd done pretty well. And then, when I was like 21-22, I just sort of decided I wanted to do something different, do something in the social sector, helping people. So, I took a job with an NGO in West Delhi and sort of shifted for that. That was the original purpose. Why did I stay? I guess there's something dynamic and interesting about the place. India's changed a lot in 20 years, as everybody knows. And, I think that's been continuously exciting to be a part of. It doesn't feel stagnant. It doesn't feel like, I mean, a lot of changes are not in the direction I would love, to be honest, but, you know, but it's an interesting place. There's always something happening. And I found that, and then eventually you build your community, your friends and your family and all that kind of stuff. So, this is home. Yeah, that's about it.Kovid Batra: Perfect. Perfect. Talking about the family, I was just talking to you on LinkedIn. I found that there was like a one-year break that you took in your career and you were just parenting at that time. And honestly, that's very different and very unique to a culture, to an Indian culture, actually. So, I just wanted to know how was your experience there. I'm sure it would have made you learn a lot of things, as it does for a lot of other parents. But I just wanted to hear about your experience with your kid.Jacob Singh: Hopefully, it's not so uncommon. I think it's starting to change especially the role of men as fathers in India. I think it's traditionally, like my dad's father, he just saw him for tea, you know, and he was reading the newspaper and he'd meet him once a year on his birthday and take him to a quality restaurant for a coke, you know, that was their relationship. I think things are different with Indian fathers these days. I think for me, you know, we were just, perfectly honest, was going through a divorce. Difficult. I needed to be there for my daughter and I was, you know, sort of taking half the responsibility in terms of time with her. This was eight years ago. And I think my parents had also divorced. So, I was kind of, my dad was a very active part of my upbringing and did all the things, did all the dishes, cooked all the meals, you know, was around. He was also working as a programmer and did all that, but he was at home as well. And he found ways to make it work, even if it had meant sacrificing his career to some extent. He was working from home when I was a kid in the 80s. So, he had a giant IBM 880, or whatever computer, a little tiny green screen, a 300-bot modem, you know, to connect and send his work up. So, that's how I grew up. Turned out to benefit me a lot, uh, when it came to learning computers, but, um, you know, he would convince him to do that cause he was good at his job, and he's like, I have to be there for my kids. And he made it work, you know? I think we all find those times where we need to lean into family or lean into work in different proportions, you know?Kovid Batra: Hmm. Great. I think amazing job there honestly, Jacob All right, that was great knowing you and thanks for that quick intro. Moving on to the main section of our today's podcast, enhancing the developer experience. So, that's our topic for today. So let's start very basic, very simple. What is developer experience according to you?Jacob Singh: What is developer experience? It's an interesting term. I guess it's, you know, the day-to-day of how a programmer gets their job done. I guess the term would be everything encapsulated from, how their boss talks to them, how they work with their teammates, the kind of tools they use for project management down to the quality of documentation, APIs, the kind of tools they use on their computer, the tools they use in the cloud that they work with, et cetera. And all of that encapsulated is how effective can they be at their job, you know, and the environment around them that allows them to be effective. I guess what I would define it as.Kovid Batra: And why do you think it's trending so much these days? I think what you mentioned and what I have also read everywhere about developer experience is the same fundamental that has been existing all the years, right? But why is it trending these days? Why do you think this is something up in the market?Jacob Singh: Good question. I guess, I mean, I've been around for a while, so I think in the earlier days of the industry, when I first started engineers were a little expensive, but they were also looked at as like a commodity that you could just use. Like, you put them on a spreadsheet, you pay the engineers, you get the work done. They weren't considered really central. They were considered sort of like factory workers in an expensive factory, to some extent. I think it was more so in the 80s and 90s, right? But like, it's still trending more and more in the direction of engineers kind of being very expensive and being decision-makers, moving into C-level positions, having more authority, seeing that, like, if you just look at, you know, the S&P 500, you look at the, you look at the stock market and you see that the top companies are all tech companies and they command most of the market cap. I think those days are over. So now, it's very much that if you're able to execute with your engineering roadmap, you're able to win the market. It's considered the basis of a lot of companies, sort of strategies, whether they're a tech company or not, and therefore the effectiveness of the developers and the team plays into which developers will join you. And when they join you, how likely are they to be engaged and to be retained? And then, how effective, you know, is each developer because they're a rare commodity because it's hard to find good developers. There's so much demand, et cetera, even in recessionary times, most of the layoffs are not engineering teams. And so, the effectiveness of each engineer and their ability to motivate and retain them becomes paramount to a company strategy.Kovid Batra: Right. Makes sense. So, according to you, I'm sure you have had the experience of seeing this shift in the West as well as in companies in India, right? When you see the culture, particularly talking about the tech culture in a company, like maybe, for example, you work with a company like Blinkit, which is huge today in India and you must have worked with other companies in the West. How would you compare, like, how are teams being led in these two different cultures? Jacob Singh: Well, I would say those kind of, you know, anything I say is going to be a gross generalization, and it's going to be incorrect more often than it's correct. I think there's more difference between two Indian companies than there is between any given American or any Indian company, you know. There's a lot of variation. But if I'm being put on the spot to make such generalizations, I would say that one big difference is the age and maturity of engineers. So, like, when I was 29, I got hired as an IC, a Principal Engineer at this company called Acquia. They kind of acquired my startup and I joined there, and, you know, we had PhDs on the team who were ICs, right? Our VP Engineering, you know, had 25 years of experience in the field and was, you know, sort of. You know, one of my colleagues was like heading R&D for the RFID team at Sun. You know, like the very senior guys were still writing code.Kovid Batra: Yeah.Jacob Singh: It's like, very much just like in the weeds writing code. They're not trying to be managers and an architect. They're just like a programmer, right? I got my first team, like to manage, like I got a small team like at 25-26, but really I got my first team of like really qualified, expensive engineers when I was like 32. Whereas here, I'm a VP Engineering at Grofers at like 29. It's like managing a 100 people. It's very common to be much early in your career. Engineers with 3-4 years of experience are sort of talking about, "I should be an SDE-IV". So, the whole like, that scale is different. You have a much younger audience. In the States, at least when I was coming up, there's a lot more earning your stripes over a long time before you go into management. Whereas here, we have a lot more very junior managers. I think that's a big difference.Kovid Batra: Okay. And that's interesting, actually.Jacob Singh: That creates a lot of other dynamics, right? I mean, you just have like, generally you know, you have more, I would, and I hate to say this, probably going to take shit for this, but having been an engineering leader in both places, I feel like you have more like discipline and like professionalism issues here, generally, which is not to do with Indians. It's just to do with the age of people. Like, they're 24 years old, they're not gonna be very professional, right? Like a lot of your team.Kovid Batra: No, totally. I think, we are not generalizing this, but as you said, it's probably about the age. In one of my podcasts, I was just talking to this fellow from Spain. He's leading a team of almost 30 folks now.Jacob Singh: Yeah.Kovid Batra: And 50% of them were early hires, like early 20 hires, right?Jacob Singh: Yeah.Kovid Batra: And he's that guy. And then I was talking to somebody in India who was leading a 50-member team there. Again, 50% of the folks were like junior engineers in their 25-26. And both of them had the same issue of handling Gen Zs. So, I think from where you are coming, it's totally relatable and I think we touched on a very good topic here. How to create a good developer experience for these early-age, 25-26-year-olds in the system? Because they're not stable, they are not, So again, I am also not generalizing. A lot of good folks are there, but they're not like in the right mindset of sticking to a place, learning gradually and then making that impact. They just like really want to hop on fast on everything.Jacob Singh: Yeah.Kovid Batra: So, how do you handle that? Because that definitely is a pain for a lot of us, not just in India, but across the globe.Jacob Singh: No, no, I've heard this a lot, you know, and I'm not really sure. I mean, I'm far from Gen Z. I was actually having this exact same conversation with the CTO of an Indian unicorn, a pretty large one, who was talking about the same thing. He's like, "How do I motivate these?" This seems like the younger guys, they don't really want to work and they're constantly, you know, making noise and they think it's their right to work from home. They think it's their right to work 20-30 hours a week. They don't want, they don't want to advance and follow all this sort of stuff. I guess my advice to him was maybe a bit generic and maybe incorrect. You know, I think there are differences in generations, but I think some truths are fairly universal and I've uncovered a couple of things which have worked for me. And every manager has their own style and because of that, and every company has its own culture and its own goals. And so, there's a thing that's 'culture-market fit'. So, certain leaders will do well in certain kinds of companies, right, who have certain kinds of cultures made for the market they're in. This is not generic advice for everybody. But for me, I like to work in startups and I like to work in you know, startups, which are working on, I would say, kind of top-line problems which means not efficiency-related problems so much as innovation-related problems. How do we discover the next big thing? What feature is going to work with customers? Et cetera. And in such places, you need people who are motivated by intrinsic, they need intrinsic creative motivation. Carrot and Stick stuff doesn't work. Carrot and Stick will work for a customer service team, for a sales team, it'll work for an IT team at a Fortune 500 who's shipping the same things over and over again, but for creative teams, they really need to care about it intrinsically. They need to be interested in the puzzle. They want to solve the puzzle. You can't sort of motivate them in other ways. And I think this applies to the younger generation as much as the older ones. You know, the best thing to do is to, basically, it's a very simple formula, it sounds cliché but figure out where the hell you're going, why you should go there and everyone in the team should know where you're going and they should know why they're important to that strategy, what they're doing that's important, you know, and they should believe it themselves that it can work. And then, they should believe that if it works, you're gonna take care of them. And if you solve those things, they will work hard and they will try to solve problems. A lot of companies think they can shortchange that by having a crappy strategy, by having, you know, a lot of program management, which removes people from the real problem they're solving by treating people as numbers on a spreadsheet, naturally, you're going to get, you know, poor results when you do that.Kovid Batra: Totally. I think very well answered, Jacob. I think finding that culture-market fit and finding the place where you will also fit in naturally, you would be easily able to align with the folks who are working there and maybe lead them better. I think that that analogy is really, really good here. Apart from that, do you think like not everyone gets that opportunity to find the right place for themselves, right, when there is a dearth of opportunities in the market? What would be the advice for the leaders that they should apply to them when they are not in the culture-market fit scenario?Jacob Singh: Leaders? You mean, if a leader is in an organization where they don't feel like the values of the tech team aligned to their value, whether it be engineer or CTO or something?Kovid Batra: Correct, yes.Jacob Singh: Good question. The best thing to do is probably to quit. But if you can't afford, I mean, I say that a bit flippantly. I'm not saying "quit early". I'm not saying "don't try". I mean, if you really have a true values alignment problem you know, then that's hard to get over. If it's tactical, if it's relationship-based, you can work on those things, right? If you feel like you have to be someone you don't like to fit in an organization, then that's unlikely to change if it comes from the top, right? There's a very cliché saying, but you know, "Be careful who you work with. You're more likely to become them than they are to become you." And so, I would say that. But to get more practical, let's say if you can't, or you're feeling challenged, et cetera. Your question was basically, okay, so let's say you're a VP Engineering or Director of Engineering and you're unhappy with the leadership in some way, right?Kovid Batra: Yeah. So, no, I think it makes sense. The advice is generic, but it definitely gives you the direction of where you should be thinking when you are stuck in such a situation. You can't really fight against it.Jacob Singh: Yeah. I will say a couple of things. This is also the same conversation I had mentioned earlier. This also came up with the typical thing of leadership not trusting tech. You know, they don't think we're doing anything. They think we're moving too slow. They think we're, you know, sandbagging everything, etc. And to solve that, I think, which is not a values problem. That's the case in almost every organization. I mean, there's never been a CEO who said, "Oh, man! The tech team is so fast. They just keep.. I can't come up with dumb ideas fast enough. They keep implementing everything." So, you know, it's never happened in the history of companies. So, there's always that conflict which is natural and healthy. But I think to get over that, that's basically a transparency problem, usually. It's like, are you clear on your sprint reviews? Do you do them in public? Do you share a lot of information around the progress made? Do you share it in a way that gets consumed or not? Are you A/B testing stuff? Are you able to look at numbers? Able to talk numbers with your business teams? Do you know the impact of features you're releasing? Can you measure it? Right? If you can measure it, release that information. If you can give timely updates in a way which is entertaining and appropriate for the audience that they actually listen those problems tend to go away. Then it's just, the main problem there is not that people don't trust you. It's just that you're a black box to them. They don't understand your language. And so, you have to find, you know, techniques to go over that. Yeah.Kovid Batra: Yeah. Makes sense. Great, great. All right, coming back to enhancing the developer experience there. So, there are multiple areas where you can see developer experience taking a hit or working well, right? So, which are those areas which you feel are getting impacted with this enhancement of developer experience and how you have worked upon those in any one of your experiences in the past with any of the companies?Jacob Singh: You said "enhancement of developer experience". What do you mean by that?Kovid Batra: So, yeah. I'll repeat my question. Maybe I confused you with too many words there. So, in your previous experiences, you must have worked with many teams and there would have been various areas that could have impacted the developer experience. So, just to give you a very simple example, as you talked about the tooling, the people whom they're working with. So, there could be multiple issues that impact the developer experience, right? So, in your previous experiences where you found out a specific developer experience related problem and how you solved it, how it was impacting the overall delivery of the development team. Just want to like deep dive into that experience of yours.Jacob Singh: Yeah. So I think a big one was I can talk about Grofers. So, one of the things we had when I first came to Grofers, we had about 50-60 people in tech, product engineering, data, design, etc. We had them into different pods. That was good. Someone had created like different teams for different parts of the application. So, it wasn't just a free-flowing pool of labor. There was the, you know, the shopping cart team and the browsing team and the supply chain, like the warehouse management team, the last mile team, it was like, you know, four or five teams. But there was a shared mobile team. So at the front end, there was, there was one Android team, there was one iOS team, there was one web team, which again, is very common, not necessarily a bad idea. But what ended up happening was that the business teams would, they wouldn't trust the tech deadlines because a lot of times what happened is there'd be a bunch of backend engineers in the shopping cart team, they'd finish something, and then they'd be stuck on the front end team because the front end team was working on something for the, or the Android team was working on something for the browsing team, right? The iOS team was free, so they would build that shopping cart feature. But they couldn't really release it yet because the releases had to go out together with Android and iOS, because, you know, the backend release had to go with that. So, we're waiting on this one. Then we're waiting on the web one. There's this cascading waiting that's happening. And now, the shopping cart team is like, "We're done with our part. We're waiting on Android. So we're going to start a new feature." They start a new feature. And then again, the problem starts again where that feature is then waiting on somebody else, waiting on the QA team or waiting on somebody else. So, all of these waiting aspects that happen ruin the developer experience because the developer can't finish something. They get something half done, but it's not out in production, so they can't forget about it. Production is a moving target. The more teams you have, the more frequently it's changing. So, you have to go back and revisit that code. It's stale now. You've forgotten it, right? And you haven't actually released anything to customers. So, the business teams are like, "What the hell? You said you're done. You said you'd be done two weeks ago." And you're like, "Oh, I'm waiting for this team." "Stop giving me excuses." Right?Kovid Batra: Right.Jacob Singh: That team's waiting on the other team. So, I think one of the big things we did was we said, we took a hard call and said, at the time, Grofers was not quick commerce. At that time, Grofers was like DMart online, cheap discounting, 2-3 day delivery, and we scaled up massively on that proposition. And, uh, we said, hey, people who care about the price of bread being 5% less or more, do they own iPhones? No, they do not own iPhones. That's like 5% of our population. So we just ditched the iPhone team, cross-trained people on Android. We took all the Android engineers and we put them into the individual teams. We also took QA, automated most of our tests, and put QA resources into each of the teams, SDATs, and kind of removed those horizontal shared services teams and put them in fully cross-functional teams. And that improved developer experience a lot. And it's kind of obvious, like people talk about cross-functional teams and being able to get everything done within a team, being more efficient, less waiting for the teams, but it has another huge benefit. And the other huge benefit is motivation-wise. You cannot expect, like I said earlier, you want your engineers to care about the business outcomes. You want them to understand the strategy. They don't understand why they're building it. But if an engineer has to build something, send it to another team, get that team to send it to some other team, get that team to send it to some other team, to a release team to get released eventually, right? And then, the results come back three months later. You can't expect that engineer to be excited about their metrics, their business metrics and the outcomes.Kovid Batra: Right.Jacob Singh: If you put everyone in one team, they operate like a small startup and they just continually crank that wheel and put out new things, continually get feedback and learn, and they improve their part of the business and it's much more motivating and they're much more creative as a result. And I think that changes the whole experience for a developer. Just reduces those loops, those learning loops. You get a sense of progress and a sense of productivity. And that's really the most motivating thing.Kovid Batra: Totally makes sense. And it's a very good example. I think this is how you should reshape teams from time to time based on the business requirements and the business scale is what's going to impact the developer experience here. But what I'm thinking here is that this would have become a very evident problem while executing, right? Your project is not getting shipped and the business teams are probably out there standing, waiting for the release to happen. And you started feeling that pain and why it is happening and you went on solving it. But there could be multiple other issues when you scale up and 50-60 is a very good number actually. But when you go beyond that, there are small teams releasing something or the other on an everyday basis. How exactly would you go about measuring the developer experience on different areas? So, of course, this was one. Like, your sprints were delayed or your deliverables were delayed. This was evident. But how do you go about finding, in general, what's going on and how developers are feeling?Jacob Singh: Well, we hit those scaling things and like you said, yes, people are delayed. It sounds obvious, but it's mostly not. Most leaders actually take exactly the opposite approach. They say, "Okay. No more excuses. We're going to plan everything out at the beginning of the quarter. We're going to.. You plan your project. We'll do all the downstream mapping with every other Android, iOS, QA team required. We'll allocate all their bandwidth ahead of time. So, we'll never have this problem again. And we'll put program managers in place to make sure the whole thing happens." They go the opposite direction, which I think is kind of, well, it never works, to be honest. Kovid Batra: Yeah, of course.Jacob Singh: In terms of measuring developer experience as you scale. So, we got up to like 220 people in tech I think at some point in Grofers and we scaled up very quickly. That was within a year and a half or something, that happened. And, you know, that became much more challenging. I honestly don't love the word 'developer experience' cause it doesn't mean anything specifically cause there's sort of your experience as an employee, right, HR kind of related stuff, your manager or whatever, there's your experience, you know, as an engineer, like the tools you're using and stuff like that, right? And then your experience, like, as a team member, like your colleagues, your manager, your kind of stuff like that, right? So it's slightly different from an employee in terms of, it's not about company confidence and stuff or strategy, but more about your relationships. So, there's different areas of it. For measuring, like, general satisfaction, we use things like Officevibe, we use things like continuous performance improvement tools, like 15Five. we brought in OKRs, a lot of things which kind of are there to connect people to strategy and regularly check in and make sure that we're not missing things. All of those were effective in pockets, depending on usage. But by far the most effective thing, and I know this might not be the popular answer when it comes to what type of sells, although I do like the product a lot, which is why I'm doing this. I think it's a cool product. A lot of it is really just like 1-on-1s, just making sure that every manager does a 1-on-1 every two weeks. And making it like, put it in some kind of spreadsheet, some kind of lightweight thing, but making sure that new managers learn they have to do it, how to do them well, how to, you know, connect with individuals, understand their motivations and like follow through on stuff and make small improvements in their lives. Like, that's the cheat code. It's just doing the hard work of being a manager, following through with people, listening to them. That being said, data helps. So, like, what you guys have what you guys built, I've built small versions of that. I wrote a script which would look at all the repositories, see how long things are sitting in PR, look at Jira, see how long things are sitting in wait. You know, build continuous flow sort of diagrams, you know, sort of just showing people where your value, team is getting stuck. I've, like hand-coded some of that stuff and it's been helpful to start conversations. It's been helpful to convince people they need to change their ideas about what's happening. I think those are some of the ideas.Kovid Batra: Thanks for promoting Typo there. But yeah, I think that also makes sense. It's not necessary that you have to have a tooling in place, but in general, keeping a tab on these metrics or the understanding of how things are flowing in the team is critical and probably that's from where you understand where the developer experience and the experience of the team members would be impacted. One thing you mentioned was that you scaled very rapidly at Grofers and it was from 50 to 250, right? One interesting piece, I think we were having this discussion at the time of SaaSBoomi also the code review experience, right? Because at that scale, it becomes really difficult to, like even for a Director of Engineering to go into the code and see how it is flowing, where things are getting stuck. So, this code review experience in itself, I'm sure this impacts a lot of the developer experience piece, so to say. So, how did you manage that and how it flowed there for you?Jacob Singh: Well, one is I didn't manage it directly. So, like Grofers is big enough that I had a Director of Engineering sort of, or VP Engineering for different-different divisions. And that level of being hands-on in terms of code reviews, I wouldn't really participate in other than like, you know, sometimes as an observer, sometimes to show proof, if we're doing something new, like we're doing automation, I might whip up some sample code, show people, do a review here and there for a specific purpose about something, but never like generally manage those, like, look at that. Grofers was really good this way. I think we had a really good academic culture where people did like public code reviews. There wasn't this like protection shame kind of thing. It was very open. We had a big open-source culture. We used to host lots of open-source meetups. There was a lot of positive sort of view of inquiry and learning. It wasn't looked at as a threatening thing, which in a lot of organizations is looked at as a threatening kind of thing. And the gatekeeping thing, which I think we try to discourage. I think we had a lot of really positive aspects of that. Vedic Kapoor was heading DevOps and Security infrastructure stuff that I work with a lot. He's consulting now, doing this kind of work. He did a lot of great, sort of workshops and a lot of like a continuous improvement program with his teams around this kind of stuff where they do public reviews every so often every week or whatever. The DevOps teams made a big point of being that service team for the engineer so they would kind of build features for engineers. So, we had a developer experience team, essentially, because we were that size. Well, the review process, generally, I mean, I gave this rant at SaaSBoomi, and I think I've given it often. I think PRs are one of the worst things that's happened to software engineering, in the last 20 years.Kovid Batra: Yeah, you mentioned that.Jacob Singh: Yeah, and I think it's a real problem. And it's this funny thing where everyone assumes that progress moves forward and it never goes backwards. And then they, the younger generation doesn't necessarily believe that it could have been better before. But I'll tell you the reason why I say that is that, you know, Git was created by Linus, by the creator of Linux because they needed, well, they needed something immediately, but also they needed something which would allow thousands and thousands of people working at different companies with different motivations to all collaborate on the same project. And so, it's the branching and the sub branching and the sub-sub branching which Git allowed people to simultaneously work on many different branches and then sort of merge them late and review them in any order they wanted to and discuss them at length to get them in and had to be very secure and very stable at the end of the day. And that made a lot of sense, right? It's very asynchronous and things take a very long time to finish. That's not how your software team works. You guys are all sitting on the same table. What are you doing? Like, you don't need to do that. You can just be like, "Hey, look at this, right? There's a different way to do it." Even if you're on a remote team, you can be like, "Let's do a screen share." Or, "Can I meet you tomorrow at two or whatever, and we'll go through this." Or like, "I had some ideas, paste it in Slack, get back to me when you can." You know, "Here's my patch." Whatever. And I think what ends up happening is that this whole, the GitHub, and for open-source projects, it's huge. Git is amazing. Pull requests are amazing. They've enabled a lot. But if you are a team where you all kind of work on the same codebase, you all kind of work closely together, there's no reason to send up this long asynchronous process where it can take anywhere between a couple of hours to, I've seen a couple weeks to get a review done. And it creates a log jam and that slows down teams and that reduces again, that loop. I'm big on loops. Like, I think you should be able to run your code in less than a second. You should be able to compile as quickly as possible. You should be able to test things as quickly as possible that you should be able to get things to the market and review them as quickly as possible. You should get feedback from your colleague as soon as possible. And like, I think a lot of that has gotten worse. So, engineers like learn slower and they're waiting more, they're waiting for PRs to get reviewed, there's politics around it. And so, I think that that process, probably should change. More frequent reviews, pairing you know, sort of less formal reviews, et cetera. Yeah, and TDD if you can do it. It's kind of the way to get much faster loops, productivity loops going, get things out sooner. Sorry, a bit of a long rant, but yeah, PRs suck.Kovid Batra: No, I think this is really interesting, how we moved from enhancing developer experience and how code review should be done better because that ultimately impacts the overall experience and that's what most of the developers are doing most of the time. So, I think that makes sense. And it was.. Yeah?Jacob Singh: I just want to caveat that before you misquote me. I'm not saying formal reviews are bad. You should also have a formal review, but it should be like, it should be a formality. Like, you should have already done so many reviews informally along the way that anyone is reviewing it already kind of knows it's there and then the formal review happens. And it's like in the books and we've looked at it and we put the comments. It shouldn't just be like, "Here's a 20K patch.", a day before the deadline. You know what I mean? That shouldn't happen anymore, I think that's what I'm trying to say.Kovid Batra: Yeah. No, no, totally makes sense. I think this last piece was very interesting. And, we can have a complete discussion, a podcast totally on this piece itself. So, I'll stop here. And thank you so much for your time today, for discussing all these aspects of developer experience and how code reviews should be done better. Any parting advice, Jacob, for the dev teams of the modern age?Jacob Singh: The dev teams or the other managers? I guess the managers are probably watching this more than developers.Kovid Batra: Whichever you like.Jacob Singh: A parting advice. I would say that we're at the most exciting time to be an engineer since I mean, maybe I'm biased, but since I started coding. When I started coding, it was like, just as the web was taking off. You know, like, I remember when, like, CSS was released, you know, that's old. So I was like, "Oh, shit, this is great. This is so much fun!" You know, like, when it started getting adopted, right? So I think, like the sort of dynamic programmable web was nice when I started, right? Now, we're at the second most exciting one, in my opinion, as an engineer. And I think it's surprising to me. I work with a lot of portfolio companies at Alpha Wave. I talk to new companies that I'm looking at investing in. It's really surprising to me how few of them use Copilot or Cursor or these various sorts of AI tools to assist in development or like everyone uses them a little bit, but not programmatically. They don't really look into it too much. And I think that's a missed opportunity. I still code. When I code, I use them extensively. Like, extensively. I'm on ChatGPT. I'm on Copilot. I pay for all these subscriptions. You know, I use ShellGPT. I don't remember shell commands anymore. ShellGPT, by the way, is great to plug. Write what you want to do, hit ctrl+L, and it'll like generate the shell command for you. Even stuff I know how to do, it's faster. But the main thing is, like, the yak shaving goes away. So, I don't know if you guys know yak shaving, but yak shaving is this idea of having to do all this configuration, all this setup, all this screw around to get the thing actually working before you can start coding. Like, learning some new framework or dependency management, bullshit like that. That stuff is so much better now. You take your errors. You paste them into ChatGPT. It explains it. It's right most of the time. You can ask it to build a config script. So, I think if you know how to use the tool, you can just be a million times more productive. So, I would say lean into it. Don't be intimidated by it. Definitely don't shortchange it. Dedicate some research effort. Trust your engineers. Buy those subscriptions, It's 20 bucks a month. Don't be so cheap, please. Indian engineering managers are really cheap with tooling, I think a lot of time. Just spend it. It's fine. It's going to be worth it. I think that would be my big thing right now.Kovid Batra: Great, Jacob. Thank you. Thank you so much. Thank you so much for this. We'd love to have another discussion with you on any of the topics you love in the coming shows. And for today, I think, thanks a lot once again.Jacob Singh: My pleasure. Same here. Good talking to you, Kovid. All right. See you.Kovid Batra: Thank you. All right, take care. Bye-bye.Jacob Singh: Happy hacking!


‘Scaling Startups with a People-first Approach’ with Roman Kuba, VP of Engineering at Tset

In the latest episode of 'groCTO Originals' podcast (formerly: 'Beyond the Code'), host Kovid Batra engages in a thought-provoking discussion with Roman Kuba, VP of Engineering at a tech-based startup Tset. He brings a wealth of experience from his leadership roles at renowned organizations including GitLab, Cloudbees, and CodeSandbox. The heart of their conversation revolves around ‘Scaling startups with a people-first approach’. https://youtu.be/lTtwQ6PPyq8?si=lnOtCuVxjtvu9Ui2 The episode begins with Roman discussing the key events that shaped his life, followed by his responsibilities at Tset. He then details strategies for aligning the team with high-level goals, fostering a collaborative effort rather than a top-down directive. He also addresses challenges encountered during the zero-to-one phase and effective ways to overcome them. Lastly, Roman leaves the audience with essential advice to prioritise user value creation and genuinely care for your team’s ambitions and well-being.


  • (0:06): Roman’s introduction & background
  • (0:52): Life-defining moments
  • (3:54): Roman’s responsibilities at Tset
  • (7:29): Aligning & keeping young devs motivated
  • (10:29): Challenges in the ‘Zero to One’ journey
  • (19:37): Balancing effort & value delivery
  • (22:33): Advice for aspiring engineering leaders

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest who has 12-plus years of engineering and leadership experience. He's currently serving as a VP of Engineering at a tech-based startup called Tset. He has worked with prestigious names like GitLab as an engineering leader, manager in the past. He's a strong believer of giving back to the community. Great to have you on the show, Roman. Welcome to the show.Roman Kuba: Hi, Kovid. Thank you for having me.Kovid Batra: Great, Roman.Roman Kuba: And by the way, a small thing to correct, the company is called (pronounced) 'Set'.Kovid Batra: Yeah.Roman Kuba: I know a lot of people call it 'T-Set', but it's called 'Set'.Kovid Batra: Oh, I'm so sorry for that. Roman Kuba: All good, all good.Kovid Batra: I'll call it 'Set' from now. Is that cool?Roman Kuba: That sounds good. Yes, sure.Kovid Batra: So, we have VP of Engineering, Tset, on the show today. Before we get started, Roman, I would love to know a little bit about you. And let's just start with a life-defining moment for you in your life that has been really impactful in terms of making Roman who he is today.Roman Kuba: Life-defining moments. Well, there's definitely not too many of them or so, but like, I would say one, thinking back, like very far in the, in the past or so when I was like actually six years old, like, that's like crazy long time, right? But I had like a great opportunity or so with my parents back then. Like my, my dad was like still a student or so and this kind of thing. And we, we didn't have like a lot of money or so, but they saved a lot of money for a long time. And we would like to spend like, I think over half a year basically in Australia. So, I'm currently in Austria, right, or so, and Australia was like a lifelong dream for my parents to get there. And that was one of the things or so.Kovid Batra: I'll just stop you here. Just for our audience, Austria and Australia are two different countries, guys.Roman Kuba: Yes, no kangaroos.Kovid Batra: Yeah. So, you were in Australia.Roman Kuba: Yeah, there was like this thing where, interestingly, to this day, I have like still a lot of memories, even it goes back for a long time, right? And on the one side, it kind of like, changed a lot in like how I started looking at the world and various things, right? And like, having this like constant interest to say like, cool, there's so many cool places to see, so many different kinds of cultures to discover, right? And I think this is one of the things that kind of like changed a lot in how I look at certain things, how I look at like certain stuff that's happening in my own country and these kinds of stuff, right? And I always try to keep a very open mind. And I think having this experience as a young kid or so, it really changed how I look at new things. And my early career is like continuing to just like part of like, traveling to other countries, traveling, like using job opportunities in the way of like seeing more parts of the world was a big, big driving factor for me to be able like to find a job that allows us to do this. And yeah, I think by now I've had the opportunity to work with like so many international people. And I think, really looking back or so, I think that was for me, the one thing was, okay, cool, there's so much more out there than this little Austria. Austria is a very, very small country. And it kind of like shaped my interest for just the general world more than anything else, I think could have done in this age.Kovid Batra: Yeah. I think even I relate to that sentiment and the curiosity, this enthusiasm that it always brings is amazing to have. And like it impacts in so many ways that even today, I sometimes think that like when we are talking to people, the openness that we get, all these things are driven from all these aspects of meeting different people, being into different cultures. So I really relate to it and it's really interesting. Thank you. Thank you, Roman, for this quick brief about yourself. Moving on, you are holding this role of VP Engineering at Tset. I hope this time it's right, right?Roman Kuba: Yeah.Kovid Batra: So, what's your daily routine like? What do you do at Tset? What are your major responsibilities that are coming with this role?Roman Kuba: So I was like trying to describe the VP of Engineering is like, even if it's like in a, more in this leading kind of role, right? For me, one important part of the whole thing is like, every day, my main focus is, okay, what can I improve in our organization today? How can I make like the life of each of our engineers, like better in the way that how to do their day-to-day job, right? And I think like, just kind of like supporting thought is the main thing that kind of drives a lot of the actions I'm doing. So, the current company I'm at, I joined only like last June, right? So, it's like not that long ago, actually. And for me, one of the first things when I kind of started, I saw okay, there's a lot of really, a lot of kind of grown processes that the company fell into, right? And there's a lot of these processes that just like start to kind of grow and grow and grow. I've been out there. We're not like in a way that they were helping the engineers on a daily basis, but often people would think of them like, oh, there's like, I cannot do this faster because there's this overhead and this kind of stuff, right? And the other thing I uncovered with this is like, we also have a lot of implicit knowledge, like just in people's heads. And there's like no shared understanding of certain things. Why do we want certain things to be done in a certain way? How do we handle certain situations? What if we do a certain failure, right? And how to recover from these kinds of things? And we had like a very outdated knowledge base at this point where say, if I ask somebody or say, "Hey, by the way, how can I learn about this?" They would kind of first go through their Slack history and see where they posted a link to a certain page, cause they couldn't find it from just like searching or anything. And so, they always say, "Oh yeah, I have this information somewhere." And that was one of the things that started very early on, okay, how can I make life for everybody in engineering better basically, right? And that is like the main driver. They say like, "Okay, I focus a lot on knowledge base and these kinds of things." And yes, the knowledge base part was for me the critical one in saying like, okay, how can I make information discoverable by everybody? But also, how can I make information like contributable by everybody in a very, very small barrier of entry, right? And basically, all of this for me is also like a big part of what does it mean to lead an entire team, right? It shouldn't be like I constantly tell everybody what to do, but ideally, I want to give people context. I want people like, to know how I make certain decisions or which piece of information do I have that they might not have, right? But just opening this up, making it discoverable, make it useful for everybody, that's my day-to-day. And to this or so we're of course, having now challenges, like we need to scale the team when we need to grow and these kinds of things. And to even be able to do this, like you just need to have a very solid foundation as a company, to have like everybody, like, okay, this is how we operate, this is how we work, this is how you can join the team, so we don't lose on the one side, a lot of knowledge if somebody leaves, but also don't have to spend a ton of time in giving somebody who joins the company all this implicit knowledge, right? Ideally, they say, "Hey, go in there, you know, everything where we are, and then you can join the journey from day one, basically." And that's my focus & help, right?Kovid Batra: That's the interesting as well as one of the hardest parts of bringing to a company. It is when we are talking and when we think about things from a high-level perspective, as a leader, I'm sure this seems to be one of the most critical things to have if you want to scale. But the problem here that I've seen with most of the teams is, like the junior folks who are working, they don't intuitively align towards this. And they find it hard to contribute there. As a leader, you know it's important. So you can dedicate that time, that focus and bring in that goal for the team. Did you do anything specific to trigger that counterintuitive behavior for people to actually go and contribute back or help you make this a crowdsource thing rather than just one person doing it? Because it's an incremental process and it has to come from every angle, right? So, were you able to discover anything interesting there and implement it for the team?Roman Kuba: I, at the start, I necked everybody just like, "Where's this documented?" Right. And if I asked the question and somebody would tell me, "Oh, it's like about this or so." Then, I would kind of immediately say, "Hey, please document it." Right. And once it was written down, I then continued to share it further in the team. So, I kind of said that the work people create and how to write things down, I try to leverage it right away, right, so that the person writing it down also sees the value in it right away.Kovid Batra: That's a really good idea, actually. Roman Kuba: Yeah, for me, that is the number one thing or so. And I really hate these weird icons that pop up in a Mac camera recently or so. It's funny. So, please don't get distracted by them.Kovid Batra: Cool, cool.Roman Kuba: But I think this is so critical, right? If you try to make changes, for you as a manager, as a leader, you're more used to just having like a longer feedback cycle in general. I make a change and they're going to see the success or the impact of a change after a certain amount of time. But as soon as you start involving other people, I think it's critical that they get like very instant gratification of how their work contributes to the overarching goal, right? And by kind of leveraging what they do and saying, "Hey, look, this is what you contributed and it already creates value from the first day you did it." I think this is incredibly important for people to actually don't lose track of the change you want to make overall, right? But to say, "Cool, I'm now part of this journey." Right, and then they go in and now they ping other people. So I'm like, "Hey, have you documented this somewhere?" And it started to be a joke at the start where I say, "Oh, please, please, please document it." By now, but people like constantly ask her, "Where's this documented?" So, you know, it's become like a viral way of like how we write things down. And that was pretty cool.Kovid Batra: No, I think that that's a pretty good idea, actually. We just have to like go to the very basics of how we can really incentivize and reward people for doing this activity. And it makes a lot of sense. Cool, Roman. I think this was something about when you were scaling, really scaling the startup, right? But when it comes to the journey of zero to one, like, you have been at Codeship, right? This was a startup where you were part of the zero-to-one journey. I think those are the one of the most challenging times. Of course, scaling is a problem, I don't deny that, but in zero to one, you're fighting for survival, right? So, in that journey, as an engineering leader, I'm sure you must have tackled a lot of problems. But tell us about one initiative or one challenge that you think was really a challenge for you. And how did you handle it? And what did you learn from that?Roman Kuba: Yeah. So, like for everybody listening, like Codeship, that was my first really, I would say tech startup challenge in this case or so. I joined the company in 2014. Yes, that's a long time ago, actually, yeah. And we were like a CI/CD startup, right? So that means when, basically, this constant delivery and testing of software was pretty like, I don't want to say a super-new thing, but having like a SaaS product doing this, it was a thing that was slowly kind of getting more and more adoption in the market and people getting used to it. I joined that company actually as one of their very early members, as an engineer, I was like still really a front end developer or full stack developer back then, even like, and focused a lot on the front end part. For me, like the, cause you say, what is the challenge? Like there were a ton of challenges on a daily basis back then. Like, everything there, I had to learn a ton of stuff, like, how do startups work, how to make really, basically, build a SaaS product, right, that you have like a ton of other developers rely on now on a daily basis to say like, "Okay, how can we ship things without breaking it? How do we recover from mistakes?" And these kinds of things, right? That was amazing. And I would say, if I think about one specific thing that the biggest one is been there for some time and like we started to introduce a lot of like different kinds of JavaScript stuff, of course, like to make, drive a lot of the very interactive parts of the application, like think of a log output, right? If you know, run something on your terminal, of course, your terminal prints all this stuff. If you do it in the web, right, then you suddenly, basically, need to take all this kind of terminal content and present it to the user in pretty much real time in the web interface, right? And that was at a time where say, jQuery was like still very, very active. And Angular was one of the bigger frameworks and it was Angular 1. And React was like just coming, was slowly the thing kind of driving in, right? And we had this one page of a new part of our product where you could run like a lot of like really complex bills and you would get like a ton of terminal output. I think you would talk about like basically, on the screen, like about, 50-60K DOM nodes that you need to render in basically, like real time for them constantly, right? And it's expanding and this kind of stuff. And there was this one big challenge where I say, okay, we had big customers and they had very big logs and that page was just like crashing the browsers for users. So, we're not able like to look at their log output because it was just like too many DOM nodes to properly handle this refresh and this kind of thing in the way we did it back then. And from the engineering side or so, the interesting part was I really needed to spend a lot of time in dissecting the problem, where was like the big bottleneck, right? We looked at a ton of different kinds of metrics on the time to paint and the refresh on kind of when do we touch which kinds of things. And we had Angular back then as the main driving part for this front end page. And within basically, a week, I did two POCs. One was with React and the other one was with Vue back then. And Vue was like completely unknown. It was like this little fun side project from one person, right? Nobody has heard of it. It was like zero point something. And I had basically, neither knowledge, nor in react, nor in Vue, right? And for me, it was like my main go-to was okay, looking at a piece of documentation, say, "What can I learn about this piece of tech to solve my problem?" cause I identified that rendering is the biggest part in the refreshing and Angular was just really notoriously bad at refreshing a lot of nodes. And like I know back then, so it was React with a constant like, I would say roadblocks we hit back then, cause it was like much more complicated. And the big roadblocks were on a lot on the technical side of things cause we also had to take into account what is the knowledge we currently have within our team, right? It's not good or so if like I build something that only I understand and nobody else in the company can easily contribute to, right? So, taking these constraints into account is incredibly important, especially in the early parts of the journey of a startup. You need to take all the resources you have in a smart way. And with Vue, I was able, like to build this page in such an easy way that even a backend developer could look at the code, understand how it works, understand how to contribute to it or so in a very easy way, and it didn't need to jump through a ton of like building hoops and kind of steps to understand it and so, cause it was looking so similar to just like plain HTML in the way it was rendered, right? So, it was, we'd like to build this POC basically, within a week. And then, it took me like another, like half week, week or so to implement it really in the product with everything they wanted to do. And then, there was this defining moment, okay, of like, I recall this moment. Like, you click this button in your own like UI and say, "Okay, let's merge it to production." It goes live, really just all the tests ran through, kind of like it went live and then you see it's deployed. And say, okay, now all the users are seeing that piece of code running, right? And then suddenly, the browser stopped crashing. Like you had users, "Hey, it's working for me." And that was like, for me, this thing was a, that was very defining the way I started to look at, okay, what value tests bring, what value documentation brings, what value like other parts within the company bring regarding knowledge we have and constraints. And yeah. That was, it was a fun one or so. And I think it helped a lot in the journey for the company.Kovid Batra: So now, like just going back and thinking about the same incident, what do you think that one thing drove you towards solving this problem? Like, what comes to your mind? Was it your curiosity to explore something else or was it something like the need of the hour and there was no escaping it? What pushed you to actually go forward and take up this challenge?Roman Kuba: Like, I was basically the only front end developer back then, right? I was the only one able, like to fix it.Kovid Batra: Yeah. So, it was more of a question of survival for you then. Roman Kuba: Yes. It was, like for us as a company, it was really, we have this product, we want to sell it, like this customer is curious, right? But if I have like this negative connotation with our product where people say, "Oh, it's not working." That's just not great, right? And for you as a startup or so, I think you always need to make very conscious decisions on what you do, what do you focus on, right? There's always like ideal solutions to say it is the best solution you can build or the other one is like, okay, what is the solution I can build now that just provides the most value to our users, right? And sometimes, even the value for the user and the ideal solution, they just go in very separate ways, right? And I think that is the thing I just learned at this point or so, when do you prioritize the right pieces of code? When do you kind of like look at what do I really need to invest in long term as a company? And it also changed a lot of my perception when it kind of, concepting things about like, where do metrics play a bigger part in the way what I build, right? like I started to weigh, look more for like performance metrics from the start. I'm looking at really edge cases in how I build things, how fast am I actually in deploying and recovering from these kinds of things. So, yeah. Ideally, if I can go incrementally forward with these kinds of changes going forward, that's always like the better approach than just say, throwing everything over the fence and restarting. That was more just like escape hatch because we had a really big problem. But usually, always making smart decisions with the constraints you have in mind and say, "Okay, what do I need to make as a small step to bring me closer to the ideal value I want to create for the user?" And my ideal solution can be the really North Star, but it shouldn't be my first stepping stone.Kovid Batra: First step towards that. Totally. I think it's a great, great piece of advice. And being in that position and taking that call, I think is the hardest part. Like, when you talk about it, you can say that just keep that balance on, like, don't go for the ideal solution, just look at what's the next best step. But that really requires some level of research, some level of understanding of what should be the next first step, because you can end up being in a tech debt situation for things like these that you have been doing. And it could be that you might delay the delivery. So, I think great piece of advice, but if I have to ask you, what exactly is that framework or even if it's not a defined framework, how do you take that call that, okay, this is going to be the first step. What's that feeling that you get when you see, okay, this is what I'm going to implement and this is what I'm going to leave for the next step. How do you decide that?Roman Kuba: I would say always like to weigh a little bit, the risk, right. Especially in a startup, like everything that you do has a lot of risk involved, right? If you build new features, have you validated them with users, will users like them and these kinds of things, right? And for me, it's always like on one side, I want to kind of like, I don't want to say minimize risk, but I want to keep the risk to a low amount of like effort when it comes to my previous investment. For me, like if I need to spend like a month of building something and there's super high risk involved in like, if it's even a month spent well, right? That's something, especially in the startup world, a month is like a ton of time. You're not, you're never getting this back, right? So, if you say, "Okay, that's for me, actually a step I can take. That takes me only like a week." Right? And maybe it's even like a higher risk or so, or like a lower risk in this case, right? Then I think that's always like the better thing to do. Even if you say like, okay, maybe it's, maybe I then need another month or afterwards to validate what I'm doing or so. And then later, a user says, "Yes, it's the right journey." Then you invested a week, right? But the thing is, so, if you invest a month and then it's like the bad thing, it's, yeah, you're not getting this back. But having a week and then spending an extra month to say, "Okay, yes, it was a good idea." That is how I usually kind of try to look at things. Yeah, that's the thing. Just getting you to the goal and getting the confirmation that like you don't waste your resources. That is, for me, the big thing.Kovid Batra: Makes sense. Just to add to it, I think a lot of times, we as developers make a decision purely based on the effort it's going to take and we just find the shortest paths to it. What I loved about your narrative is that there was no single point when you were thinking about the effort that would go into it. You were always thinking from a customer standpoint, like what value should be delivered right now. So, even without you saying, I'm just taking this from you that thinking for the customer, delivering the value should be the primary objective in your mind. The effort, whether it is one week or 10 days or diving into a new technology to ramp up your learning and do stuff, I think that never became the hurdle for you. It was always just the path that you have to take to deliver that value. So I think, amazing, Roman, I think I already feel inspired from the way you are thinking and doing things. All the best to you for your upcoming endeavors and may you shine like this ever. On that note, I think I would ask for one last piece of advice for our audience today from you as an engineering leader, as an engineering manager, people who are aspiring to be that what would you like to tell them?Roman Kuba: That's a fun one. I would say, the engineer in me would say, like really focusing on the value is the number one priority because your user, they just don't care which piece of tech you're using, right? They're not caring which framework you're using and all this kind of stuff. And it's for developers, very uncomfortable. And this thing I needed to learn. But making a decision that says, okay, even if it takes you a little longer, what is the thing you want to create for the user for them to get the benefit, right? That is for me, the number one thing. Start thinking about the value you want to create. The leader in me just says or so for anybody, because I went through this journey, right? Like being a developer, then leading a front end team, then stepping up to become an Engineering Manager, right? What I always did and do to this day is like really honestly caring for the people you work with, like understanding their ambitions, understanding what they want to achieve, right, or so. Like, everybody, even they, when we talk about tech, right, they also have fears about like, do they make the right decisions, right? Really genuinely be interested in what people think, how they feel about certain situations, right? Because in this case, you also want to create value for the people that you work with. And I think that is the number one thing, like yeah, generally care for each other in this kind of case or so. And do this journey on a startup or a tech product that you're ever building, like together. And yeah, that's my advice, I would say.Kovid Batra: Great, Roman. Thank you. Thank you so much for this advice and thank you for your time today. We'd love to see you on the show again once we hit a benchmark where we have another episode and we would love to call guests like you back on the show. Really loved the talk.Roman Kuba: Thank you, Kovid, for having me. It was a pleasure being here.Kovid Batra: Thank you, Roman. See ya!Roman Kuba: All right. Take care. Bye-bye.

‘DORA, SonarQube & First 90 Days of Leadership’ with Glenn Santos, VP of Engineering at PDAX

In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code), host Kovid Batra welcomes Glenn Santos, VP of Engineering at PDAX. Glenn is also dedicated to empowering developers to become leaders with his initiative ‘eHeads’, a community for engineering leaders to exchange experiences and insights. His vast experience includes valuable contributions to renowned companies such as Salarium, TraXion Tech Inc., and HCX Technology Partners. The discussion revolves around ‘First 90 Days of Leadership, DORA & SonarQube’.

The episode kicks off with Glenn sharing his hobbies and life-defining moments, followed by an insightful discussion on how Glenn as a VP of Engineering manages his role, the company’s mission, and day-to-day challenges. Further, he shares strategies for aligning developers with business goals and navigating compliances in FinTech while maintaining velocity. He also shares his 90-day draft for building trust in the initial days as a leader and highlights the use of DORA metrics and SonarQube to measure team success, address integration challenges, and plan targeted improvements.

Lastly, he offers parting advice to aspiring leaders and engineering managers to embrace leadership opportunities and prioritize personal growth over comparing themselves to others’ progress.


  • (0:06): Glenn’s background
  • (0:37): Glenn’s hobbies & life-defining moment
  • (2:38): Role & daily challenges at PDAX
  • (3:37): Aligning tech strategy with business goals
  • (5:22): Aligning team & individual goals
  • (8:00): Managing velocity and compliance in FinTech
  • (11:31): First 90-day leadership plan
  • (14:56): Measure engineering team success
  • (17:24): Implementing DORA & SonarQube
  • (21:58): Parting advice for aspiring leaders

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He’s currently VP of Engineering at PDAX, which is one of the best crypto and digital asset exchanges in the Philippines. He’s also known as the organizer of eHeads, a fellowship for local engineering leaders. His trajectory of career has revolved around mainly helping others work better. So he’s a passionate tech leader with a lot of compassion and empathy. Welcome to the show, Glenn. Happy to have you here.

Glenn Santos: Thanks. Thanks for having me.

Kovid Batra: Great, Glenn. So, before we start off and learn some great stuff from you, from your experience, we would love to know a little bit more about you, like your hobbies, your day-to-day activities. So quickly, if you could introduce us with yourself and tell us about your life-defining moments and some of the best experiences that you have had so far, your hobbies, how you unwind your day, I think that would be great.

Glenn Santos: So probably, my most life-defining experience was when I discovered TechCrunch before. So, when TechCrunch was just starting out, I was just a usual rank-and-file worker in a big company. I wasn’t a developer at all. So, when TechCrunch published like 10 ideas on how to create a startup, these were the ideas that they thought would boom. I found one that was particularly something that Filipinos here where I am from could do, which is some sort of labor arbitrage. So, it’s called outsourcing now. It’s very popular across the world. But at that time, we did not have the technology to make it easy, so I had to build my own forum, I had to create my own website, and do all the other stuff needed to get that business up and running.

For my hobbies, I’m actually an avid fan of cars. And I’m also a foodie, as they call it. So, I like trying new foods. Technology-wise I still read, like, Hacker News to keep up-to-date. But I also mix it up with some newsletters to supplement my knowledge in engineering management. And I share my learnings in my LinkedIn. That’s maybe a quick run-through of what I, yeah, what I’ve done.

Kovid Batra: Yeah. Yeah. That really helps. Thank you so much for this intro and coming to the main section, the main discussion, like when we want to learn something from engineering leaders like you, I think the best would be to start with your current role wherein if you could just tell us, what you do as a VP of Engineering at PDAX, what PDAX exactly does, and what your day-to-day challenges are. I think let’s get started from there first.

Glenn Santos: So, as VP of Engineering, I handle most of the people side in the engineering management role. So, my focus is really on people and the processes that enable them to work better. So right now, one of my initiatives in the company is to roll out DORA metrics and SonarQube. In my day-to-day, I actually do 1-on-1s, I join meetings with engineers and I also help plan out what, since we’re at the start of the year, I’m helping plan out what we’re going to do for 2024.

Kovid Batra: So, when you say you are planning what is gonna go out for 2024, I mean, this is basically what a VP Engineering would be doing, like connecting the business to the tech side and, like enabling the teams to be aware of what we should build and what strategy we should follow. So, I think this is one interesting piece. And this is one of the challenging things of a leadership role where you bring in the business and align it with the technical strategy. How do you exactly do that? And if you would share some of your experiences with aligning your teams to that technical strategy which ultimately aligns with the business goals. So, how do you do that?

Glenn Santos: So, first I need to understand the business goals for this year that’s going to be actually rolled out next week. But right now, it’s pretty clear what our direction will be business-wise. So on my end, I have to translate that into something that will help the engineering team with the help of product, of course. In our organization, product is separate from engineering. So, we align ourselves with each other so that the features that we build are according to that roadmap from the executives.

And aside from that, I also have to make sure that we keep code quality high because one of the things that I’d like to implement is that we build features more quickly. So, that’s enabled by better code which actually is a very good flywheel that contributes to the speed of development as well. So, we can do more with less once we have better code.

Kovid Batra: That totally makes sense. When it comes to aligning the team with these goals, it’s always a challenge for making the developers intuitively or naturally aligned with these goals. So, what exactly would you do in your meetings or your day-to-day work to ensure that these people are on a day-to-day level aligned with the business goals and the work that they are doing? Because it’s always a secondary effect, right? Like, the developer builds the code, ships it, and then ultimately, they see the results when the features are being adopted or your system is getting faster. So, it’s always a second-order effect. So, in day-to-day, how, do you make sure that they relate to that second-order effect goals and get rewarded with that actually?

Glenn Santos: So, when we’re building things aside from the regular, I think most of your audience would be familiar with the stand-ups and the catch-ups with product and the entire team. So, that’s part of it. But another part is, I always reiterate during our own engineering meetings, why we’re doing these things because we need to connect that with their own motivations. Each person has a different motivation, but I’m hoping that most of our engineers are motivated by growth and learning as well as achieving something that’s impactful. So, we share metrics in our meetings. We share how the users are accepting their features. And we also want them to, like connect the goals of whatever they’re doing with their own personal goals. So, we’re a fintech company that’s focused on wealth, increasing wealth. And most of our engineers are actually crypto traders as well. So we give, we roll out initiatives like helping them learn more about crypto and also how to handle their own funds. So that’s also something that we strive to do at PDAX.

Kovid Batra: I think that’s the best thing that you can have, like the people who are building the tool for a user, they themselves are users of that product and they understand the problem statement, they understand the solution around it. I think you answered the question really well here and you’re lucky to have that kind of motivation because in a lot of cases when people are building, let’s say some B2B products, the developers are totally disconnected from the kind of audience they have to build the product for, right? So, I think you’re in a good position and it’s a good strategy actually.

Cool. I’ll move on to the next question, Glenn. So basically, when you say that you are working with PDAX and it’s a financial institution, I’m sure there are a lot of compliances and security issues coming into the picture and, being a fast-moving company, you have to roll out so many features and in as less time as possible. So as a leader, how do you manage that balance? Because that is a little bit of a challenge. And when compliances come into the picture and specifically in FinTech, it’s a big, big challenge. So how do you manage that, your velocity while making sure that you are fulfilling all the compliances?

Glenn Santos: Yeah. Good question. Currently, we’re, there’s a really like a push and pull here. So, other teams, they need their central bank requirements because that’s part of the regulations, but we also want to build something quickly, which is also a mandate from our CEO, actually. So, what we do here is we actually set aside time for that compliance stuff. And, for the most part, it’s not handled by the engineers themselves. I let the managers handle that. But for example, we need input from tech leads or engineers, we need to bake that in so that it doesn’t disrupt their flow. So, I’m still a big believer of giving them a maker flow, these engineers, because that’s the only time where they can deliver quickly. And they’ll have well thought-out solutions to their, to the problems that we give them. So, we don’t want to interrupt that. But at the same time, we also want them to be communicative and collaborative. So, I think having those standups and having them work more async is actually key here so that they can contribute when they need to, but not, we don’t, like rush them into contributing these admin tasks.

Another thing is that we want to also build rapport with these other teams who are not technical, who might not understand what we’re doing so that when we’re, like a bit delayed when giving responses because we’re working on other stuff, we can smooth things out. And that’s actually another part of our like what we’re doing in the company currently, some process improvements so that these asks from external parties are handled well.

Kovid Batra: I think this is a good strategy where you are segregating their work to an extent where they don’t get interrupted in the flow of work on an everyday basis, but also they’re aware of things that are going on and they understand the context of it so that, as you said, like when they need it, when they need to contribute in that direction, they have that context and they implement it accordingly. So, yeah, I think balancing this on a day-to-day level is the key here probably because you don’t know when things go more into that direction where you are interrupting them every time. And then, there could be situations where they’re not completely aware of what’s going on on the compliance side and they end up building something which doesn’t fall into the picture and they have to rework. So, I think the balancing act is a must here, which I’m sure you’re doing. And you joined PDAX I think very recently, it’s most likely one year or so.

Glenn Santos: Less than a year actually.

Kovid Batra: Less than a year? All right. So, I think this is also an interesting piece, coming in at a leadership position and building that trust with the team. Right? So, this is something where I see a lot of people struggle, like people just don’t take the authority. In today’s world, at least they don’t just take the authority. They want to, like be influenced in a very subtle, different manner from the leaders. So, how are you handling this role? How are you handling building of that trust with the team in this initial year?

Glenn Santos: So, when I started, I actually, before I even started, I interviewed all the leaders that would be under me and I’ll be working closely with because I wanted to establish that initial rapport. I wanted to know if we clicked because for the most part, you don’t want your reports to be, like going against you. So, you want to have some harmony. When I started, I also actually, and I still do frequent 1-on-1s because I want to get to know them not just for their work, my direct reports who are engineering managers. I also want to know, what makes them tick, what they’re really like, and maybe some of their interests outside of work. So, that’s part of it.

And aside from that, for the engineers themselves, I’ll start doing some skip-level 1-on-1s as well so that I get a holistic picture of the engineering team. But, when building trust with them, I’m very transparent and open about what we’re going to do. So, I always reiterate that our goals for this year are code quality, this is how we will be measured, and I also want people to be more learning-focused this year. So, I’m really hoping that that aligns with them because one thing that I’ve taught recently is that you cannot give people motivation. They have their own motivations. You just have to align yourself with them so that they can do their best work.

Kovid Batra: Anything that you specifically follow when you join in? Any basic rule or format or template that you follow that, okay, whenever I’m going into a new position as a leader, like this is something that I should continue doing for some time.

Glenn Santos: Yeah. I actually, since I’ve joined a few companies recently, I’ve actually created my own 90-day, like my 90-day draft on what I should do in the first 90 days. So it’s split into 30, 60 and 90. So, while the goals are not that set in stone, I do want to get as much information about the organization as possible in the first 30 days, as well as talk to as many people in the organization. Yeah. So I go to, I actually go on-site, we’ve returned on site already, and I need to talk to as many people because for our companies, you have to interact with people who are not in tech, maybe some people in operations, some people in sales. So, you’d want to build that rapport with them so that they understand you and you understand them when they have things that they ask from you.

Kovid Batra: Right.

Glenn Santos: Yeah, so that template has been very useful for me. There’s actually a book out called ‘The First 90 Days’ I think, that I use as a basis.

Kovid Batra: Perfect. Great. Glenn, the last thing which I want to touch on with you in this discussion is something that you just mentioned you have taken up as an initiative: setting up the DORA metrics. So, DORA metrics is probably one aspect that I want to understand. But broadly, I want to understand what’s your way of measuring the success of an engineering team. Like, if your team is doing good, how do you define that for the team and how do you make sure that everyone is aligned on those KPIs and metrics, maybe DORA metrics? And, what all goes into setting up that momentum for the team so that everyone is motivated towards those? That they just don’t feel that they are under a microscope when you are talking about KPIs. They should naturally feel to work on those KPIs when they are working on a day-to-day level. So, I just want to understand this whole piece from you.

Glenn Santos: So, one of our, I guess our rallying cry this year is to be better engineers. So I’m pretty sure most engineers want to be better. So, DORA metrics, I also tell them that this is not actually some sort of measurement that we use just for that sake or to, like rank you. I want to use it to really create better engineers because when you follow the metrics, you’ll naturally hit roadblocks. Engineers love problem-solving, so this is one way to, like attack that part of the brain that loves feedback. It’s a very quick way to reinforce the feedback loop. That and SonarQube, which is also an automated way to collect metrics.

So, people love gaming, and we’ve seen that gaming is very very effective in producing behaviors that we want. And this is one way for them to really see if they’re doing well, they’re publishing clean code, they’re creating code that has no bugs, no vulnerabilities, so we want that. And also, it’s a team metric more than an individual metric, because the emphasis of DORA is really on teams. I want them to be more collaborative. So, if it fails, we’re not singling out one person. I’d rather tell the team, “Hey, you’re not doing well, help each other out, raise these metrics so that we can deliver better products to our customers.”

Kovid Batra: Right. Makes sense. Apart from building this first-level alignment of the team towards these metrics, what challenges did you see while implementing these success metrics for the team? And any specific example? So, I’m not sure if you have implemented it yet or not, but, let’s say, if you’re looking at implementing it, what would be your go-to strategy? What would be those one or two important metrics that you would be tracking? And how, again, you would bring that alignment with the team that, okay, these are the right metrics that we should be focusing on right now?

Glenn Santos: So, we’re actually in the process of implementing these metrics. We’ve ranked them accordingly. One thing that really stands out that I’d like to measure is the reliability of our code. So, that’s automatically measured by SonarQube. So one thing that I really emphasize here. One of the roadblocks, sorry, that we’ve come across is that if you’re using systems, different systems for like CI/CD or another company for your repos and maybe another company for your servers, it might be best if you streamline these first because that’s one of the challenges that we had. We had to string them together and DORA metrics is ideally collected in real time. So, for now, we’re not collecting it in real time. But, if for example, everything that you have is in AWS, it might be simpler or everything you have is maybe in Atlassian, that’d be simpler. And probably one of the people’s side challenges of implementing metrics is actually getting them to integrate, especially if you have lots of repos.

Kovid Batra: Yeah.

Glenn Santos: So, having time for them to do that, that’s usually the challenge. Do they do the features or do they do these integrations? So, I have to work with product, say that we need to slot this in. Maybe, you can slot this in, like before the sprint or during the sprint so that we can start collecting the metrics because we can only act upon the metrics once we’ve collected them. And yeah, we’re actually at just that part right now.

So, the next phase would be creating a plan, how to improve those metrics. So, we are not there yet, but we don’t want to plan ahead because that might involve, you know, we say that this is wrong, but our metrics would say that actually we’re doing okay here. So, we can focus on other metrics that are not up to par. So, we can put our engineering efforts there. So, it’s more targeted and has more impact.

Kovid Batra: Yeah. I think it also makes sense. Like, you cannot really jump the gun here. The whole point of having metrics is to first understand the problem. So, if you will just say that, okay, I will pick up this metric and start working on it from today itself with the team, that might not actually align with the real improvement areas. So, I think the thought process that you have right now for implementing these metrics makes a lot of sense. Like, first-level implementation, getting in place, getting that data in place, people looking at it regularly. And from there, you will start getting those indications where the inefficiencies lie. Just for example, if we talk about change failure rate, right? This is one of the important DORA metrics that needs to be tracked. So, if in your team, there are a lot of failures once you release to production, then that becomes the area of focus. And then, you start working towards it, taking measures towards it. But, in the beginning itself, if you say that okay, let’s start working on change failure rate, and surprisingly, your team is doing good on that metric, the team would say that why are we doing that? That would make it lose its purpose. So, it totally makes sense to look at it very deeply and understand at every team level which metrics would really work out for them. It’s not that for a particular team, the same metric that is working out would work for the other team also. So, it’s a process. I think the way you were taking it up, like phase-wise is something I would say is the right way to go about it.

And, great. I think, Glenn, it’s really nice to understand these things when you’re implementing them hands-on. I’d love to know more insights from you when you do this implementation. Maybe we can have another session, another podcast where we discuss about how you implemented those metrics and what rewards you got out of those. So, great. I think, it was a great, great talk. And before leaving, I would love for you to give parting advice to our aspiring leaders and aspiring engineering managers who are listening to this podcast, how they should move ahead in their career.

Glenn Santos: So, one of my big pushes really is, and you can see it in my LinkedIn that I want developers to become leaders. We don’t have enough engineering leaders actually, and not enough developers are interested in leading. So, my advice is for people to try it out. You can pedal back if it doesn’t really fit you, but it might be another way for you to grow. So,, right out within your own company, maybe you can help another startup out. And when you’re going through this career journey, it’s not really for you to compare yourself with others. Other people would have done pretty well and other people might have really not progressed that quickly, but don’t compare yourself to them. Compare yourself to what you were, like maybe one year ago, five years ago. As long as you’re, like progressing in a good pace, I think your career as an engineering or engineering leader or an engineer would really go far.

Kovid Batra: That’s really great advice. And I think the best part I felt is that you said, “Keep on trying it with other startups and companies.” So, I think having that hands-on experience and being in those situations would really, really build that quality in you. Like, reading books or just listening to a few podcasts might give you some initial framework on how you should do it. But the real belief I would say comes in when you have done it hands-on multiple times, probably.

So, great advice and thank you so much for this amazing, amazing discussion. I would be more than interested to talking to you again about your experiences of implementing DORA and handling your team, maybe six months down the line, how it went down and how it went up. So, let’s get in touch again. Thank you for today. I’ll see you soon.

Glenn Santos: Thanks. Thanks, Kovid. Great to talk to you.

Kovid Batra: Thank you.

‘Leading Dev Teams through Acquisitions’ with Francis Lacoste and Miroslaw Stanek

In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code), host Kovid Batra engages in an insightful discussion with two dynamic engineering leaders: Francis Lacoste and Miroslaw Stanek.

Francis has formerly worked with Heroku and Salesforce & is now a VPE and CTO Coach specializing in scaling up startups. Miroslaw is the Director of Engineering & the PL Engineering Site Lead for the Poland R&D division at Papaya Global. He’s also the author of the newsletter ‘Practical Engineering Management’. Explore the theme of ‘Leading Dev teams through acquisitions’ by delving into their real-life experiences.

The episode kicks off with Francis and Miroslaw talking about their personal lives and hobbies. Moving on to the main section, they dive into the acquisition experiences and the pivotal hurdles faced by the engineering leaders in their respective organizations. They stress the importance of swiftly merging company cultures post-acquisition while addressing challenges in navigating the ‘us’ versus ‘them’ dynamic. The conversation also explores strategies for maintaining engineering team efficiency without sacrificing value delivery.

Lastly, Francis and Miroslaw share parting advice with engineering leaders who are navigating similar challenges.


  • (00:05): Miroslaw & Francis’ background
  • (04:23): Challenges of leading dev teams through acquisitions
  • (07:40): Navigating the transition period
  • (20:50): Lessons learned & areas for improvement
  • (27:20): Maintaining team motivation
  • (35:22): Measuring efficiency during transition
  • (41:02): Aligning team practices with new requirements
  • (42:54): Parting advice by Miroslaw & Francis

Links and Mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today, it’s a unique episode for us and we have some special guests. In fact, we have two amazing guests with us, Mirek and Francis. Both of them are accomplished engineering leaders. But they have one thing in common, their passion for contributing back to the engineering community. And that’s why we connected. So, Mirek has been on our show previously, but let me introduce him again. He’s the newsletter writer for Practical Engineering Management. He’s the Director of Engineering at Papaya Global. Francis is coming to our show for the first time. He’s an Engineering Leadership Coach. He’s a seasoned engineering leader and has worked with companies like Heroku, Salesforce and more. I’m glad to have both of you on the show. Thanks for coming. Thanks for joining in.

Francis Lacoste: Hi, Kovid.

Miroslaw Stanek: Yeah, thank you, Kovid. Hey, Francis. Thanks for having us.

Kovid Batra: Great. Francis, Mirek, it’s a basic format, like before we jump on to our today’s topic of leading dev teams through acquisition, I think it’s great if you could share some of your hobbies, some personal things about yourselves with the audience so that they know you a little more. So, we can start with you, Mirek, would you like to go first?

Miroslaw Stanek: Yeah, yeah, sure. Yeah, like Kovid said, it’s my second time in this podcast. but, for new people listening to us, my name is Mirek Miroslaw, depending on which pronunciation you prefer. Like Kovid said, recently I’m the Director of Engineering for the company Papaya Global. I’m also the site leader, leading the Polish R&D side of this company. And I also write a newsletter ‘Practical Engineering Management’. Basically, I try to help engineering leaders to maximize impact of their work and make their teams successful.

Personally, I’m the father of a three-year-old daughter. So, showing her the way, exploring the world, answering all of the questions. And, recently I’m also becoming a professional athlete. Yes, even after being 35 years old, you can still apply for the license. So, I’m an obstacle race runner. I have some aspirations, maybe, you know, not the box on the Olympics, but still, you know, I’m enjoying the ride and then hopefully, we’ll be able to share some successes over time. Yeah, so, thanks for having me.

Kovid Batra: All the best. All the best. All the best. Thanks, Mirek. Thank you so much for this lovely intro. Francis, your turn, man.

Francis Lacoste: So I’m Francis Lacoste. I’m based in Montreal in Canada. I’m an executive coach working mainly with CTOs and VPs of Engineering at startups. I help them specifically when they need to scale their team. And this is where we, they need to get really deliberate with culture. This is my passion, really making sure that teams have a great engineering environment like I’ve experienced. Before that, I was an Engineering Leader at Salesforce and Heroku and started my leadership career at Canonical, which was an open-source company, the one that made Ubuntu. And this is where I started learning remote management back in 2000.

Outside of work, I play in an electronic ambient band. I play a hands-free instrument, the Theremin, which is the space sound music type of sound that this instrument makes. Also, I have a long practice of meditation and I now also teach meditation with the Buddhist geeks, which is an online organization.

And it’s a pleasure to be here, Kovid. Thank you for inviting me.

Kovid Batra: Great, Francis. Thank you. Thank you so much for that lovely intro. I would love to hear you sing and play the music sometime.

Francis Lacoste: Well, we have a Bandcamp and we’re on Spotify, so I can give you the link in the show notes.

Kovid Batra: Oh yeah, that’s cool! Great. Francis, Mirek, we are here today to discuss around the challenges that engineering leaders face post-acquisition. And both of you come with immense experience. You have spent time in different-sized organizations. You have had startups, worked with companies as big as Salesforce, Francis, as you just mentioned. I’m sure you have had experiences of acquisition, right? And various types.

So, to start off, tell us about what kind of acquisition experiences you have had. And what were the biggest challenges as an engineering leader or as an engineering team you saw for the company getting acquired?

Francis Lacoste: Well, at Salesforce, we had many, there were many acquisitions. I came in with Heroku just after they had been acquired. And the Heroku acquisition was kind of a weird one because it took like that very long time. It operated somewhat independently. That was part of the main challenge. You know, the challenge is how do you integrate the culture? You know, it’s an integration problem. The big challenge was the ‘identity’ one. We’re identified as Heroku, but Heroku is now part of Salesforce. How can we be seen? How can we embrace the bigger identity of Salesforce? So, that’s how I would characterize its essence, the challenge we faced. And, it was not inside of it, but concise on, there were many other acquisitions, some more rapid where kind of you’re acquired and then there’s.. It’s a technology acquisition, so the product kind of shuts down very rapidly, things like that.

Those are other challenges, but there’s still this identity issue that’s very present there because usually people are not happy when losing identity.

Kovid Batra: Sure. I think we’ll come back to you for more details on that and discuss more things in depth. Mirek, what about you?

Miroslaw Stanek: From my side, basically the company I’m working for recently, Papaya Global acquired the previous company, Azimo, where I worked for almost eight years. What was the challenge of the acquisition? I think that the merging process in general, yeah. So, my role in the company was like, I would say, middle-level manager as a Director of Engineering who leads leaders who lead individual contributors. Basically, our main challenge was to make sure that the entire know-how which was acquired by, you know, by the bigger company is utilized because we came with know-how, we came with, you know, experience, and then the long stories, ways of working, but this is still in the sphere of, you know, of the potential which you can give to the company. And as a leader, as a manager, you need to be sure that this potential is somehow utilized. So, I think this is the biggest challenge. So, finding good places for the skills which we are bringing with you and you know, it opens all of the challenges around that. Yeah so, the ones about the organization, the culture, the team structure, and everything. So yeah, this is how it looks like in the general view.

Kovid Batra: Makes sense. Diving deep a little more into this challenge, how on a day-to-day basis are you navigating this situation? And Francis, please feel free to share your opinion or Mirek, please feel free to discuss anything that you feel should be known to the community also which you are facing as a challenge today. And, Francis comes with a lot of experience. I am sure he would have certain advice on how to navigate this situation.

Francis Lacoste: Yeah. I mean, I’ve coached people who went through acquisition as well, so that’s another source. I think one of the things that is very important to get going is to know what the context of the acquisition is. You know, there are multiple reasons for an acquisition. I’d say there are three main ones. So, the first one is usually a strategic product acquisition. Your business is acquired because, it’s seen as complimentary. I mean, there’s two, actually, there’s two there, you know, it can be because they want the revenue. So you’re in the same space as your competitor. And they just want, I mean, the one who’s acquiring is kind of a competitor and they’re kind of getting your customers and they want to add their customers there. That’s one strategic acquisition.

The other one, which was more like Heroku and I think in Mirek’s case here, is there’s a complementary product. You know, so it’s kind of Salesforce wanted to expand its reach in the developer space and Heroku was very at good traction in the developer space. So, it was okay work. And, and you’ve seen that in Salesforce. You know, we have a portfolio of companies they acquired, exact targets to add, like marketing capabilities to the CRM, Tableau to add analytics. So these are kind of products complimentary. And the idea is that when you go to sell to customers, you have, like a more comprehensive solution to sell them. So, that will drive more revenue.

Kovid Batra: Right.

Francis Lacoste: So, this is like the strategic acquisition and that will be very different, how it goes and how it will go away than these other two, which is ‘higher acquisition’, you know. So, you’re acquiring a company because of talent. You, you want to usually this will be as you acquire a small startup where you’re not really interested in their product or that technology.

Kovid Batra: It’s just the team that you need.

Francis Lacoste: It’s, “I want the team.” You know, there’s this, and usually it might be one person in the team. You know, there’s like a, somebody has like a very deep expertise. They’re not willing, they have a stake in the company, they’re not willing to jump ship. So they’re going to buy the company so that they can work for the bigger corporation. That’s a very different context than the first two.

And the third one is a tech acquisition. There, it’s not like you don’t really have traction. It’s not about your customers or things like that, but there’s complimentary technology. So, they want that tech. You know, you’ve solved one problem for them and instead of building it by themselves, they will buy you. And depending on that context, it will change a lot of how the acquisition will go.

But, what’s your experience with it, Mirek? Is it like, was it more technology acquisition, a talent acquisition or a strategy acquisition?

Miroslaw Stanek: Well, You know, in the, I think in the end, it’s those types of acquisitions, they have a lot in common because yeah, you can acquire the product, but in the end, you know, there are people behind the product. So even if you have this piece of technology, you still need to have those talented people who can maintain that, who can plug it into, you know, into the new structures and who can continue the growth. I think that, we are kind of mixing both things. Obviously, we expanded the new company’s portfolio, but we also brought, you know, fresh talent, new perspectives and fresh know-how to the problems which can also be the strategic problems for the company, yeah? The company wants to grow. The company wants to expand their portfolio. So bringing, you know, fresh talents who spent years building this or that can be a part of this acquisition.

Kovid Batra: Cool. Francis, do you have any questions that you wanted to ask Mirek?

Francis Lacoste: I think Mirek is right here in the sense that these three types that I said, or four, you know, if you split the first two, they will often overlap. This is what is always interesting about the Heroku acquisition, you know. Heroku was a strategic acquisition. So, what it means is that the first thing that they do is they will usually give autonomy to the product because you don’t want to kill the golden goose. And that creates a challenge because then it will mean that you will have, like kind of two independent or semi-independent organizations going by and in Heroku’s case, it took basically seven years to complete the integration. Actually, that’s not true. Like, five years after I joined, for the first five years, the technology team, I mean, Heroku had its own CEO and it was reporting to the product organization. So, the Heroku engineering organization was totally separate than the rest of the sales force and our engineering organization. And what we’ve seen is that when they did other acquisitions, that changed. You know, in some acquisitions, the technology organization is trying to be merged, you know. And this is where you kind of get these processes because you need to.. As if you’re independent, you can have these processes going on here and these processes going on over that place. And that’s fine. I mean, unless you need to align roadmaps, there will be friction, but those are the frictions you need to deal with. Whereas, if you’re acquiring the technology, then the first thing that we’ll do, or the talent, it’s kind of, we don’t care about how you’re working. Usually, the way it goes is that they will kind of say, “Here’s how we work, and you need to align with that.” Sure, we’re open.

And then, there’s a challenge of how we can influence the culture as per the acquisition, because you have good things. And there’s a size, you know, so it’s usually the smaller ones to influence the bigger one, but that’s very hard. And it will really depend on how you’re able to hook in into the process, build the relationships, all of these things.

So, even though all the problems will happen at some point, the schedule on which they will happen, these integrations will differ based on the integration type because the first thing they do when it’s a product, you know, at the acquisition, usually you can expect like they will merge the sales team rapidly. And in Heroku’s case, that took a while. But in other acquisitions, first thing, it didn’t take long. That the sales team at that exact target or the sales team, the go-to-market of Tableau were integrated in the go-to-market, the general go-to-market because you want to go to the customer with a unified product offering, even if the tech, I think the customer experience is we’re using two different products here. You know.

Kovid Batra: Right. Coming back to Mirek’s challenge after the acquisition. Having the capacity utilization done properly. Is that something that you have also experienced and is there anything specific that you have done at that point of time? Because I can also feel this that as soon as an acquisition is done, there is a lot of context to gain. There are a lot of things for people to first get on board with and then see how teams can be utilized at every level. And the operating style of every company that comes in would be different, right? So, there are multiple areas where you need to first get yourself onboarded after that position and then, ensure that everyone is utilized in the right place. So, Francis, a question for you. Have you experienced such a thing? And how did you navigate that situation?

Francis Lacoste: Yeah, I mean, Heroku’s, acquisition was kind of special in that case, you know, because these questions really took years to materialize. So, Heroku Engineering and Heroku Product were split, you know. And then, Engineering went into to report into the general Engineering org and same thing with Product. And then, these questions started to happen.

And then, there’s these things. Okay, well, is that capacity here? Can we use it for something else? You know, again, do we want, this is less prioritized and the challenge there was kind of often there’s not a lot of knowledge or you have to explain how your product and your technology fit together. And you have to understand how you need really to dive into the understanding of each part.

Kovid Batra: Yeah.

Francis Lacoste: And especially in a big organization, the decisions are made without really the details of the context. So they will say, “Oh, we can cut that.” You know? Or, we were going to ask them, but then it has a huge impact on the product because it’s..

Kovid Batra: It is not looking into deeply. Yeah.

Francis Lacoste: This is critical infrastructure. I mean, it doesn’t seem to be much, but if we don’t develop this, then we’re going to have problems or these things are going to have problems, things like that, dependency. And at the same time, there’s often, like not a lot of understanding of the other side of what it is trying to achieve. So, the advice I would give is really understand, if you’re being acquired, you need to understand very rapidly what the business of the acquirer is, you know, the company making the acquisition, how the tech fits. And now, you fit into that because you cannot really rely on them understanding what’s going on, you know.

Kovid Batra: Exactly.

Francis Lacoste: So, you need to understand them so that you can make your case to them, you know, in the terms that they understand.

Kovid Batra: Right. Right. Mirek, for you, after the acquisition, you were heading the engineering team there. When you moved here, the developers, the team members who were working with you, did they have an expectation from you, or were they looking up to you to sort their lives into this new space? And what exactly you did, like, I want to know, like your first-hand experience there, like what exactly did you do to solve these problems of them and for them and help them get on track or maybe you’re getting them on track right now, I don’t know, just share that experience with us.

Miroslaw Stanek: Yes. So, one of the biggest challenges for me as a, you know, not the senior manager, like I said, just the mid-level manager, is that I got a lot of questions with the expectations that I could answer all of them which obviously, wasn’t true. So, obviously, when the company is acquired, I assume that on the strategic level, you have a product. So, this new management thinks about how to use this product in their strategy. You have pool of talents. So, they think about how to use, utilize those talents. And they think like long-term. My role was bridging this gap between those strategic decisions which were still, you know, in discussions basically. My work was to bridge that with leaders and the engineers, to translate that into their, basically day-to-day you know, activities. It’s very similar to the things which you do as a fresh manager in a company, yeah? So, what you’d need to do in the first 100 days, for example, yeah? So, I assume that you need to learn as much as possible about business or the product. You need to understand what are the problems of the company that you need to solve. And then, looking at your team, at the individuals, you need to find the best fit for their skills in the scope of problems that the company has. Like I said at the beginning, we are joining the company with some experience, with a track record, but, you know, we need to somehow build this credibility because this is just the potential and we need to find a way to utilize this potential, how to start providing the value.

So, basically, my 100 days were full of 1-on-1s with people in all of the positions, from software engineers to their managers, to the directors, to also product people, marketing people, data people and others, to build context. For example, one of the projects which I led at the very beginning post-acquisition was building front-end infrastructure because we realized that with the monolithic system which we had back then, we couldn’t move as fast as possible. And actually, this was one of the, you know, know-how which we brought to the organization because we did some kind of that stuff in the past. So, you know, next to those big strategic things, the product and the entire talent pool, we also brought some, you know, very specific experiences. And actually, there was a problem in the company which we could solve with that.

One and a half year later, I can say that our entire front-end application is built on top of micro front-ends. We have tens of those compared to the single one, one year ago. So, this went well. But, like I said, it had to start with understanding that this is the real problem of the company and we have resources, we have experience, we have people who can address just that. So, this was one of the two experiences I had at the beginning of the acquisition.

Kovid Batra: Perfect. I think, great job there, first of all. And, one thing that I feel is that when you have traveled this journey, there is always some looking back and saying, “Okay, I could have done this better.” Right? So is there anything of that sort, Mirek, which you think you could share as an experience with the audience that this is something that you could do better? Like broadly, I feel you did the best thing. And as Francis also said, first you have to understand the business, understand the need. That’s the very fundamental. And you got to that point rightly, having 1-on-1s and aligning the teams, bridging that gap, bringing everyone on board, right? So, this is amazing. But if there was anything else that you could have done, and whatever you did, if you could do it better in some or the other way.

Miroslaw Stanek: I think that one of the super-important things which I underestimated at the beginning is the quick merger of the, I would say, companies’ culture. So, as long as you have ‘us’ and ‘them’, and we work this way and they work that way, it’s super hard to navigate, yeah? So, you know, the truth is that usually bigger organizations that are more bureaucratic, more formalized are acquiring smaller organizations that usually move faster. But also, you know, they are moving faster and breaking.

Kovid Batra: Yeah. Yeah. Yeah, there are pros and cons.

Miroslaw Stanek: Yeah. So, I think that those are the, you know, non-technical challenges that you should address from day one to bridge this gap, to stop talking ‘us’ versus ‘them’, to see how quickly we can become one organization focused on a single goal because rather than, you know, expecting the company to adjust to us, we need to find a way to influence, to bring our experience, to help change the culture which works for all of us, rather than saying, “Okay, we work this way. And then, now the new way is not that effective. So I cannot, you know, push anymore once a day because of this or that or that.” So, I think that my role as a leader would be to answer all of those questions. Why we cannot push as fast as we did in the past? Why we have more compliance rules? Why this or that? I think that this is the thing that I should do more at the beginning of that position. Just provide all of the needed context to the former team or the organization to help them become, you know, good, empowered employees of the new organization. This is it.

Francis Lacoste: I agree completely with what Mirek said, you know. I mean, and this is similar to what we would have done differently. I think for us, it took really, too long. We stayed like ‘us’ with ‘them’ for way too long. And I mean, it was still going on, you know, when I left Heroku. In my last year, it was kind of, this was what I was trying to get to the team. It was, we were looking, we don’t know what is Heroku’s mission. And I was kind of, look, we get briefed every year at the company kickoff, which is this big event that sells for us where we have the strategy of the year, you know, and we want to know what our business is. We need to listen to that and tell how we fit into that, where, what is our contribution. Salesforce is in the business of digital transformation. How do we help customers with their digital transformation? And they were cool as a big part to play with, like at development there, but the ‘us’ and ‘them’ is strong. And this is where I said at the beginning, you know, it’s an identity problem. And there’s kind of a, the acquisition, the fact that you’re successful because you’re, you know, you’re at an exit. Especially the funders are having a dip there. Usually you’re bought, you know, I mean, even if it’s not for the valuation you were expecting, you’re still, “Oh! We’re a big deal. We got acquired.” You know? And at that time, like I said, I wasn’t there at the acquisition, but when Salesforce had acquired Heroku, it was a big deal. I mean, in Acre News and all sorts of that, people were saying, “Oh, Heroku is acquired by Salesforce because it required a lot of creds.” And I’ve seen other acquisitions where there’s some sense of pride and arrogance as being the smaller being and, “We are a startup”. “We’re nimble”. We’re really, I mean, “We have traction.” “This is why we got acquired, so they should listen to us.” “We know a lot. They don’t.” You know? So, there’s some arrogance and pride there. But the truth is, you know, especially, the bigger the differential, we need to get some humility and really start to get interested around, okay, why is there this? Because bureaucracy, it’s, I mean, it’s funny. When I was thinking, well, Mirek, you know, usually what is appreciated by the startups is the HR policies of the bigger corporations because they have more formal, you know, they have better insurance, health insurance, all that. That’s usually, “Oh, this is great!” But then it says, “Okay, this is how you should deploy to production.” Because there’s compliance issues and usually the bigger one will have to deal with this. Oh no! So, we need, as startups entering this world to kind of really get the humility of, “Okay, we probably have something to learn from them and it’s on us to tell, to understand what are the pain points and how we can solve it, probably.”

I loved Mirek’s story around the front-end development. It’s a great example. There was a thing and this is how we can solve it. I mean, Heroku was not successful in that way. You know, I mean, we kind of knew how to do deployments and all of that, but we were not really able to solve the deployment problem for Salesforce as a whole, you know. And so, Salesforce created its own Heroku, you know. And because Heroku, we were not interested. So, the arrogance is at the leadership level. So, you need to be able to jump shit and.. That was ‘ship’, I’m a little sorry. You need to jump shit in a way and embrace the new culture because otherwise you become like very protective of what you have and that’s, I mean, down the line, it’s not good. I mean, you see it, usually people will stick for their golden end, their leaders stick for their golden handcuffs and then they leave, you know, because they were not able really to integrate and find the value in that. And the people who stayed are kind of miserable. So it’s, yeah.

Kovid Batra: Totally, totally. One thing you just mentioned around, like how that cultural difference plays a role at different aspects of how you are operating. So, it could be something related to the hierarchy. People moving from a team which is small to a large organization would be happy about the HR policies, as you just mentioned. So, I have had an experience of working with an MNC and I have had an experience of working with a startup, right? The problem is that everyone, even the MNCs want or a large-scale organization wants that the team should move faster, right? Of course, without breaking things. And startups usually move faster, even though they break things, but they move faster. So, when this cultural shift happens, a startup gets acquired by a large-scale organization, keeping the team motivated that has been, like working with such a good pace and releasing features, having that clarity on what they are doing, seeing that impact, how does that transition work? Like I need to understand some detail around that part, maybe. Francis, Mirek, any one of you can answer that, like how do you keep your teams motivated with the fact that, okay, now we were running at 100, it’s going to be 50 now, right? That things could slow down for us, and still you need to keep them motivated on that journey. How would you do that?

Miroslaw Stanek: So, from my experience during the acquisition, as an individual contributor, you either join the existing team. So, this is basically like you would be hired to this company. Or the other way is you stay as the entire team, as the entire entity, and you build your stuff and your job is only to expose an interface or any ways of integrating your stuff with the rest of the product, with the rest of the business. I think that the second scenario is easier because you can still build things in your way. You can still have your, you know, ceremonies, ways of working. Sometimes you even keep the entire, you know, SDLC process or the tech stack. This is nice, you are just taking care of exposing the API or the contract or whatever.

When you join the team as an individual, I think it’s a good exercise for the company which acquires to see how their onboarding processes worked for this particular person. So, I personally look at the things of.. How quickly you can commit to production? For example. How much you need to learn? Do you have those materials which you can learn from? And then, how can you utilize them to push even a one line change to production? If you touch the production, it’s a success because you went the entire way and then you can start generating the real value and expand.

Yeah. So, I personally assume that the best motivation to people is to give them the possibility to generate value. And like I said, those are two ways of, I would say, maximizing that, yeah? And this is basically my experience from the last one and a half years.

Kovid Batra: Totally. Totally makes sense. Yeah. Yeah. What’s your take on this, Francis?

Francis Lacoste: Yeah. I mean, I agree here again, you know. The choice between the two will depend. It’s not necessarily in your hands, unfortunately. You know, I mean, if you’re able to maintain autonomy, it will depend more on the context of the acquisition or if it’s like, “We want to keep this product.” And so, they won’t refactor the teams or they will try to maintain the team’s autonomy, at least for a while so that the product can continue to grow and develop, you know. If it’s, like more technical or a hiring acquisition, then you cannot really expect autonomy. And then leveraging the onboarding process and that. And it’s hard because I mean, you’re really changing things for folks. And the trick is that even with the autonomy, there’s a clock ticking. You might not be aware of it because there’s autonomy, but autonomy is, as always, an expiration date, you know? At Heroku, it was like a lot of years. For most of other acquisitions, usually it’s more like a year, 18 months, 6 months, you know, and then, there will be, you’re on a timeline. And what is tough there as a leader is that you’re expecting to continue building the product as you are and you’re expecting implicitly or explicitly to integrate with the rest of the engineering org. You want to get ahead of it. Even if it’s, like just in six months or a year, you want to start building the relationships to.. How is it that you’re doing planning? How is it that you’re pushing to production? What is the integration aspect? And while at the same time, keeping your team autonomous. But you want to initiate these relationships. Get ahead. I mean, this is what I would have liked to do.

Kovid Batra: Yeah, yeah. I understand. And I think it’s good actually. See, setting the expectations brings a lot of more certainty to the situation and people get prepared for it. So, it definitely makes sense. First is that you give them that positive side of being there, keep them motivated and set the expectations right for the future so that they are prepared for it. So, I think that’s one good way of moving around like that.

Francis Lacoste: There’s something I want to add, you know, because I think I didn’t feel I really answered your question, initial question, which was about how we maintain the speed and agility, you know, of the original context. And this is the truth there, unfortunately, is that to maintain speed, you need autonomy. If you’re trying to centralize everything, this is when you centralize decision making, that things get slow and you get bogged down in, like, all of the coordination processes to make a decision. And this is what’s plaguing larger organizations. And so, there is an organizational philosophy at management. So, there is an uphill battle there because larger organizations that can move fast will add a lot of autonomy to the decentralized decision making. And that’s not really what is, like the common thinking in larger organization management. So, this is why it’s often unsuccessful. If you add up like the centralized decision making and the centralized process, you end up with these slow things. And that’s just the nature of it, you know, kind of. So, that’s the challenge.

Kovid Batra: Yeah, looking at the bright side would be the only option, like looking at the HR policies.

Francis Lacoste: And I mean, there are various.. The trick, and this is why I insist on relationship building because I mean, especially the larger organizations, the more they are, you can build some autonomy. Even though officially, there’s only a single way to do it, in practice, there will be multiple ways because of the history of acquisition and all of that. So, you can, if you know this, if you have the relationships when you did your training, your inventory of the lay of the land, then you know, okay, well, I can gain more time here and help steer that part of the organization into something that is more sane, you know. So, you can influence the culture, but you’re not going to transform it, you know, six months here. It’s like you’re starting a journey to nudge a little bit, the larger organization to work as a saner practice. We saw that at Heroku, especially around remote work. When I joined, it was to build a remote culture there. And when the pandemic hit, at Salesforce, the larger Salesforce organization, there was a lot of interest. Oh, what can we learn from Heroku? They’ve done that. So, our experience was welcomed and we were able to shift things, you know, in that area around remote work a little bit like Mirek was able to do around, like the front-end development. So, this is why understanding what the pain points are where we can contribute can help these micro-shifts.

Kovid Batra: Yeah, yeah. Makes sense. All right, moving on to one last piece of our discussion today around the acquisitions. This is a time of transition, turmoil, leaders themselves are figuring out that space, that foot into the new organization and trying to set up things with the existing team and the upcoming team. At this time, how do you think you can look at the efficiency of an engineering team? How can you go about measuring it? Or maybe, you should not measure it because there could be other aspects to look at at that point of time. How do you ensure that the people who are getting paid are delivering the value in that moment of transition? And how do you ensure that people are efficient?

Miroslaw Stanek: So, from my perspective, I take into consideration those four stages of team development, yeah? So, we have forming, storming, norming, and performing. And I assume that if the company is acquired, it’s major enough, fast-moving enough. So, I assume they are close to the ‘performing’ stage, yeah, where you measure the efficiency, speed, you can implement DORA metrics, you know, measure the number of deployments, whatever. But when you are acquired, I assume that you are coming back to the forming phase. So yeah, obviously, if you stay as a single team, single entity, you still can move really, really fast. You can keep deploying your stuff, you know, every single day to production. We are moving fast, but the question is if we are moving in the right direction, yeah? So, that’s why you can still keep measuring those things.

But I think that at the beginning, you know, of ‘forming’, you need to get to know people, company, business and everything. So, you understand how you can contribute to the company’s success rather than just moving fast in a totally random direction. So, I would come back to my answers from a few minutes ago. I would measure the onboarding time, basic stuff, how quickly you can, you know, come into production because, you know, you need to get access to your repositories, you need to go through all of the documentations and stuff like that. In the meantime, you know, just learning the company, learning the teams, your, you know, colleagues and everything. Then obviously, you will go to the ‘storming’ phase where everyone is debating on the ways of working and why we don’t work this way, but that way and so on. But, you know, after this turbulent time, then you can come back to the performing phase where you are optimizing, but only when you know that you are going in the right direction.

Kovid Batra: Makes sense. Perfect. Perfect. What’s your take on this, Francis?

Francis Lacoste: Well, what I’d add, again, it depends, you know. It’s really understanding how the acquiring organization answers that question because they probably already have a framework of how they’re thinking about performance, how they’re doing performance management, for instance. That’s also one of the usual sources of friction. We like the HR process, but not necessarily the performance, the way they do performance management, you know, because they have a very formalized one. Our smaller organization was always smaller. So in a way it’s kind of understanding how these questions are framed and processed at the bigger level. And then seeing, okay, how is that compatible with us? How are we going to need to adjust? And if you’re already doing that, you know, so that, because that will be an impedance mismatch that will need to be negotiated. And if you want to negotiate it, you’ll have to get ahead of it because otherwise the expectation will, you’ll just use ours.

Kovid Batra: Yeah, yeah.

Francis Lacoste: That’s very tough. The other around that question often it will be removing duplication. You know, it’s not so much, it’s everybody is busy because I mean, everybody’s busy in our company. Now, the question, like Mirek said, is kind of, “Are they busy on the right stuff?” And this is where I always recommend looking more for output, you know, what the outcomes are. I mean, not output, actually outcomes more than, like the busyness, you know, or our people’s time sheets or, you know, that, you know, oh, the number of pull requests or number of lines of code or all of these metrics which are kind of irrelevant in many ways.

But really, how is the business? Are we meeting our business outcomes? Giving transparency on how we’re making progress on those so that they can have conversations. But often, what happens is more kind of, you have a Platform Engineering team in your startup and we have a Platform Engineering, so we’re just going to merge those, you know, because obviously you should not have two Platform Engineering teams. I mean, that’s kind of naive, but it’s also a source of multiple confusion. But this is also a conversation you need to have, they’re going to come. So, you want to say, “Okay, what is this Platform Engineering team doing?” “What is their charter?” “How is it compatible with ours (or not)?” “Is merging really the right thing?” So, getting these collaborations going between peers at the startup and the bigger. If the teams have talked and have kind of an idea, when the Execs come in and say that you need to merge, you can actually say, “Well, actually, this is how we think we should be doing it.” And then, it’s much easier because the people with the maximum understanding of the context of the deals are able to weigh in on the decision.

Kovid Batra: Yeah. So here, let’s take your example here, Francis, when Heroku merged into Salesforce, there must be certain performance practices you would have already taken up, right? And then, there must be something that Salesforce enforces on the team, right? There must be some clashes over there. Can you give us an example of that? And how did you, as a leader, navigate your team and align them with that? So, it completely changes the way you are thinking, how you’re incentivized to do something in a team, right? And if that happens, it’s a big shift, according to me. How you handle that would be something that I would like to know.

Francis Lacoste: Yeah. I mean, two examples of that were, like the performance management, which I mean, Salesforce didn’t have a very formal one at the beginning. It came in later. But it required this one. The way they do promotions and things like that. So it’s kind of, okay, we need to align more with that. And it was about understanding this process & understanding how we do things. And then, there’s a phase where it’s about how we can continue to keep the spirit and the principles we have in that different process and hybridize the two. Another one was the career ladders. So, we had our own career ladders. And then, there’s kind of the, okay, well, these are the different roles. Harmonizing that. Often, I mean, the biggest job was managing expectations on both sides. Basically what we had was like an interpretation. This is that level. Here’s what that level means here. And you were seeing that even though officially, that’s kind of, you should not be doing that. I mean, the HR folks really hate that. But in practice, contexts are different and you need to have that adaptation. So, even though it was not recognized, it was happening all over the organization. It’s not like just a group who were doing that, but other teams also when they’re, kind of doing commentary on the official career ladder.

Kovid Batra: Yeah, of course. That’s there. Great, guys. I am out of my questions for now. It was lovely discussing all these challenges with you and having a discussion on all those practical tips that you shared. Any parting advice from both of you for the engineering leaders who are in a similar situation, what they should be doing, what they should be taking as next steps?

Miroslaw Stanek: So, from my perspective, I would say that your role as a leader is to find a good match between the skills you are bringing to the new company. You know, your team, the know-how the solutions, the product, to the problems which the new company has. And start, you know, start by doing that. Start by showing what’s the value of your stuff in the context of a new reality. And the quicker you sort it out, the quicker you become, you know, successful in a new organization.

Francis Lacoste: That’s a very good tip. So, two things for me. The first, most practical one is get the conversation going, you know, look at the org chart and find people who are in similar roles or where you can see that oh, if I were to look at this and it looks similar and I want to merge these things, start talking with those teams to get your team to actually start talking to these teams, just to get to know each other, to learn from each other, that sort of thing. Very informal kind of thing. It is just to encourage cross-organization conversations because that makes everything easier afterwards. You get to know people, you get to relate to them as humans. They’re not like a dam who wants to eat you or things like that. So, just encourage, multilateral conversation between similar roles and similar teams, between engineers, well, across the org. So, conversations. Then, same thing with the leader.

The other aspect that I say is kind of, keep in mind that there’s an identity shift that needs to happen, you know, from “we are this company” to “we are this bigger company”. The mission is changing, that sort of thing. And when there is an identity shift, there will be a grieving process, you know, because you’re losing an identity and you’re embracing a new one. So, be prepared to accompany the people in that journey, you know, of kind of losing the, “Oh, this is how we were.” And, “This is our startup times.” And things like that. The loss of that, because it’s a real loss, it will be an emotional impact. And then, so kind of acknowledging it and normalizing it, supporting people through it and embracing, helping them to embrace the bigger identity, “Hey, this is the new mission. This is bigger. We can do more things together.”

Kovid Batra: Totally. I think both of you, thanks a lot for such great piece of advice. Can’t thank you enough. Let’s keep this passion of contributing to the community going and let’s build great dev teams together, man.

Francis Lacoste: Thank you so much, Kovid, for providing this space.

Kovid Batra: Thanks.

Miroslaw Stanek: Thank you.

'Building Teams from Scratch vs Branching' with Lubo Drobny, Software Engineering Coach at Cisco

In the recent episode of groCTO Originals (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Lubo Drobny, Software Engineering Coach at Cisco. With an impressive professional background at Seimens & SAP Labs, Lubo also actively contributes to the tech community through blogging, hosting podcasts, and organizing meetups centred around product and software engineering topics. Their discussion revolves around ‘Building teams from scratch vs branching’.

The episode begins with Lubo sharing his love for programming, hiking & gardening. He also gets into the details of a life-defining moment in his career that shaped his current coaching style.

Moving on to Lubo’s career progression, we get a glimpse of his journey from Slido to its acquisition by Cisco, highlighting the key differences between a startup & a corporation. He also shares strategies for team building through hiring, onboarding & training while focusing on delivery.

Lastly, Lubo highlights the key engineering metrics for assessing team excellence and their impact on delivery and quality, while underscoring the importance of prioritization.

Time Stamps

  • (0:06): Lubo’s background
  • (0:41): Lubo’s hobbies & life-defining moments
  • (5:56): Journey from Slido to Cisco
  • (11:15): Balancing hiring, training & delivery while scaling up
  • (15:18): Branching strategy for building teams
  • (17:05): Working at Slido vs Cisco
  • (21:41): How to evaluate tech excellence?
  • (25:42): Finding the root cause of inefficiency in teams
  • (28:47): Conclusion

Links and Mentions

Episode Transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who loves to organize meetups with product and with tech fellows. He loves to organize engineering podcasts. He has 16 years of engineering and leadership experience. Currently, he’s serving as a senior engineering leader at Cisco. Welcome to the show, Lubo. Great to have you here.

Lubo Drobny: Hi! Hi, everyone. Thank you for having me. I hope you will enjoy this episode.

Kovid Batra: Of course, we will. And I’m sure you would have a lot of things to share from your journey at your startup and acquisition by Cisco. So, we’ll definitely enjoy this. But before we get started on that part, we would love to know you a little more. So, if you’re comfortable, can you just tell us about your hobbies? What do you like? Some life-defining moments for you? That would be great.

Lubo Drobny: Yeah, perfect. When we’re talking about my hobbies, I would say that my first hobby, uh, programming, I think this is not a surprise. This was probably also kind of a life-changing moment. So I was just 11-12, teenager and I got my first computer at that time. It was an 8-bit Atari XL and I fell in love with this machine, not for games, but for the, let’s say, the possibility of creating new stuff, programming stuff and so on and so on. This was a very important moment for me.

But another one, it was, um, I would say, and a life-changing moment probably was when I was at a Swiss company, RSD, and my boss was a very good mentor. So this is something I probably never felt before, or didn’t have the experience when your manager or your leader is also a great mentor and helping you to grow. And this was very, very eye-opening for me. And it worked well.

And then about my hobbies, um, I like hiking. Uh, usually in Slovakia, we have nice mountains, but also around Europe, for example, Italy, the one, it’s Austria, uh, very nice mountains. Uh, I like gardening. So, this is also connecting to nature. And I like to play in my small garden. And I’m a proud father of three kids. It’s not a hobby, but something which defines me.

Kovid Batra: That’s great. Thanks a lot for sharing that. And you mentioned that your mentor, your boss at one of your companies was a really, really good leader and he guided you well. Can you tell us more about that experience of yours?

Lubo Drobny: Yeah. Uh, it was I think about 10 years ago or 12, I don’t remember exactly. And I was switching my role from technical developer to manager or engineering leader, and what needs to be said, it is a different role. It is not like evolution. So we go step-by-step. It is kind of a different role to lead the people, manage the people. Uh, it’s different than coding because computers do what you want, but people are very different. And for me, it was very important to tell him that okay, I’m kind of new to this. I would need help because otherwise, it could be a disaster. And he was very open and he, what was important was that he discussed a lot with me what he plans to do, he asked me a lot of questions, how I would approach those problems, what needs to be done, but he also really comforted me, okay, well, this is good, done. And he helped me to have focus on important stuff because at the beginning you cannot keep all balls in the air. When you are juggling, some of them could fall, but he always, we talked about it and he always told me, “Okay, this is not important. Don’t focus on it. It’s okay. You are doing good. It could be better, but we need to.” So, he was very encouraging. And this is a kind of quality. Usually, a lot of people kind of only criticize. But he was also very encouraging, very helpful always for me. So this was a very nice experience. And I think it really helped me to survive and grow as an engineering leader. Probably without him, I would, I would go back to coding and engineering.

Kovid Batra: I think that that’s a really great example. And when you, when you find someone at that stage of your life when you’re actually growing or making such transitions and somebody guides you well, you’re tend to actually learn from them, that trade and you yourself try to implement it. So I’m sure that today your team members who are looking up to you as a leader, are sharing the same emotion and feeling.

Lubo Drobny: I hope so because I think I copied kind of this coaching or mentoring style of management. So I’m, I’m not very direct. With my team, I usually talk to them trying to find, uh, the answers, the questions. So I’m not bringing the solution upfront, I’m trying to help them to find it. And I try also to coach them or mentor people around me to grow, not only as a team but also grow, uh, as persons. So it’s very important for me because if you have good people on the bus, uh, it’s, it’s a perfect setup.

Kovid Batra: Yeah, right. Absolutely. Great, Lubo, I think it’s a really great start. And talking about compassionate leadership, empathetic leadership, I think is very important these days. So let’s, let’s get started. Let’s look into more of your journey as a tech person, as a tech leader. Your stint at Slido was quite long. You spent almost six years scaling that startup from zero to one, and then this acquisition also happened. And then, you moved to Cisco. So this journey is quite interesting, at least from the outside. You tell us about your role at different points of time and how, how you took the team from zero to 50 members. And then, how did this acquisition happen where now, you are serving at Cisco as an Engineering Leader, how have things changed for you from Slido to here? I think it’s a big question to answer. You can take your time and let us know some interesting facts from the story.

Lubo Drobny: Yeah. So I hope that it will also be interesting for the audience. But in general, I joined Slido, I think seven years ago. Uh, at that time, it was a promising Slovak startup and there were around 40 people. But only five, uh, developers and two students. But at the time it was like, yeah, this could be interesting because they started to make some profit and the Slido application, if you don’t know, it’s about engagement in meetings and conferences. So, it’s a polling and questions and answers tool. So the presenter can communicate with the audience. The presenter can see the questions online. It’s soft real-time or can poll again in a soft real-time manner, uh, audience and see results and so on and so on. And looks that, uh, this is an interesting niche at the time and it could, it could grow and also the leader or CEO at the time, but the company decided that, yeah, this is a good time to scale the team and try to push more on, uh, also on engineering.

And my role since then has been the same. So, build world-class engineering and world-class products. So this was kind of the mission from the beginning. It’s kind of cliche, of course, but, this is usually the mission of everyone at a startup. You would like to build something great. But, to build something great, you need very good or great people. So as I said, it’s very important who is on the bus with you. And, so my first, of course, my first role was to start hiring and put together, let’s say, a solid process. And there were two levels to this. So, um, once it was, let’s say, kind of short-term, so find the gaps in the team, double the positions, so we are, we are strong and double the team, um, kind of in short time. But on the other hand, also think on, let’s say, mid or so, a long-time period. But we discussed that we should also build some awareness in the engineering community that, uh, we are good because otherwise nobody knows. So, um, I was focusing with the HR team on typical hiring. So, looking for the people, prepare the process, stages and all the stuff. But also we worked on some, let’s say, ‘engineering marketing’ or ‘advocacy’, how we call it. So we started to write some blogs. And we started to be more visible on meetups. Uh, lately we’ve started to organize meetups. So today, I’m helping to organize the product meetups in Bratislava, engineering, uh, meetups here in Bratislava. Uh, we started to be visible at conferences because we believe that it’s important in the long-term also to increase the awareness that we are here and we would like to build a great team. So, this was at the beginning.

Uh, then the next challenge, I would say, was finding a good structure for our teams and deciding how we would like to work. What we put together also with product leads, is that we would like to have small teams because they are, um, in our point of view, most effective for what we need. So, up to 8-10 people, not bigger. And we would like to have cross-functional teams. So, product parts, we call them ‘discovery’. So, it’s Product Manager, Designer, later also, User Researcher. And then, a ‘delivery’ part, which is the Tech Lead, engineers, front-end, back-end, and a tester. So it’s, it’s kind of a typical setup, but we’re experimenting, uh, let’s say, with the size of the team, with the roles. But in the end, we found out that this is probably the best template for us, how to create a team with it. Of course, few mistakes. Maybe the big mistake was, for example, starting the new teams from scratch because usually, we lost the culture thing. And so, therefore, we decided that it’s better, for example, to start the new team by splitting from the older one, which worked better.

Kovid Batra: Sorry to interrupt here. I have a question. You had this great strategy of, um, hiring the right folks by creating that awareness. So you started this community aspect, right? So, from there to hiring more people, you were like, it seems that at that stage, hiring becomes the highest priority, right? You want to scale, you want to grow and everything is going on. At that moment, when you are hiring, new people are coming in, the time period of onboarding somebody easily, like if we talk broadly, it takes 8 to 10 months for somebody to actually show you something productive coming out because the person would come in, gain the context and then get familiar with the things that are going around. So then, at least it takes eight months for somebody to come out and deliver something. And in a stage where you are fast-growing, how did you manage to deliver alongside hiring such folks and training them faster if you are doing that?

Lubo Drobny: I understand the question. The first point was that, uh, we were focusing on experienced people. So let’s say, seniors because usually they are able to be onboarded faster. So..

Kovid Batra: Yeah.

Lubo Drobny: So, for example, in my experience, how we did it, uh, when someone senior joins the team, the first month, okay, setting up everything. But we are in a startup. We don’t need a lot of permissions. So it’s very quick. This is your laptop and accessories. Uh, then we have, I think one or two weeks in general onboarding to the product, uh, to the company, everything. And then, after one month, I was like, “Okay, guys, what I expect is that you will do the first small release to the production.” Because we are a web application, we can release very quickly. We are using a common tech stack for the web, it’s TypeScript, Node.js, React, or Angular. And when we hire people who are proficient in those technologies, that is great. And we are not using some internal special frameworks or something, you know, you need to figure out how it works. And also we have very, very light processes. So, even when we hire, for example, a Java Engineer, after three months, they will be ready to code, ship, and deliver. So..

Kovid Batra: Oh, that’s great.

Lubo Drobny: But the best guys, in one month, they did the first release. So it was very quick, but we were focused on seniors. Then there was a question, okay, uh, what about the juniors? Because it’s, you can’t hire only, only them (seniors).

Kovid Batra: Right.

Lubo Drobny: And, what would I really like? We started the internship program which remains. And so, we decided to do a three-month summer internship for full-time and paid internships. Usually, four or five people join. And then, if they decided to continue part-time, it was really great. We were focusing on university students, of course. And this was a very great way to find very, very good junior people who are on top level, I would say. So I can recommend the internship program also for, for others. It is working for us very well.

Kovid Batra: Yeah. I think hiring the expert folks, having your tech stack pretty common and simple and sorted, having the least number of processes, and having automation in the right places can really accelerate that process of onboarding. And hence, when you’re hiring someone who is good, you can get the productivity as fast as possible, right? So..

Lubo Drobny: Yeah.

Kovid Batra: That, that really worked well for you there. So, I think that’s a good piece of advice to keep such things in mind when we are proceeding to scale, at least at that point when you are navigating towards two different goals. One is, of course, bringing in people and then training them and hiring them. And at the same time, delivery. This could work out really well. And I think the point which you started that also seemed very interesting. Like you said, we thought of not hiring people and putting them into new teams, we just branched out, uh, new teams from the existing teams itself. So, this seems to be a very interesting strategy. I think you could just continue on that. So, I’d love to hear more.

Lubo Drobny: Yeah. Because what we, what I, or what we realized, when we started teams from scratch, they came with some culture or habits from previous companies and they started to replicate this thing because they didn’t have, uh, let’s say experience from our teams, our culture and the way we work. And in the end, we realized that this is not the, this is not the best. And maybe it is more clever to, for example, we have a good team, we can hire a little bit more people there, and then, turn around and split them. It’s also easier, also for the team and to keep the culture this way if you already work in a good team and you understand how we work, what are the habits, what are the things, what is important for us, you can easily continue. So, uh, this is the, let’s say, mechanics, how it, how it works for us. I think it’s, it’s better, at least in our practice.

Kovid Batra: Definitely.

Lubo Drobny: But, of course, sometimes you need to start from scratch if you do not have, let’s say, the skills, technology, or you started with something really new, so you cannot pick it for everything. But let’s say, if you would like to have the new team with the same tech stack and the same culture, this is the better way from my point of view.

Kovid Batra: Definitely. Even I agree with that point. All right. I think, apart from this, when you scaled up and, uh, I’m just going back to that piece where the company got acquired. The way you were operating at Slido and now, working as an engineering leader with Cisco. How have things changed? Like, give me some examples, like, okay, this is how we used to do here. And now, things have changed for the better or maybe for a little worse here.

Lubo Drobny: Yeah. Of course, something changed. The thing is that, uh, we joined a very big company, a corporation. And also, corporations focus on security, definitely. So, what definitely changed was that we had to implement more certifications around the ISO, 9000, 27000, and also, another American certification for software development, security and quality. This was kind of challenging for us because we didn’t want to sacrifice, let’s say, our way of work, but we had to change some processes, of course. But we didn’t want to slow down our, let’s say, release process and our possibility to be, to be fast. Um, therefore we had to implement a lot of automation and we had a lot of discussion with the experts in this certification, how to do it. It is compliant and it is okay from the security point of view or quality point of view. But we had to do some sacrifices, I would say. So, it is not the same as before. But on one side, we, are, uh, shipping more secure products, so it’s, it’s not bad.

Kovid Batra: Yeah. Yeah.

Lubo Drobny: On the other hand, we joined Cisco as a business unit. So, they didn’t change the way, how we are organized, how our teams work and Slido is still continuing like a standalone offer. So, also, the Slido brand still exists. Also, this is kind of different, so they didn’t swallow us, I would say, but we are still living as a Slido, which is kind of, kind of nice. And therefore, we are keeping some autonomy, which is good for us to some extent that we can continue working, you know, let’s say, the way we consider them the best force for Slido. On the other hand, as I mentioned, Cisco brought on to us more focus on security and quality, of course, because, um, this company requires high levels of that and more opportunities in, uh, let’s say, integration. Integration way. So, we started with integration with Webex, of course.

Kovid Batra: Yeah. Yeah.

Lubo Drobny: This is a Cisco tool, but then we continued with the integrations with also other video tooling. But, in this cooperation, with Webex teams, gave us a lot of experience, how to do it right way and so on and so on. So, and of course, they gave us the opportunity to reach a broader audience, especially in an enterprise environment where usually the startups are not, let’s say, uh, preferred

Kovid Batra: Yeah, I know.

Lubo Drobny: Usually, corporations would like to buy tools which are strong with the maintenance and all that certification and all the stuff.

Kovid Batra: There is one more important thing that I just felt like asking. When you were building Slido and you were an independent company, the level of impact you would have felt that you’re creating with the product that you’re rolling out and then, integrating with a tool like Webex and then reaching out to like millions of users, right? So, that changes the overall feel of how you’re building it, how you’re doing it. So I think that that must have been a good experience.

Lubo Drobny: Yeah. This is, uh, this is definitely the positive thing that, uh, we were able to, to put Slido in the hands of the enterprise users, like the Webex or another integration. So this was definitely, definitely very positive. We were able to do it because otherwise, probably, we would not have gone in this direction, definitely.

Kovid Batra: Of course. I mean, even if you reach so many people, it would have taken a few years to reach there, right? So that’s, that’s a good jump there. Cool. I think that that’s interesting.

And now, the last piece that I just wanted to understand here. When you are operating with 50 developers with you, I am sure being, uh, an empathetic leader, you are trying to understand every aspect of your developer who is part of the team. But how do you exactly measure their overall excellence? How good they’re doing? How do you measure their work? How you measure their achievements is what I want to understand from you.

Lubo Drobny: Um-hm. So, what is most important for us is the product itself at the end and the value that we are bringing to our customers. So for example, if we build something in time, in high quality, very secure, but nobody’s using it, in the end, it is a failure even if we did a good engineering job. But if it is not working for our customers, we will scratch it or discard it or trim it on the part of the product. So, in the end, it’s, um, this cooperation with the product is very important for us because we are a product company. And also, my evaluation of what we are doing is connected with this, that at the end, when we’re doing and delivering something, we believe, of course, that Product did their jobs and they, they suggested a good feature or, or product to build. Uh, but this is still a very important part of, uh, let’s say, also evaluation of what we are doing in engineering. If in the end, what we built is used and it is built the way that people can use it. So in this case, the second important thing for us, it’s quality and usability, which reflects, for example, uh, net promoter score or statistics like this. So you can, uh, you, you want to measure that these deliver something, that it is a good idea from the product side, but it also on the other hand, it is delivered with good quality because we have experienced if there is some big bug, uh, in the product and our NPS is going down next week.

Kovid Batra: Yeah.

Lubo Drobny: It’s, it’s very connected, it’s, it’s very connected. And for us, it’s a, it’s a very important metric. So, it’s NPS. Then, of course, what we’re evaluating is, uh, the quality by measuring, for example, the total number of bugs or trends. So if we are able to keep it in the, let’s say, a reasonable level, so we have kind of a ‘zero medium +’ bugs policy. So, we are okay to have small hiccups in the product and we are, uh, we are okay with it. But we would like to fix, let’s say, medium, medium bugs as soon as possible. So, this is important for us. Then, uh, for us, is important, deployment pace, that our CI/CD and all this, our continuous integration, and release process is fast. So, there is no problem, that test automation is working well. So, we are measuring weekly deployment strength. And again, if we see that there are some problems or, uh, developers are complaining that something is taking too much or if the tests are unstable, we would like to very quickly fix it and address it, because this is very important for, let’s say, developers’ experience. If you have eight people, A-class people in the team, they just want to release it. They don’t want to wait. They don’t look for some..

Kovid Batra: Reviews or anything.

Lubo Drobny: ..Some excuses why they want to push it. And they want to see their work outside. So, this is very important for us.

Kovid Batra: I think this, this brings me to one important point. Like you said, you look at the bugs rate and, like you have this policy, like, as soon as there is a medium-severity bug out there, you have to resolve it as soon as possible. See, these things ultimately tell you that, okay, this is the problem, like this is a symptom kind of a thing, right? But at the end, when you have to drill down and understand what is the core, like is it a bad review process or is the initial code quality not good? Then how do you end up finding it? Uh, like, of course, you can go by the brute force method, but I’m just, uh, curious to know how you do it.

Lubo Drobny: For more, let’s say, some critical bugs or some high-severity bugs, uh, we are doing, um, postmortems. It’s usually a very interesting process. Uh, usually takes two, three weeks. So, if something happens, there is an owner of the postmortem. So, it is not about who is guilty or not. There is someone who is the owner, who is able to put it together. And it usually is investigated because, uh, you need to, you need to check the log files. You need to talk to people about what’s happening. You need to check the slight communication and you put together, let’s say some scenario, what happened before, what happened during the incident. And you would like to evaluate more things, how we reacted, if our reaction was good or it was slow, um, because maybe we could do revert or we could fix it. And, you know, there is a lot of, a lot of nuances. You can evaluate it during our reaction to this bug or to this problem. And then, of course, there are some five ‘whys’, this typical ‘why is this happening?’ and why, why, why, why. And you asking yourself more than five times to really find a good, to find the root cause of what really happened. And then, you would like to suggest a good, let’s say, some short-term fixes and maybe also some long-term, because you maybe need to just fix some code because there is a bug. But maybe also you need to fix the process or you need to fix some communication issues. You need to fix something else. Because sometimes, some problems happen. But, if you are able to react in seconds or minutes, It’s perfect from some point of view. If you can improve from, let’s say, reaction time in hours to minutes, it’s also a good deployment. This is what I want to say.

So for us, it’s also improvement, uh, important in this. Uh, time to detect the problem and, uh, time to fix, of course. And if we are able to increase those, uh, decrease, decrease those times to a minimum.

Kovid Batra: That makes sense. Perfect, perfect. Great, Lubo. Uh, this was really interesting. And, uh, when someone shares like these level of details, but with some examples, I think that’s the best part and I loved that while discussing this with you. So, I’d surely love to have another round of discussion with you on other topics related to the engineering channel sometime.

But today in the interest of time, I think we’ll have to call this short today and thanks a lot once again for giving us the time and sharing your learnings and experiences with the community.

Lubo Drobny: Okay. Thank you again for having me. I really enjoyed it. And I wish you the best.

Kovid Batra: Thank you so much. See you.

Lubo Drobny: Bye bye.

‘Leading with Empathy & Compassion’ with Jörg Godau, Chief Digital Officer at Doctorly

In the latest episode of the ‘groCTO: Originals’ podcast (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Jörg Godau, Chief Digital Officer at Doctorly and one of the founding members of The EL Club in Berlin, Germany. His vast experience includes valuable contributions to renowned companies such as VRR Consulting UG, Nortal, and IBM. The discussion revolves around ‘Leading with Empathy & Compassion’.

The episode kicks off with Jörg discussing his hobbies and life-defining events before delving into his role and daily challenges at Doctorly. He emphasizes leveraging user insights and business understanding for software development and aligning individual career aspirations with organizational needs during team scaling.

Furthermore, Jörg explores measuring engineering team success both qualitatively and quantitatively. Wrapping up, he shares his final thoughts on remote work.

Time stamps

  • (0:06): Jörg’s background
  • (0:45): Jörg’s hobbies & life-defining moments
  • (4:52): What is Doctorly?
  • (8:51): Adoption challenges for Doctorly
  • (10:57): Leveraging user & business insights when building products
  • (13:00): Biggest role challenges and their impact
  • (17:38): Aligning team goals with individual aspirations
  • (22:45): How to define success for an engineering team?
  • (25:06): DORA metrics for measuring teams’ visibility
  • (28:55): How to gauge developer experience?
  • (32:13): Final thoughts on remote working

Links and mentions

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest who is the founding member of the Engineering Leadership Club, Germany. This is a group of empathetic leaders who believe in supporting and mentoring other engineering leaders to lead with compassion. He has 20+ years of engineering and leadership experience himself. He’s currently working as a Chief Digital Officer at Doctorly. Welcome to the show, Jack. Great to have you here.

Jörg Godau: Thank you so much, Kovid. It’s great to be here. Just to be clear, one of the founding members, not the only founding, don’t want to take credit for everybody else’s great work as well.

Kovid Batra: All right. All right. My bad there. Perfect. So, Jack, I think before we get started and have a lot of things to learn from you, I would first want you to introduce yourself with some of your hobbies, some of your life-defining events, so that our audience knows you more.

Jörg Godau: Sure. Yeah, I can do that. And, my name is Jack, but actually, my name is Jörg. I was born in Germany, a long, long, long time ago, and then immigrated to Australia as a very small child, and I lived there for about 30 years. And the umlauts and the pronunciation were not possible. And, people in Australia don’t have umlauts. They don’t have it on the keyboard. It’s not compatible with the Australian way of saying things. So I gave up and said, right, “In English, just call me Jack.” Um, lived in Australia for almost 30 years. Got married there and then moved to Berlin for one year in 2006-2007. I plan to register at some point with the Guinness Book of Records for the world’s longest year, because I’m still here. And now I have, I have two kids, and live here happily with my wife and kids in Berlin since also a long time now, when I think about it.

As far as like hobbies, relaxation, I very much like going for hikes. So like long distance walks. So we’ve done the Camino, we’ve done the Tour de Mont Blanc, also with our children, both. And, this year we’re going to do the Fisherman’s Trail in the South of Portugal. So, and that’s two weeks where you like, we carry all of our stuff. So it forces me to not carry a laptop or other things. So I, in that time, I also can’t work. So it’s a, it’s a very good way to switch off and have a bit of digital detox.

Kovid Batra: Perfect, perfect. What about some of your life-defining moments? I mean, anything that defines who you are today.

Jörg Godau: I think I really like this move to Germany and this plan to like, you know, travel around Europe and do random things for a year. That was a big difference. Obviously as a parent, like having children, you know, every parent will tell you like children change things quite a lot. I think most recently, like probably actually joining Doctorly and having the chance to really almost build something from scratch in a startup environment and really like be able to very directly shape the organization and shape the way things move. These are all like, and they’re on different levels. No one is like.. Personal, travel, seeing the world, experiencing different cultures. One is more like the family life and the other is, is certainly the work life.

Kovid Batra: Great. I think, I totally relate to it. I personally love to travel. I though don’t have a kid right now, but I definitely feel so that it changes your life completely. So I totally relate to that.

Jörg Godau: Yeah. And for us to Australia, like my wife is also like, was also an immigrant to Australia. And, for us, Australia is very far away, right? Like, it’s far away physically. It’s far away in terms of its involvement with world politics. Like in Europe, like world politics is like two hours drive away is the next country, right? Like in Australia, two hours drive away, like that’s a trip to see your friends, right? It’s not like, it’s just not the same.

And also in terms of cultural access. Yes, like people go to Australia with art exhibitions and cultural exhibitions and concerts, but even for those people, it’s a lot of effort to go. So it’s less accessible. Right? In Europe, if you want to see anything, like cultural concerts, ballet, art, it like, there’s just so much here that it’s, I think actually impossible to see it all, which is a different approach.

Kovid Batra: Yeah, absolutely. I agree to that. Great, Jack. I think thanks a lot for sharing that with us. And now, moving on to our main section where we would love to learn a lot from you, but keeping the time in mind, let’s start with something very, very basic. Like you are currently working as a Chief Digital Officer at Doctorly. So, tell us what does Doctorly do, what is your role there and what are your daily challenges?

Jörg Godau: So, Doctorly’s vision is to enable people to live healthier lives. This sounds beautiful and like, you know, cloudy, but like, okay, how? And so, when the founders of Doctorly originally started the company, they looked at what are the real problems in healthcare and in Germany and probably in many other countries. So the problem, one of the problems is the communication and the digitalization of healthcare. In Germany, patients become data mules. You go to a doctor, they give you a piece of paper, you carry that piece of paper to somewhere else, they give you more paper, you carry it back, and you end up with like these massive folders of paper which you probably don’t understand and don’t want. If you lose it, they get very angry at you because you have, they have to print it again or something. So, this process is terrible. So we thought, okay, let’s build something for the patients to improve it. But you can’t because it’s not the patient’s job to put this data. The doctor has to put it and the doctor has to get it. At that point, we realized that the source of the issue and the core of the problem is doctors are confronted with very old-fashioned software. The software that doctors use in general in Germany today started to be built in the 90s, the 2000s. If you’ve been around for a while and you can recognize a Delphi application by how it looks, this is how they look. They look like Windows 95 Minesweeper. Gray bevels. Push the wrong button, it explodes, right? Like, it’s really, really bad. And they run it on computers in their office. So, backups, security, any of these topics, super, super challenging, right? Because like, while they do do backups, they never test the restore. If you don’t test the restore, you haven’t done a backup, right? Like, it’s like, so all of these things led us to start building the core Doctorly product, which is Practice Management software for German doctors, fully cloud-based. They don’t have to worry about anything. They get updates every night, like, they get, like, data backups. We do it. It runs on a professional data center, with professional people supporting the machines. And so, they just don’t have to care. So they can concentrate on the patient. But now already, the data is digital and the data is somewhere central. So we have the first step in being able to transfer the data. And in the next, in the next period of time, we’ll start also building the patient app and a platform and a marketplace so that the patients get control of their data and can say, Hey, I want to send it to this other doctor, but we have to start with the doctor first. That was the real core of us.

Kovid Batra: That’s great. I think that’s a good finding there. Yeah. Please continue. Sorry.

Jörg Godau: Sorry. My daily business, I run everything to do with technology. So the CTO reports to me, the developers, scrum masters, QA, architecture, cloud, all of this is my responsibility. And it goes a little bit further. And as the Chief Digital Officer, I’m also responsible for security, data privacy, and topics like this. So it’s managing all of the software development, delivery, and running of the software for the doctors, but also making sure we’re doing it in the right way that it’s compliant with regulations. And it’s Germany, so we have many, many, many regulations. I think if you print the regulations and the source code, the regulations will be bigger.

Kovid Batra: Yeah, that could be possible. One interesting question here. So, are these doctors ready to use your software immediately or there is an adoption challenge and like, do they pay for it?

Jörg Godau: So the doctors pay for the software, yes. Our prices are very similar to the prices that they normally pay for what they’re used to at the moment. A lot of doctors are ready for this because if you go to a doctor’s office and ask them, “Do you like your software in Germany?” The answer will be no, but they have very little choice. There’s not very many companies that do this. And some of the big companies actually have six or seven products. So the doctor can switch from one product to another, but it’s actually still the same company in the background.

Kovid Batra: Yeah.

Jörg Godau: And one of the things that these companies also do very badly is, you know, updates we’ve seen, they send like not floppy disks, but CD-ROM disks to the doctors and the doctor then has to install the update. Or like some of them you can download the updates. But if somebody accidentally clicks ‘update now’, then the practice can’t work for two hours or three hours. It’s like, and you’ve got all these angry patients who want their like treatment and your computers are just effectively broken.

Also, terrible customer support is another problem. Like, we have very good customer support. We have people who actually used to work in doctor’s offices working in our customer support. So they know, like when somebody calls up, they know what this is. They know, like how important it is and they can actually really help these people. So, doctors are ready. There is an adoption challenge because we have to get the data out of these old systems into our system. That’s the biggest challenge. So lifting the data from, like in the physical office. And if the doctor has, we have it sometimes hundreds of gigabytes of attachments that they’ve kept over the last 20 years, and a very bad internet connection. It takes a long time to upload. Yeah, but that’s just the feature of Germany and its internet providers as well.

Kovid Batra: But as you said, like, doctors are not very adaptive or receptive of the new tools. First of all, uh, I really appreciate the fact that you bring in a lot of business side information, user side information to your job, being a digital officer, a technology officer, I really appreciate that you have that business perspective in place and what exactly do you think you do with all this information and understanding of your user when you build your product, because that’s very important. Like, when you’re building technology, if you have that level of empathy, that level of understanding for the users, I think you can do a tremendous job at building the software right. So can you just give me some examples? Like, yeah.

Jörg Godau: So, we actually have partner practices which we work with and they work with us even before we’d launched. We worked very closely together with our partners and our product owners, our designers were able to go to this doctor’s office and sit with them and watch how they work and watch what’s not working in the old software or watch what is. And the old software is not all terrible, right? It’s old, but it’s not all terrible. It works. And some things are actually quite good. So they were able to go there and see what are the processes in the office of the doctor and where can we have the biggest impact. So our aim is to actually reduce the admin of the doctor like by building systems that reduce the admin by 40-50% so that they can treat faster and the limited time they have, they can focus on the patient Average German doctor’s visit for a normal patient- six minutes, including ‘Hello’, ‘How are you?’, ‘Goodbye’, ‘Here’s your medication, take it three times a day.’ And in that time, the doctor also has to write down all of the billing information. So, making all of this admin stuff easier means that in those six minutes, at least the doctor then can concentrate on the person in front of them and what they need. So this is super important.

Kovid Batra: Makes sense. So, what are the biggest challenges you see today in your role that you are tackling and has the biggest impact?

Jörg Godau: Right now, organizationally, we’ve reached a point where we are now focusing more on scale. So, having great software that does the right things. That’s certainly like an essential first step, but now we have to focus on scale. So, instead of adding 10 customers a month, adding a hundred a month, adding a thousand a month, what processes do we need to make sure that each of those also gets the same great support that the first 10 got? Yeah. Like, so, because if you have 10 customers and you have one customer support person, okay, he can talk to all 10 every day for an hour. Like, and it’s fine, yeah? But if you have a hundred, a thousand, 10, 000, it becomes much more about processes for scale, giving people access to their own support. So, self-service support, really clear instructions, or even better, building applications where you don’t need instructions for. And this is super important that it’s really intuitive, that it’s very easy.

On the other side, as we’re thinking about platform, integrations, marketplace, how do we enable somebody else to build plugins for our product? Like, I don’t want to build everything myself. There are, like different medical image formats. People have built great viewers for this that display all information with different colors and everything. It works. They’re really, really good. How can I enable that company to build a plugin that integrates with my software so that it runs, and the doctor can go to like a marketplace page and say, “I want to use this viewer.” “I want to use this telemedicine thing.” “I want to use this prescription stuff.”? And they have a choice then, but they don’t have to use 12, 15, 20 different products because they don’t like that because the products don’t work well together. So this integration and scale challenge, those are the biggest topics that we’re working on this year.

Kovid Batra: How do you exactly tackle this problem? So, if you could give me an example, I think I would be able to relate more here. Let’s say, we talk about having integrations, right, with third-party software. So what kind of challenges do you really face on the ground when you go about doing this? And you as a team leader or the like the whole organization, technical leader, what, what steps do you take to enable your team to do that efficiently?

Jörg Godau: Yeah. There’s all of the usual challenges, like when you integrate with a third party, like, how do you exchange information with them? How do you actually, like assure that the data is travelling in the right ways, that the data security is met? This is something where we have to be very careful when we’re integrating with third parties that, like, they don’t do things in a way that is against German regulations or against data privacy regulations. So for example, even if you take something as simple as appointment booking, right? Like, the patient wants to book the appointment. The doctor wants the patient to book the appointment. But, which data is shared? So, if you book an appointment with a psychotherapist, this already gives quite sensitive information about you as an individual, right? Like, you know, because somebody can, from just the calendar entry, understand, hmm, Jack has booked an appointment with a psychotherapist, maybe there’s something, like, wrong with him. So, we have to be very careful about those regulations. And then, it’s all of the standard stuff. How can we secure the communication? How can we, like make sure that the data is transferred accurately? How can we keep the systems reasonably decoupled? Yeah. Like, you don’t want to be reliant on somebody else and they don’t want to be reliant on you, like building these principles of decoupling. And then, those are the architecture challenges. And then you have on top of that, how do you share authentication? How do you validate the users? Where’s the primary source? Like, is the primary source our system, the other system, how do you match? You know, many people have the same name, right? So like, and even the same date of birth. And Germany has a population of like 80, 90 million people. A lot of those are double ups, right? We have a lot of like Müller and Schmitz. Yeah. And like, so you have to be very careful, like how you, like you don’t get the wrong appointment with the wrong person. So, some things that seem simple, become then bigger challenges at scale.

Kovid Batra: Makes sense, totally. When you encounter these challenges, these are some things that are to deal with the product and technology, right? Along with that, I’m sure you’re handling a big team there. There are people challenges also. So, this is one important topic that we usually discuss with the CTOs and other engineering leaders who are on the show. While you’re managing people, it is very important to see as your company scales, the people progress, right? And when you’re enabling a team, you need to make sure that people take the right career path. Like, you wouldn’t want a person who is aspiring to be into management or let’s say, Engineering Manager, you push them towards taking some technology role. So, you need to find that alignment. How do you enable your.. And you can’t go to each and every person and then talk to them and understand everything. When you are at scale, you have hundreds of developers, team members working with you. How do you impart that thought into people so that they make their decisions consciously of what do they want to do? That makes your job easier. But I think that’s very important for them to understand themselves also to align better.

Jörg Godau: A lot of this comes from company culture and values. If you set up the right company culture, the right company values, then you are actually in a very good place to allow people to grow in the right way. Doctorally, even though it’s a startup and I think altogether, we’re about 70 people now. Development about 30, 35 or technology, let’s call it technology, 30, 35, a lot of other people in sales, customer onboarding, support, you know, like these other organizational roles. So, we have four values. ‘Excellence’. People should strive to do great work. Yeah, like, fairly normal. ‘ Integrity’. You must do what you say that you’re going to do, or try to do what you say that you’re going to do. And if it doesn’t work, you must tell somebody and not, like, just hide it, yeah? It’s fairly normal as well. ‘Kindness’. Yeah, this is super, super important. And this is not just kindness to the employee, but kindness to the customer, kindness to the patient who is sitting in front of our customer, like kindness to each other, how we talk to each other and how we, like behave if you make a mistake or if you accidentally, like talk to somebody the wrong way. Go and say like, “Hey, I’m sorry.” Right? This is part of it. And, ‘Ownership’. So taking ownership of the work that you do, being responsible for the things that you do and accountable for the things. And using these four values, we talk about them all the time. I refuse to let them be written on the walls. I think once you start writing them on the walls or putting them in pamphlets, values are no longer useful.

I did this actually, we had a, I went to a, like a presentation and gave a talk in front of a bigger group of people and I asked, you know, “A show of hands, does your company have, like values?” And most people put up their hands. I’m like, “Okay. Do you know the values?” And like, half the hands, they go down. At Doctorly, every single person knows the values because we try to refer to them always and we try to use them in our daily business. So we say, “Thank you.” Thank you for taking ownership. Thank you for like, you know, doing this work. Thank you for like, you know, being kind, to like help me. And that’s really important. And when people feel comfortable and safe, then you can talk about personal growth. Do you want to become a better technical expert? Do you want to become a manager? Are you happy doing what you’re doing and we don’t, like need to move you anywhere? It’s also people, like sometimes they’re just happy doing their job. You know, like, and sometimes people don’t want to be something else. They just want to be good at their job and do this. Of course, in technology, everybody must still continue to learn because the technology changes, so you can’t be completely static. But if somebody is a great backend developer and they want to continue to be a great backend developer, and they have no vision for themselves for leadership, why should I force them? It just hurts them and hurts me in the end. So, this is really important And then, taking the time to talk to people, you know? Those are the secrets. Like, I think we all know them. It’s the doing that’s, that’s harder. Yeah.

Kovid Batra: Exactly. I mean, I was just about to say this, that even though every time you mentioned, that, okay, this is the value, pretty common, but the important point that I took away is that you are not putting them on the walls and you are bringing them into the discussions on an everyday basis when you’re working. And I think that’s how the human brain also works. Like, you have to do that reinforcement in the right way, so that people live by it. So, I think that’s pretty good advice actually.

Jörg Godau: It’s like learning a language. If you don’t use it, you can’t learn it, but you can study it and it’s okay. But if you don’t use it, if you don’t live with the language, it’s not possible to really learn it. And if you have values that you don’t use, what’s the point, right? Like..

Kovid Batra: Absolutely, absolutely. Perfect. So I think with this, one question that comes to my mind is that when everything is aligned on the cultural and values part, you’re doing good. You know, you get that feel from the team that they are very integral, they’re putting down their best, right? How do you exactly measure their success? Like, for an engineering team which is basically enabling the product, how as a technical leader, you define the success of an engineering team so that they also remain motivated to achieve that, right?

Jörg Godau: It’s super difficult, right? Like, metrics, measurements, super difficult topic. And it’s one that we’re just revisiting ourselves as well at the moment. And we’re considering what do we measure? So, at the moment, we are measuring very obvious things, customer bugs, customer satisfaction. This is quite simple. If there’s no bugs that customers find, it doesn’t mean your software is good, but it means that it’s working in a way that they expect, you know? So that’s one very easy thing. I think all development companies can measure this.

The other thing that we’re trying to do is we’re giving the teams when we ask them to build something, we actually ask them, “Okay, you tell me how long.” And they get to choose. Will it be four weeks, seven weeks, five weeks, eight weeks. And then we measure, did they get that right? So, are they able to deliver at the time when they say they want to deliver? And if not, then we have to look at what causes this, obviously. And this is a big change. We used to work using Scrum, two week sprints, deliver every two weeks something. We don’t do that anymore. Now, because the things that we build are either too small and so two weeks is too much, or too big and it takes many months. If we have a new complicated regulation that we have to implement, you can’t do this in two weeks. And you can’t, like, yes, you can build it iteratively, but it provides no value until it’s finished. And thus, you have the certification. So you can never give it to a customer until you have the signed piece of paper from, like the regulatory body.

So in this sense, we’ve now aligned our development process more to how the real world expects us to work. And that’s been a big change, but I think overall now that it’s been going for a few months, that’s been actually quite good.

Kovid Batra: Anything on the DORA metrics piece that you have seen, being implemented or thinking of implementing in your teams? Like particularly, let’s say, cycle time or change failure rate so that the teams have visibility there, or do you just think that these metrics put in the right process, which you’re already measuring would do the purpose, fulfill the purpose?

Jörg Godau: We do measure some of these things. Deployment frequency for us is not relevant because our customers don’t want the software to change during the day. You’re a doctor and you’re using the software. It should not change.

Kovid Batra: Yeah. Yeah.

Jörg Godau: Oh, they’re like, you know, if you’re Amazon or eBay or something and you have customers 24/7 and you can, like do like different things. Yeah, fine. But for a doctor, if he’s in the middle of making a prescription, and the form suddenly changes and there’s a new box, it’s like, no. So deployment, our deployment frequency is one, once per night. Finish. So then, there’s no point to measure, you know. And, obviously when there’s something that needs to be deployed, but otherwise that’s, so that path for us is useless.

What we do measure is if there is a critical bug. So, something that is stopping a doctor from doing something that’s important for the patient. These ones we want to solve on the same day so that the patient can get his medication or his sick note or whatever they need. And this is something that we track the resolution time on the bugs. So, critical bugs must be resolved within the one day, and that’s working very well. Other bugs, we want them to be resolved within the times that we, like the SLAs that we give. So we track the SLA resolution on this. But, if there’s a spelling mistake, you know, if it says ‘calendar’ with like, double ‘a’ instead of double ‘e’, nobody cares when this is resolved. Yeah. It’s an example that I’m pulling from nowhere, but it’s not important because everybody still understands it’s the calendar. They can find it. They can use it. Everything works. So these ones we don’t care about. So any of the low-level bugs, we don’t track the time on these. They have to be done. Yeah, it’s wrong. Yes, must be fixed, but it’s not such that people can’t work. So, low-level, we ignore in terms of tracking metrics because it just adds effort. Every measurement that you make costs time. Every time you look at the measurements, “Oh, we’re not resolving our low-level bugs in 16 weeks.” Yeah, and? Like, well, what does it matter?

So, this is the important thing. When you’re measuring something, you must determine what are you going to do with the answer? So, if you’re measuring a piece of wood, you’re asking the question, is it big enough to make what I want to make from this piece of wood? Yeah. It’s a very specific question. If you are measuring development teams, it’s much more complicated, obviously, but what do you want to do with the answer? If you have no, like, if you don’t know what the answer is for, you shouldn’t measure it.

Kovid Batra: Absolutely. I think it’s a very valid point that, DORA metrics or in general, any engineering metric that you’re looking at, it’s not going to be same for the other team that is working on a different product, right? Every organization, every team has their own areas where they need to focus. And you have to choose these metrics rightly so that you can make an impact rather than just putting down all those gazillion metrics there and overloading the team with something which is completely unnecessary. So I totally agree to that point and it makes sense. The deployment frequency was a very good example. Like in your case, it doesn’t make sense to measure, right? You can deploy only once.

Cool. I think that that’s really great. That was something on the quantitative part. You’re looking at engineering efficiency here. But another important aspect is the developer experience, right? Uh, you have to be empathetic of your team, trying to understand what do they feel. What are their basic needs if there are any kind of challenges? So, do you do any measurements or pulse check-ins there to understand what they need as a team, as an organization to work swiftly?

Jörg Godau: So we do the usual things like we do like 1-on-1s, we do skip-level meetings. So, managers talk to them. At the moment, actually our CEO is in South Africa. A lot of our team is actually based in South Africa. And he then met personally with all of the people in South Africa.

Kovid Batra: That’s great.

Jörg Godau: We have twice a year we have events where people come together. Our team is very distributed. So we have Germany, East Europe, Lebanon, South Africa. But twice a year we bring people, not all together because we can’t afford flying 20 people from South Africa to Europe or vice versa. But we have one event in South Africa, one event in Europe, and people get to spend time with each other. This is very important for the feeling. And we do, measure employee NPS. So internally every month we send like a very quick survey, like just three questions, you know, NPS-style survey. And then once per quarter, we actually do a feedback cycle, like a proper feedback cycle where people get feedback from their peers, from their manager, from their direct reports. So, and we gather all of this feedback and the managers then look at it together with the people and say, “Hey, this is the feedback you got. Like, your team members are really happy with the way that you work, but not so happy with how you communicate. So what can we do to help you, like communicate better?” Or, ” You’re doing good work, but your colleagues don’t like the way that you like, sometimes don’t write enough unit tests. So, what can we do to help you write more unit tests?” Like, so, like very specific conversations can then happen out of this.

And we also then rate the employees, like how well are they doing now and what’s their future potential. So we have a like a grid system. Are they doing really well now? What’s their potential like in the future? And we reward the ones that are doing really well with extra shares or opportunities to do more work or not more work, but like to like grow in their career in different ways. So if somebody says, “I want to become Senior Engineer.” Or, “I want to become Team Lead.” We then try and look at that with them together and say, “Okay. So, what are the steps that we need to take? What’s the path?” And have very clear discussions with them.

Kovid Batra: That’s really amazing. And managing remote teams like this is kind of necessary now. And if not done well, I think you will not have the right team with the right enthusiasm in place. So, totally appreciate that.

Perfect, Jack. Thanks for sharing all these insights and learnings with us. I hope our audience would love it and thanks a lot once again.

Jörg Godau: I’m very, very happy to have this conversation. Thank you for giving me the opportunity. I think just one last thought on the whole, like remote work point.

Kovid Batra: Yeah.

Jörg Godau: There are a bunch of companies now that are saying you must come to the office two or three days or like some rule for coming back to the office. For me, I think this should be taken under the premise that as a management team, as a leadership team, we cannot support you remotely. It is not about the employees, but it’s about the organization can’t do it. If you force people to come to the office because you don’t trust them, you can’t see their work, you can’t measure what they’re doing, this is not their fault. Now, like you have to find ways to actually be able to do these things remotely. It is much more work as an organizational leader, as a team lead, as a manager, to have a remote team. Because if you have a local team, sure, you walk into the office, you look, “Ah, Mary, she looks a bit sad.” “John, he seems like he’s not having a good day. I’ll talk to him.” Remote team, you have to actually spend time. You have to talk to them. Not every day, maybe if you have too many people, but regularly or in group settings. And you have to provide this. And that means you as a manager have to find somewhere the extra hours to do it. And this is the thing where I think companies are misrepresenting. This is like, ah, we like, need it for collaboration. It’s very good if the people can meet and collaborate, making like, we have it to like, we make hackathons, but the people can participate remotely, so they’re able to collaborate, able to work together or we have these events where people come together. These work, but if you force people to go to an office and sit at their desks, especially if you’re an international company, what am I supposed to do? I make the people in South Africa go to the South African office to have a video call with the people in East Europe. What’s the point? Like, this is like, it’s like at this point because we’re so spread out, it’s now like obvious that it won’t work.

Kovid Batra: Yeah.

Jörg Godau: So, I think that’s super important and we’ve seen a lot of, like news, big companies forcing people back to the office full-time, part-time. I think that this is a failure of people to adapt and not of the individuals, but of the organizations. And this is something that I’m very passionate about, like holding up a flag for.

Kovid Batra: This is a little counterintuitive thought for me, but I think it’s very true, actually. It’s the organization that has to take care of it, not the employees.

Jörg Godau: And if, if I as a manager can’t do it, if I’m not capable as a manager to manage a remote team, that’s okay. But I have to say, “I, as a manager, I’m not capable to manage a remote team. So you must all come to my office.” It’s not his fault that I can’t manage him when he’s two hours away. Right? Like, or her fault. It’s my fault because it’s my job as a manager to manage these people. And some people are not good at remote work. There are individuals who, if they work from home, they don’t perform. Yeah? But you have to either help them to learn how to work in this way or they have to find a job where they go to the office. Yeah? But it’s not like, it’s not every employee’s fault that one manager is not capable. Yeah. It’s like if you think about it this way, like if there’s 10 people and one of them has a problem and nine don’t, which one is most likely have to change?

Kovid Batra: The organization, probably. Yeah.

Jörg Godau: Yeah. Cool.

Kovid Batra: Perfect, Jack. Can’t thank you enough for all the insights and learnings. I would love to have another show with you and share more details on how to manage these remote teams better because that looks like a very interesting topic to me now.

Jörg Godau: Yeah. Thank you very much, Kovid. It was a real pleasure to talk to you and certainly very happy to talk again in the future. Yeah, thank you.

‘DevOps, SRE & Platform Engineering’ with Ricardo Castro, Principal Engineer, SRE at FanDuel

In the recent episode of ‘groCTO: Originals’ (Formerly: Beyond the Code: Originals), host Kovid Batra welcomes Ricardo Castro, Principal Engineer, SRE at FanDuel. He is also a co-organizer of the DevOps Porto Conference and DevOps Day Meetup, as well as an ambassador of the Continuous Delivery Foundation. The discussion centers on ‘DevOps, SRE & Platform Engineering’.

The episode kicks off with Ricardo shedding light on his personal interests and transformative life experiences. He imparts valuable wisdom on differentiating between DevOps, SRE, and Platform Engineers.

. He also advises adopting best practices for implementing CI/CD pipelines in startups, medium-sized enterprises, and large corporations and presenting a robust framework for cultivating effective DevOps teams.

Lastly, Ricardo provokes thoughtful reflection on whether deployment frequency truly encapsulates DevOps efficiency, or if the focus should shift towards the value delivered.

Time stamps

  • (0:06): Ricardo’s background
  • (0:41): Ricardo’s hobbies
  • (5:06): Key differences between DevOps, SRE, and Platform Engineers
  • (18:53): CI/CD implementation practices for different company sizes
  • (23:40): Strategies for building strong DevOps teams
  • (26:44): Is deployment frequency vital for measuring efficiency?

Links and mentions

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who is an expert in Platform Engineering. He’s a co-organizer of the DevOps Porto Conference. He’s a co-organizer of the DevOps Day Meetup. He’s an ambassador of the Continuous Delivery Foundation. He’s currently working as a Principal Engineer/SRE at FanDuel. With a total of 15+ years of experience in DevOps engineering and leadership, we are happy to welcome you, Ricardo, to the show. Great to have you here.

Ricardo Castro: Thank you very much for having me, Kovid. I’m really excited to have this conversation with you.

Kovid Batra: Perfect. Perfect. So, before we get started and deep dive into Platform Engineering, DevOps, and Site Reliability, I would love to know more about you, Ricardo. Our audience would be interested to know more about you. So, tell us about something that you like outside of work.

Ricardo Castro: Yeah, sure. The people who know me know that I’m an avid music listener, so I just love music, mostly metal music. That’s the thing that I listen to the most and everything around guitar, I love as well. I played guitar for many years and it’s something that I’m trying to pick up recently, so it’s something that probably in the next few years I’ll be ramping up my skills. Also, I enjoy sports, doing sports. I practised Taekwondo for more than a decade. And now I want to try something different. So, I’m doing CrossFit and I’ll probably try some martial arts in the next year, probably Jiu Jitsu. That’s what I’m going for.

Kovid Batra: Oh, that’s so cool, man. Music, Taekwondo, from where are you getting this energy and what is the motivation to learn all these things?

Ricardo Castro: I just usually like to challenge myself. If I want to learn something because I enjoyed it, I just try to do it, even if I don’t have a lot of time. And if I really suck at something, I try to at least get to some level of proficiency, not like going to a guru or on something, but try to at least get some understanding of that, if at the very least I have some interest on that topic. And that’s how I usually try to approach it.

Kovid Batra: That’s cool. That’s cool, man. All right, moving on to my next question. Anything that inspires you or defines you in your life, any, any life-changing moment or a life-defining moment that you would love to share with us?

Ricardo Castro: Sure. So something that I really like doing is to help other people or other teams. So, before I got into tech, I worked as trying to help kids in school to overcome challenges at school in terms of, so they probably, they were bad at math or something like that. I worked at a company for a few years like that. And it’s something that I always enjoyed to get to help other people achieve their goals. So for many years in the beginning of my career, I was a traditionally a software engineer, just building features, building product, and then eventually I migrated into a more of an operational role. And I think that now we talk about a lot of Platform Engineering, but it’s something that I believe that once I went into more of that operational role was something that I always tried to do, like to build tooling and to build platforms that other teams could use. And I don’t have to be in the middle. So I’m there to help, of course, but it’s something that my goal was always to, if you don’t need me because I built you the tool or you have something that you can progress on your own, that’s cool. I don’t want to be an impediment for that. So, it’s something that usually inspires me. So, how can I get out of the way of what people are trying to do. That could mean building documentation. That could mean building a CLI. That could mean building an API or a platform or whatever it is. And my goal is always to empower you to do whatever you need to do with the least impediments possible.

Kovid Batra: More like automate everything theory, right?

Ricardo Castro: Yeah, yeah, yeah, yeah. We always find new things to work on. So, I don’t, at least for now, I don’t have that fear of getting myself out of a job. Because as soon as I finish something and I deliver something, there’s 10 other new things that pop up. So, it’s always that, like, automate, give the tooling that people actually need. So if they don’t need me, I shouldn’t be there in the middle of just to click a button or to run some command because people are responsible. People are grownups. So, here are the tools. Progress on your own. If you need me, I’m here to help.

Kovid Batra: No, absolutely. I think, it’s a little counterintuitive for a lot of people. They try to create those dependencies so that they have the security probably, but I think the right way to grow, even I believe so, that you should make up time for yourself. And to make out time, you just have to get out of those situations where you are doing just the redundant job for people. So..

Ricardo Castro: Yeah, exactly.

Kovid Batra: Yeah. Yeah. Cool, man. I think this was really interesting. It was great knowing a little bit about you. Let’s move on to our next section which is more around DevOps, Site Reliability, Platform Engineering, your area of expertise, basically. So let’s start with the very basics. DevOps, Site Reliability Engineer, Platform Engineer, I would love the audience to know from you, what’s the fundamental difference? And with each of these roles, there are some responsibilities coming into the picture. So share here’s some thoughts about those responsibilities that you see as a DevOps Engineer or a Site Reliability Engineer or a Platform Engineer. And then, what are the challenges associated with it? So, it’s a big question. You can take your time.

Ricardo Castro: Yeah, sure. I’ll try to compartmentalize that into, like DevOps, SRE. So let’s start with probably the concept that people know for them, a longer period, which is about DevOps. So, if we go back and we start seeing the origin of DevOps, the movement started to form around 2007-2008. And it had one goal, right? It was to bridge the gap between dev and operations. So, we had devs on one side. We had ops, traditionally SysAdmins, back in the day. And there was a conflict between this group of people. So, engineers want to be, or product engineers, software engineers want to deliver features, want to deliver, put stuff in production in front of customers. SysAdmins or operations people, let’s call them operations people; their responsibility is to make sure that the systems are working as they should. So, if you introduce change to a system, there’s a very high likelihood of that system having some kind of failure. So there’s not an incentive alignment here.

So on the one hand, we have, you have people that want to introduce changes to a system. On the other hand, you want people that just want to make sure that the system needs to be stable. Don’t mess with it. Just, just leave it be. And this becomes a problem because to continue growing, companies need to continue to deliver features, but then you have probably two of the most important teams in the company that are not aligned in the same objective. So that’s where, where, what DevOps try to bridge that gap. It’s around, okay? How can we get these two areas aligned into common goals? Of course, over time, we realize that it’s not only Dev and Ops. There’s a lot more Quality Engineering, Security and so on and so forth. You have to involve Product. So, DevOps nowadays, I think it’s a lot more than just Dev and Ops. There’s more disciplines that need to be brought to the table around this. But DevOps in the beginning and when the term was coined was in 2009, was never very prescriptive in terms of, “Oh, this is what exactly what you should do.” But the problem with that is that on the one hand, it gives you a lot of freedom. So, the main goal is to bridge the gap between all of these disciplines. How do I align those goals? On the other hand, some, most companies are like, okay, but I need some, you need to tell me something that I need to do to actually do that. So, what we’d started seeing around DevOps was a lot of work around how do I deliver features faster? So, it was stuff around CI/CD. How do we automate all the things? So, DevOps in the last decade started to migrate a lot into, I can build some automation around, for example, how do I, how do I build resources with tools like Ansible, Terraform, whatever tool you, you decided to use and a lot about CI/CD. How do I automate the build, deploy, test process to get stuff into production?

Site Reliability Engineering, probably a lot of people don’t know, actually was created inside Google many years before DevOps, which is kind of weird because we only, like in the last three, four or five years started hearing about Site Reliability Engineering. But, it was around 2003 when Google was facing the same problem, right? Devs, Ops, Engineering, this doesn’t work. Google was growing like crazy. So they were like, “Okay, so we need a better approach to do this.” So they tasked a team. What would happen if we take a bunch of software engineers and put them in charge of operations? And that’s the, like the gist of what happened with Site Reliability Engineering. So Google created this practice. It was made popular by the book that they released in 2016 where Google revealed what for them is Site Reliability Engineering.

Something that we need to keep in mind is that that book came after, like more than a decade of experience. So what Site Reliability Engineering was in the beginning at Google and what was in 2016, it’s not the same thing. There are continuous learnings and continuous approaches, but it’s a lot about going from production backwards, right? So, something that people know a lot is about SLO. So, Google created something that would allow them to define what reliability means. It’s not like I think reliability is this. You think that reliability is that. No, we need a common language where, where we say, “Okay, this is what reliability is.” SLOs. That’s a framework. Okay. Once we have that, we can start working backwards. So, are we achieving our targets? Are we not achieving our targets? If we’re not, what do we need to do? Of course, these two disciplines can.. DevOps and SRE can somewhat meet in the middle, because if we start from production backwards, we will probably arrive at a point where we say, “Okay, so probably one of the biggest problems that we have is that my deployment process or my build process is not reliable enough. I’m introducing a lot of problems. So, let’s automate it. Let’s improve that.”

And of course, recently we started hearing a lot about Platform Engineering. Although again, although people think it might be a new thing, it is not. If you learn, if you read, like the ‘Team Topologies’ book, which is like four or five years old, they already talk about Platform Engineering. And if you worked at a big company, like 15 or 20 years ago, you already had internal platforms. So, the concept of Platform Engineering, it’s absolutely not, it’s not new. The thing is that the advancements of the cloud and all of these new technologies that we have started to democratize how platforms could be built, making it easier, making it that companies, smaller companies, or even startups can build their own platforms easier. So, that’s why we’re starting to see a lot of involvement in Platform Engineering, which is awesome, which is good. It’s about building some kind of abstraction where, for example, software engineers have a standardized way to deploy stuff, to observe their services, how to get them running in production. There’s a lot about golden paths. So this is like the preferred way for the company to actually build and deploy services.

One common pitfall that I see a lot with Platform Engineering and I’ve been writing about that recently a lot because I see this problem happening a lot in many companies. It’s about platform teams building stuff in isolation, right? So we, you create a platform team. They go into their room. They do their thing. And then they say, “Oh, here’s the platform.” If you don’t treat your platform as, let’s put it like, as a product where you have customers, which are other engineers in your company, you’ll probably have a lot of trouble because you probably built the wrong platform or at the very least, something that is not aligned with what people are expecting. You’re probably not solving their problems. You’re probably creating some roadblocks. You don’t have the vertical or the business knowledge, the business domain knowledge that those teams have. So you’re probably building, “Oh, so here’s a nice way to deploy this kind of application.” They’re like, “Okay, yeah, but I have this requirement and that requirement and I can’t do that with your platform.” So, that’s probably the most common pitfall.

So, just to summarize Platform Engineering, you should look at it as some kind of a product where you have customers, which are other engineers, and then you have to build, like any other product, the features that they need. Of course, every once in a while, you need to risk it. You need to try new things and you need to put new stuff in front of your engineers. Sometimes we don’t even know what we need, right? It’s like product development and the customer only knows what he wants when he sees it. But if you have customers like your fellow engineers and they have problems, the platform should be aimed at solving those problems. Maybe deployments are too slow. Maybe every time that I need to create a new project, it’s a hassle. So if I have an easier way to do that, it would be awesome. Maybe I don’t know how to observe my application. Okay, so my platform could build some automation and I get that for free. All those kinds of things. So you should be building iteratively and should be solving problems and making your teams faster, not trying to build a platform and then force it into your teams. And then at the end of the day, you will not be happy because adoption will not be great. Your teams will not be happy because they will be forced into doing something that is not helping them.

But Platform Engineering, I think it’s probably one of the biggest advancements that we’ll have in the operation side of the things because it allows you to automate a lot of stuff and it allows product teams to actually build faster because okay, I know exactly how to deploy my application, how to observe it. It’s easier. I need to focus or spend more time fixated on the problems that the business want to solve and not how I’m going to operate this in production.

Kovid Batra: Right. Makes sense. One question, regarding Platform Engineering and Site Reliability. So, the people who are actually on this team, who are taking care of, I would say developer experience, because ultimately you are impacting the developer experience with it.

Ricardo Castro: Yup.

Kovid Batra: How does a day-to-day basis, the role of a Site Reliability Engineer differs from somebody who is involved in DevOps. Like, what I could understand from your explanation is that both of them have the similar goal of taking care of the teams. There should be things running, it should be in line with automating or improving the overall acceleration or velocity of the team, right?

Ricardo Castro: Yup.

Kovid Batra: So, both seem to be similar levels. How does their role on a day-to-day basis differ from each other? And yeah, I think first is this.

Ricardo Castro: Yeah, sure. So, it is, of course, will be different from organization to organization. There is no silver bullet and you have to adapt to your own reality. What I see most often is that when you’re talking more about DevOps or traditional, I always struggle with the term DevOps Engineer, because again, I think DevOps is culture. You don’t need DevOps engineers, but let’s go with what the industry has come up with. What I usually see with DevOps teams is that they usually are responsible for some part of the automation. So probably they build, I don’t know, they build your servers or they build your Kubernetes cluster, whatever it is, they help you automate your CI/CD pipeline, for example. But then it’s probably up to you and your own responsibility to just, okay, so you have all this tooling, just go do whatever you need to do. Site Reliability Engineering usually starts to focus on production, right? So they start looking at production. You’re like, okay, what does reliability mean? One of the first things that site reliability teams do when starting to build this culture inside a company is, okay, we all have a different opinion of what reliability means. Okay, so let’s build a common understanding. Is it SLOs or whatever framework you want to do to make this definition? Once we have some nice definition, do we have the observability that we need to actually understand if you’re being reliable or not. So, site reliability engineers usually are very focused on observability. We have the metrics that we need. We have the logs that we need. We have the traces. We have whatever we require to actually inform that reliability and say, “Okay, it’s good.” “It isn’t good.” “Are we achieving it?” “Are we not being reliable as our customers need us to?” Usually only, only then they start to tackle more reliability issues in terms of unless there’s something glaring in your system. So, let’s say that you build an API or build a site and it’s constantly down, right? So, probably the first thing that the Site Reliability Engineer or engineering team will try to do is around, okay, let me like try to mitigate this or make it less painful, let’s put it this way. But if you’re getting, if you already have a, if you’re decent, you probably want to get from decent to actually meeting customer expectations. So that’s why you need a reliable framework. That’s why you need an observability platform, whatever it looks like in your organization to actually understand, okay, I’m meeting these goals or not.

Usually where these two DevOps engineers and SRE teams meet, it’s more or less right in this, in this, at this point, right? So you’ll probably realize once you have the observability and SLOs, that you could improve, for example, the way that you deploy applications. The way that you are running in production, you probably need, I don’t know, maybe you need a circuit breaker. Maybe you need to implement rate limiting. So, SREs can help with that. And the other way around. So once, DevOps engineers have a lot of, a lot of this in place, they can start then operating with teams. But I would say that these two approaches usually start at different spectrums. And then, eventually meet in the middle. So again, just to summarize, SREs are usually a lot involved, at least in the beginning of about defining what reliability is and what it looks like, a lot about observability. So they need to understand what is happening in your systems and as DevOps engineers are usually in the beginning focused a lot about automation, building CI/CD pipelines, and then eventually converging. Of course, just to finish on this, what SRE looks like in Google and in other organizations will be completely different. So, people need to take that into consideration because it’s tempting to just look at the SRE book and say, “Oh, I need to do this exactly as the book says.”

Kovid Batra: Yeah.

Ricardo Castro: We don’t, so the book is quite big. So there’s a lot there to learn from. And of course, companies like Google, Amazon, Meta, they have probably challenges that, I don’t know, a handful of companies, in the world have. So they need to tailor those solutions to their problems. But we can do the same, right? So we can see, oh, this is how Google does things. So, do I have a direct relationship between what they do and what I do? If not, are there similarities, are there differences and make that adaptation?

Kovid Batra: I think that makes a lot of sense. And the point that you mentioned here, you have to treat, if you are an SRE or let’s say, a DevOps Engineer, you have to treat other developers as your users and the platform as your product. So while you are building that, you have to have that ideology in mind to actually improve the overall experience, impact the overall velocity of the team, the quality of the work they’re producing. And I think most important part comes into the CI/CD pipeline itself. Like that is one critical portion of the whole delivery pipeline, I assume. So, you are an expert at it. What I would want to learn from you is what are those best practices or what is the ideal way to implement CI/CD for a startup, for a medium-sized company, let’s say who has 100, 200 developers, and then we move on to a larger size company where you have, let’s say thousands of developers.

Ricardo Castro: Yup.

Kovid Batra: Of course, For each stage, there should be a different set of practices. There’s a set of considerations that have to be taken while implementing that CI/CD pipeline. So, can you just throw some light over there?

Ricardo Castro: Yeah. So I think that overall, the problems are the same between your either a startup or a big company. So if you think about CI/CD, it’s the concept that we want to integrate code as fast as possible or integrate regularly. Let’s put it this way, regularly. And about continuous delivery. It’s about you’re getting stuff in front of your users. At least that, that’s my definition. And what we see a lot in the literature, some people, and this is a caveat, think about CI/CD as just automation. And what I would say to that is that if you have an automated integration step and an automated deployment step, but you’re not integrating regularly, it’s not continuous integration, because if I have a feature branch that spawns, I don’t know, a week, a month, and then eventually I integrate, that’s not continuous integration. That’s automated integration, but it’s not continuous. And the same thing with deployment. Yeah. For me, continuous deployment is putting stuff in front of your users, not just getting to the point, “Oh, this is in the process of being released.” And then it stays there for a week, a month, six months. It’s like, okay, I’m not putting it. I don’t even know, if it works or not. I like a lot of the philosophy of Charity Majors. She usually says that if you don’t put stuff in front of your users, you don’t really know if it works because probably we’ll discover problems with that.

So, what I would say is that independent of the size of your company, what you want to do is to make it faster, right? So, I’m a developer. I do a pull request. It is reviewed. I want to get feedback as fast as possible. Of course, that for smaller companies, they don’t have the budget in terms of either money or engineers to implement a lot of that themselves, so they can rely on SAS services if they have the budget to automate a lot of that stuff. And now, with the CNCF, we have a lot of tooling around that that can make it really easy.

As you start getting bigger and bigger, you probably will start to have more requirements. So, you’ll probably start having the need of more custom things. You’ll probably have more systems. You’ll probably have legacy systems where just using a tool out of the box doesn’t work. So, you’ll probably start to have to build some stuff internally. What I would say is to continue to leverage open-source tooling as much as possible. That’s always a business advantage because you won’t get stuck or you won’t get pulled in into a specific vendor. And then, yeah, all of your things are on top of that of that platform. It would be a strategic advantage. But the goal is the same, right? I want as a developer, I want to get feedback as fast as possible. So, I want to submit something and I want to, I don’t know, that my tests run faster, run fast. I want the deployment to run fast. So as an engineer, if I’m put into a place where I do a PR is merged. And then it takes one hour for the tests to run, one hour to deploy something. So I’m just sitting there like for a couple of hours like, “Okay.” And then to have something and I am like, “Oh! Actually, there’s a problem.” An automated test run or a user complaint. And it’s something very simple. And then I have to spend like two or three more hours just waiting for that whole process to finish, of course, when you’re probably a smaller company, you won’t have a lot of this, a lot of these problems because usually your systems are small. But again, that’s one of the differences between.. Usually, what I see with startups and bigger companies is that your system starts getting bigger and bigger and it’s easy to start having these delays, right? So I submit a new change and it takes a one hour, two hours, three hours for my change to get into production. So again, the goals are still the same. You’re just facing different problems in terms of size, scale. Bigger companies probably have more custom things that they need to do and they have bigger systems. So, they have to invest more in terms of time and money to actually fix those issues.

Kovid Batra: Yeah, Ricardo. I think that that’s really interesting. Now, looking at certain practices that you need to, like adopt before going ahead and solving those problems for the team. So, is there a specific framework that you follow when you do it in your teams? Any kind of philosophy that you adopt before approaching, like one you already mentioned on a broader level that you should treat them as your users and platform as your product. But is there anything else that goes into building some really good DevOps teams there?

Ricardo Castro: Yeah. So something that probably people know and have seen in the industry is a lot of talk around DORA metrics, right? So, for people who don’t know, it’s a set of metrics that allow us to understand the level at my organization or my teams are at. It’s a kind of a standardized way. It has been done, if I’m not mistaken, since 2014. There’s also a great book, which is called ‘Accelerate’, which explains the origin of where the metrics came from and the, the whole scientific approach around it. And it’s probably the best way that we have right now. Maybe we can come up with something better in the future, I don’t know, but it’s probably the best way that we have right now to actually understand at what level, in terms of proficiency, is my organization. And those metrics are deployment frequency, lead time for changes, time to restore a service and change failure rate. And now, I think last year, a new metric was introduced, which is reliability.

So essentially, it’s some centralized ways that I have. If I measure these things, I can understand if I am an elite type of team or I’m at a low level. So something that we’re doing in our organization is measuring these things. For example, that we were talking about CI/CD, if my lead, my lead time for change is more than six months, I’m at a low level, right? So it means that I have some change. I want to introduce that change. And it takes me six months to get that into production. Also, it allows me to compare between organizations. Of course, this needs to be taken with a grain of salt, right? So we can compare ourselves, like blindly. But it allows me to understand, “Okay, if my company takes six months to take a change to production, I can’t be at the same level as a company that deploys software continuously every single day. And the same thing for time to restore a service. If every time I have a problem, it takes me I don’t know, hours, days to fix it or to mitigate it, I’m not at the level that I want to be at. So it’s something that we’re doing internally. It’s something that I’ve done in the past and I think it’s a good idea to at least analyze the DORA metrics. See if it makes sense in your organization. Of course, they’re not the only metrics that you should look at, but it’s a standardized way. And it’s a good starting point because we have a lot of data from the past. I think the respondents in the last few years have been in the order of tens of thousands. So we have a lot of data that we can rely on and to be sure that these metrics are actually relevant. And these metrics are something that can allow me to understand, “Okay, if I’m at an elite level of deployment frequency, I’m in a good place. If not, it’s something that I probably need to work on and improve.”

Kovid Batra: Totally makes sense. I have one question related to this. One of the metrics, that we usually measure, which is deployment frequency, and you have just mentioned about it, a lot of engineering leaders to whom I’m talking, sometimes they challenge this thought that why is it even important? Like, we are doing it once in a week or once in 15 days. And if we’re rolling out features at the pace that we want, the deployment frequency doesn’t actually tie to that because ultimately it’s the value you want to deliver. If you are delivering it in small chunks or you’re delivering it in one big packet within 15 days, it’s the same. So measuring deployment frequency and understanding the efficiency of a DevOps team or a dev team on the basis of deployment frequency is probably not the right way. What’s your thought on that part?

Ricardo Castro: Yeah. So, I’ll start with the caveat and then I’ll give my opinion. So there are some cases, for example, there are services that I don’t know, don’t have a lot of development, right? So it’s a service that is old or is a service that is very stable. So then, there are no new features. So it’s normal for those services or that, that group of services to not have a lot of deployments. So, that’s the first thing. So, it’s not like a one size fits all. Maybe I have a service that I don’t know, deals with authorization and I’m, I’m done with authorization. I don’t have a lot of things to do that. So it’s perfectly normal that I don’t do deployments on that service every day.

That said, now there’s what you were talking about. If I’m delivering, for example, let’s use the timelines that you said. What’s the difference between me developing or delivering something like every day or delivering like the entire value once every two weeks or once a month. What we’ve seen and that’s why it’s important to have all the metrics and not one of the metrics in isolation is the fact that, for example, if you do a deployment every two weeks or a deployment every month, you will probably have more time with the other metrics. So you will probably be introducing more changes at once. So you will probably introduce more failures because it’s one of the, if not the most common thing to introduce a failure in a, let’s say in a system. It’s to introduce a change. And a deployment is a change. So the bigger the deployment, the bigger the likelihood of that problem of you introducing a problem in, in the system. And of course, time to restore will be impacted because if you introduce a small change, you have it in your mind. You introduce it every day. You just work on that code. You can understand it better. It’s like, “Okay, so I introduced the change and it was a failure. Okay. Let me look at it.” You probably get around much faster saying, “Oh, the problem is here. It’s fine. I’ll fix it. Deploy it again.” If it’s a big change, you’ll probably take a lot longer to get there because there was a lot of code that you put into production. What is happening? You have to pull in a lot of people. So you work on this piece, you work on that piece. What the hell is going on? Most likely your time to restore will be impacted because you will take longer.

And of course, lead time for changes will also be impacted, right? So if you introduce a small change every single day, deployments will be a lot faster. If you introduce a big change that is in a lot of services, deployments will be more complex. That’s another thing actually interesting to measure. It’s about the complexity of the deployment. If I need a coordination between services, if I’m introducing a big change, it’s something that I need to take into account in this consideration.

Of course, something that people usually tell is like, oh, okay. But for me, for actually to introduce smaller changes, I need to write more code. Oh, because maybe I need like some feature flag or something like that, or maybe I need to introduce somewhat of incomplete code just so that I can guarantee that it’s working in production. That’s true. But it’s usually at a very small scale, right? So maybe you need to, just to ensure that even if the feature is not complete, that the code that you’ve written doesn’t break anything that is there. Right? So maybe you need to put some defensive measures, like, for example, a feature flag just to make sure that no request passes through that code. That’s true, but it’s usually very small in terms of scale, and you can revert it back really fast. Reverting a big change is much, much harder.

So, just to summarize around that, I understand the concern, but it’s what we usually see. And when you use these metrics as a whole, it’s that when you introduce a bigger change, usually other metrics are impacted because you introduced a big change into a system. You’ll have more problems. You’ll take a lot more time to restore. And if deployment frequency is usually higher, it means that you’re not introducing big changes every single day. You’re introducing small changes, and you can recover much faster and deliver it at a higher speed. And what we see, actually, it’s something that there’s always a discussion about if you’re going faster, you break more things. If you look at the data from the past six or seven years from the DORA metrics, that’s actually not true, right? So, the teams that actually deliver faster and they’re deploying more frequently, take less time to restore service and have less failures.

I know that this might sound counterintuitive, but it’s what the data shows. It’s not like us saying, “Oh, this is like a utopia.” No, it’s what the data shows us is that if I deliver smaller changes more frequently, I actually introduce less failures into my system. And when I do, I’m much faster to recover.

Kovid Batra: Totally. I think it makes sense also, even though it might sound counterintuitive, as you said, but it definitely makes sense. If you’re bringing in a small piece of change, the error percentage, keeping it the same, the amount of absolute error would be much less. So, of course, it definitely makes more sense to deploy frequently.

I think the challenge comes in with the part where people want to set up, need to set up that pipeline for automatically deploying and doing it fast. That’s where the sluggishness comes in. But I think it is very important to have such a system in place if you have the bandwidth and the right team to do it.

Ricardo Castro: I understand that that’s an upfront investment, but it’s something that we can look at the data because again, it’s not me and you just having a conversation and sharing our opinion. It’s like we have data. We have data on that that actually can tell us, yeah, this actually works. So, although there’s an upfront cost and an upfront investment, the data tells us that at the very least at the medium term, you will start getting a lot of benefits. And if you’ve been in the industry for a few years and you have the chance to actually work in this kind of way, you start to realize that yeah actually, it is, right? So it’s not something that I heard someone talking, like someone from Netflix saying that in their organization, it’s awesome. No, I actually experience that on a day-to-day basis.

Kovid Batra: Yeah, yeah, yeah. Makes sense. Great, Ricardo. I am totally infected by the energy you have and the way you explain things. There’s definitely a lot of depth in what you are saying here, and maybe these 30 minutes are not sufficient. We might need another session for deep diving into certain issues like that. And I would love to have you for another show sometime again.

Ricardo Castro: Yeah, that sounds great. We can arrange something like choose a topic and go deeper into a topic. I’ll be very happy. I’ll be very happy to have that discussion with you. It was a very nice conversation that we had today.

Kovid Batra: Great, Ricardo. Thanks a lot. I hope our audience likes it too. Great. So I’ll see you soon and keep you posted.

Ricardo Castro: Thank you very much, Kovid. Thank you very much for having me. It was a really nice conversation. I think it’s something that is on top of everyone’s mind. People hear about DevOps, SRE, Platform Engineering, CI/CD. And it’s good that we see like-minded people just having discussions. We agree on some things. We don’t agree on something. But it’s out of these discussions and out of this brainstorming that we can actually, can start to get solutions with our organizations. So, I think it’s nice that we have a broad spectrum of opinions because again, my company will be different from yours and probably, what works for me might not work for anyone else. So if we have a broad spectrum, we can say, “Oh, actually what Ricardo was saying applies to my company.” “Oh, actually what Kovid was saying actually applies to me.” And people can, can make their own minds.

Kovid Batra: Absolutely. Absolutely. Perfect. Great, Ricardo. Thank you. Thank you so much once again. Great to have you on the show.

Ricardo Castro: Thank you very much for having me. Thank you.

‘Engineering Leadership 101: Key Skills and Transition Tips’ with Claus Höfele, Head of Engineering at On

In the recent episode of ‘groCTO: Originals’ (formerly: ‘Beyond the Code: Originals’), host Kovid Batra welcomes Claus Höfele, Head of Engineering at On and the author of the newsletter ‘Drawn to Leadership’. He has a rich technical background at the Doctari Group, eBay Classifieds, Sony Ericsson, and more. Their conversation revolves around ‘Engineering Leadership 101: Key skills and transition tips’.

The episode begins with Claus sharing the core function of his company ‘On’ and the inspiration behind his newsletter. Following that, he explores his definition of ‘Leadership’ and describes his journey from a software engineer to a leader. He also offers insights into his role as a Director of Engineering, managing multiple teams, context switching, and escalations, particularly in lean structures or during hiring phases.

Lastly, Claus delves into defining success for engineering teams and discusses his significant success as an Engineering Director and the contributing factors.


  • (0:06): Claus’ background
  • (0:30): What does the company ‘On’ do?
  • (1:06): Inspiration behind the newsletter & sketches
  • (4:59): Claus’ passion for traveling
  • (8:32): Claus’ definition of ‘Leadership’
  • (10:32): Transition from software engineer to leader
  • (14:45): Does transitioning to a leader reduce tech contributions?
  • (17:27): Defining the role of an Engineering Manager
  • (20:22): How to handle context-switching as a Director of Engineering?
  • (24:14): Defining & measuring engineering success
  • (25:50): Standout success moment in Claus’ career

Links and mentions

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an interesting guest. He’s the author of ‘Drawn to Leadership’, who summarizes leadership concepts through sketches. He’s currently working as an Engineering Director at On. He has 15 years of engineering and leadership experience. Welcome to the show, Claus. Happy to have you here.

Claus Höfele: Thank you for inviting me, Kovid. Great to be here.

Kovid Batra: The company name is really interesting, “On”. Could you tell our audience what does it do?

Claus Höfele: Yeah. Yeah. So, the company produces, well, running shoes, sports apparel, etc. So, I think maybe you’re switched on or it’s switching on the exercises and movements. Um, so it’s a company, coming out of Switzerland, but I’m based in Berlin where they have a tech hub, and,  yeah, where I’m supporting different cross-functional teams, software teams, working to make logistics and yeah, producing the right types of, of shoes.

Kovid Batra: That’s so cool. Nice. And tell us something about your newsletter, the blog that you write, the sketches that you make. I checked them out and those are really interesting. For our audience, we’ll share the link in the comments when we post this out, but tell us about from where did that inspiration come in and what was your thought while bringing this to the audience.

Claus Höfele: Yeah. So, when I was a software engineer, I often went to conferences and shared my know-how about software development. And then, I got into leadership and I’ve been doing this for a while. And then recently, I felt like, hey, I could maybe do a podcast or maybe share my knowledge in a, in a newsletter. And I thought sketchnotes is an interesting twist to it because you can summarize different concepts in a very good way. It’s maybe sometimes a kind of a visual aid, like to memorize the concepts. Sometimes it’s, you know, bringing the gist out of these concepts on point and yeah, I’ve started sharing this in a newsletter. I’m pretty active on LinkedIn about, you know, sharing my trials and tribulations of leadership. I felt I always received really good feedback learning from others, so I wanted to share something as well. And the sketchnotes, they are hand-drawn on an iPad. And I think, you know, it’s in a way also fighting my perfectionism, because hand-drawn is always a little bit imperfect or imprecise. And I think this balances out, you know, the world we live in. It’s often very digital and very, you know, exact and blue. And this is a bit more a playful way to approach leadership, which is important to me. I think we don’t have to take leadership too seriously. It is a big topic, but having playful ways to learn more about leadership, I think that’s important to me.

Kovid Batra: No, that’s actually cool. And I’m sure these visuals leave a very good impact on your memory. So, remembering those is much easier when you, like, listen to it on a podcast or maybe read it. For me personally, I would say the visual things are more impactful in terms of learning and remembering as compared to maybe listening or reading. Of course, reading brings a very different angle where you can have your own imagination; that can be good for a lot of people, but I really appreciate this way of learning. But, I’m more interested in from where this inspiration of sketching came into the picture. Like, is it a childhood hobby that you had or you recently developed it somehow?

Claus Höfele: Yeah, I think I’ve recently developed or found that kind of a skill or, for me, it’s a way to, to maybe live out my creativity. I like to write and also sketching is a bit, you know, maybe something I can’t do super-great, but you know, it’s always, you know, the process that I enjoy doing. And, yeah, it’s, it’s basically an outlet for my creativity.

Kovid Batra: Cool. Nice.

Claus Höfele: Fortunately, with the iPad technologies and good drawing applications, it’s also become much easier to do this sort of thing. So, on paper, it’s even, even harder, but with the assistance of an iPad and good drawing programs, it’s quite doable to learn this.

Kovid Batra: Yeah, I mean, using an iPad is absolutely cool because in the age of AI, when we are writing our articles with the help of ChatGPT, which definitely increases our quality of writing, reduces the time to write it. Similarly, I think that technology works for you, man. I really appreciate using such productive tools, for sure.

Cool. All right. So this was a great thing that we got to know about you. Apart from this, do you love travelling? Have you travelled to different countries?

Claus Höfele: So I, I used to live in different countries. I used to live three years in Japan and five years in Australia. So, I have bit travelled the long way around to Berlin. So, I’m originally from the south of Germany, but then spent nearly a decade abroad and then came back to Germany and since then, I’ve been living in Berlin. It was an interesting experience. So, my wife is from the UK, so we were also looking for English-speaking countries and I took some opportunities. So, Japan was an opportunity that I had working for the right company and being at the right place at the right time. So we spent a bit of our time working and living abroad.

To be honest, now that I’m back in Germany, it kind of calmed down a little bit. I mean, COVID also helped, but now I’m feeling like, hey, Berlin is great. There are lots of things to see and do here, so I’m not travelling that much any longer.

Kovid Batra: Cool. Japan, Australia, back to Germany. I’m not sure how Australia and Germany would be a different experience for you, it sure is, but Japan would be a drastic culture change, right?

Claus Höfele: Yeah. Yeah, definitely.

Kovid Batra: And I have heard a lot about Japan. So, any specific learnings from your experience at Japan? Where were you working? What were you doing there?

Claus Höfele: Yeah. I was working for a joint venture of a Japanese and Swedish mobile phone manufacturer. And, so they were kind of, they had people from a lot of cultures, right? And yeah, I think Japan was a very interesting experience. So, I mentioned that my wife is from the UK, so Australia was a little bit more planned and thinking, hey  this could work out also with, with the language, but coming to Japan, it was yeah, I want to say super-exotic, very different experience. I was super-curious, and learning and getting to know the culture. So they have a, have a very strong work ethic, but fortunately, also for maybe foreigners, they take it a bit easier on you. So I really had a great time getting to know the country. In the end, I didn’t speak the language too well. I started learning, but of course, it takes some time. So, in the end, it was something we did, but then moved on to Australia.

Kovid Batra: I think learning different languages impacts your processing, the brain processing in a very different way. Did you experience something, like when you were learning this language, how is it different, and how it impacted you when you were trying to speak in that language, think in that language?

Claus Höfele: Yeah. I felt very inspired by also the the, the Japanese script. I mean, they use like, different alphabets, at least two alphabets and also Chinese symbols, right. And Chinese symbols, maybe this, you know, ties in with the sketchnotes, you know, it’s very, it doesn’t exactly say.. It has a kind of an implicit meaning, right? That, and I, had a really interesting book, like also trying to, you know, see the meaning of the Chinese symbol inside this symbol, you know? Maybe it kind of mimics a bit. “Tree” would kind of mimic sort of the shape of a tree. So, it’s a much more intuitive approach to, to writing, to reading and writing, that felt very strange to me, but also super-interesting.

Kovid Batra: Cool. Cool. Coming back to your blog, newsletter, sketching, it’s all about leadership, right? You’re guiding people who are aspiring leaders for tomorrow to lead better teams, right? So let’s start talking about something there, like how do you define leadership? What leadership is for you?

Claus Höfele: So, I think first of all, leadership can happen on any level. Like, it’s not necessarily a position. That said, if you are a manager, it’s hard to imagine being a manager without having leadership skills, right? So maybe for managers, it’s more important, but I think it’s totally true that, you know, anybody can be a leader by showing, you know, by being proactive and kind of guiding other people to put outcomes. And, the way I define myself as a leader is that I have a background as a software engineer, but I’ve been, you know, hands-off from programming for quite a while. So, I don’t feel I want to have or need to have the solutions any longer. I see my job as helping other people to get to the right solutions. So, I’m spending a lot of time also planning workshops or trying out different techniques to involve as many people as possible, um, to have everyone have, have a say, but still, you know, make good outcomes and good progress on the problems that we’re working on. For example, running, like team kickoff workshops, or maybe also online sessions to tackle a problem. And, what’s working really well, for example, is Miro or doing this in-person. And I think these workshops, what they all have in common is that it’s a structured way to kind of channel creativity into really good outcomes.

Kovid Batra: One important takeaway from your definition of leadership is empowering people, like that’s where your success lies and that’s what true leadership is. Cool. I think that’s a very interesting start.

You said your journey started from a software engineer to leadership. And I believe a lot of my friends and audience listening to us are in that journey itself where they would want to know about this transition, how did you make your decision, what was your role and responsibility, probably as an Engineering Manager, and then as a Director now, what kind of things you do, so that the people who are looking up to these profiles, these roles and responsibilities in their companies have a good idea of what it actually looks like. So, can you just tell us about your experience, starting from Software Engineer, then transitioning to Engineering Manager, and then leadership?

Claus Höfele: Yeah. Yeah. It’s indeed an interesting transition because the realization is that management and software development are two different positions. And of course, the domain or the companies that you work in are similar and maybe they have a similar domain, kind of challenges, but what do you actually do day-to-day is very different. So, it was an interesting transition. And it started with me being a Software Engineer. I’ve done a lot of work on mobile phones. And I also programmed a PlayStation game and bit by bit, I kind of became more of a, like a Lead Engineer. I had a very good experience and good success in actually developing different kinds of software. And my first step into leadership and management was as a Tech Lead, which every company defines this differently, but the way it was defined at the time was like, you still had hands-on work to do, but you also started to manage people. And I find this is a super-challenging position because, it involves, you know, two different kinds of jobs basically.

Kovid Batra: Right.

Claus Höfele: But it’s also like interesting because it’s kind of the first step into leadership. So, it allows you to kind of try out, hey, what is this about? Try yourself out and also see if that’s an interesting career for you because I think at some point you need to make a decision: do I continue on the Individual Contributor path or do I continue on the management path? So, I had this Tech Lead position and this was still very involved with my technical expertise of mobile app development. And then, the next step was what I would call an engineering management position, which means that it was a technology that I knew, but wasn’t super-experienced in. And I think this is also maybe a learning from management that you often support different kinds of teams where you understand the general technology, what this is about, but you probably have less hands-on experience than the most senior engineers in the team. And I think as a manager, you need to become a little bit flexible in, you know, what kind of teams and what kind of tech stacks you manage.

And then from there, it kind of evolved into managing multiple teams. So, that’s a bit how the Head of Engineering or Director of Engineering position currently is defined, that I’m supporting multiple teams, we are currently at the brink of also introducing team leads and engineering mentors for the teams, but currently, I’m managing these people directly. So, it’s kind of another level of indirection, right? So, as an Engineering Manager, you directly interact with one team and directly manage people. And then as a, maybe Head of or a Director of Engineering, it comes like a bit more indirect by managing other managers as well. And yeah, it was an interesting transition because I was able to kind of maybe try myself out, also like phasing out the actually hands-on programming, and then bit by bit coming more into this role. But it took, I feel it took like several years to actually, you know, understand what this is about, to find my way, you know, my definition of leadership. And yeah, it was an interesting journey. And it still continues, right? It never ends what you can learn.

Kovid Batra: Thanks. I think, I made you speak a lot on this one, but I have some really good thoughts around the point where you said that when you transitioned from a software engineer to a tech lead, then to a manager, I could see in every expression of yours and the words you said, the role becomes more towards taking care of the people and the technical skillset, of course, carries along because that’s innate to this particular department, or I should say, that vertical of the business where you are leading tech teams. But, as you go up the ladder in this journey of management leadership, is it for everyone, or it depends on company-to-company, how much technical contribution do you put in as a manager, as a tech lead, and as an engineering leader, I would say? Does it go narrower on that side? How does it work according to you?

Claus Höfele: I think it’s what is a tech lead, a team lead, an engineer mentor is, is often different companies have different definitions. And I think if you go beyond maybe supporting four or five people, I think it’s super-hard to still continue to be hands-on with the technology. So, my goal is to understand the problem, the technical problem that we’re working on, but my goal is not any longer to actually be able to solve it myself. And, yeah, this is basically a decision point where you also have to make sure you want to let go of software development because it’s, it’s really an amazing job. Unfortunately, there are a lot of opportunities. Like, if you go into Staff Engineer or if you work as a Principal Engineer, right? There are lots of opportunities to also show leadership, technical leadership on a, on a very high level with a very good pay and position, maybe online with different management.

Kovid Batra: Right. I think that’s where you have to take a call, what is your feeling or what is your call that whether you want to go for a technical leadership role or you want to, like actually become an Engineering Manager and then take business-oriented roles.

Claus Höfele: Yeah. And, I think being a software engineer as a background to becoming an engineer leader is quite challenging because we have to let go of quite a few things. First of all, I think you have to let go of this idea that you need to be the best engineer. I think this takes a lot of mental effort. And you also have to let go of, “I’m now the lead.” Or, “I’m now the manager. So, I get to say what people are doing.” I think you have to let go of this thought as well. And, and having a technical background, this is often the challenge I see.

Kovid Batra: So basically, the technical understanding that you gain from the previous experience of being an engineer and then Technical Lead, that helps you as a manager and a leader to probably give better estimates and be more empathetic towards how the work is done, which probably the business side doesn’t understand or relate to in most of the scenarios. So, if I’m not wrong, is it that the main skill set of an engineering manager or an engineering leader is to definitely manage teams better, lead them better, bring in the cultural aspect that motivates them, keeps them satisfied, and along with that, be properly answerable to the business by understanding the context of technology? Does that sum up the overall role of an Engineering Manager or an engineering leader in an organization?

Claus Höfele: Yeah. What’s the difference between management and what’s the difference between leadership, right? And the definition I really like is that leadership is all about people. So what you said the culture of working together, the cooperation and managing is about things, you know, timelines and money and projects, right? And I think as an engineering leader, you need to handle both. But you can’t mix, you know, both sides need different approaches. So of course, what I’m doing day-to-day, a lot is also, you know, hiring new engineers, making sure we hire the right talent, also making sure that teams are set up for success. I work with the teams on, yeah, maybe kicking off things or also handling conflict. And also, maybe celebrating. I think it’s end of the year, it’s really important to also celebrate the achievements. I think this is all about the people in the culture side. And then, the management side is, of course, also about, you know, budgets and being able to handle head counts and maybe HR wants you to fill in certain forms, and of course, also with  dealing with a stakeholder. I would define the role of a Director of Engineering, maybe as a translator between the two kinds of worlds. So maybe, translating technology problems into a language that business can understand and vice versa, understanding their point of views and translating that into a language that technical teams understand. And then, on my level, it’s also a lot about maybe working at the overarching problems, like maybe defining a technology roadmap that affects multiple teams. So rather on a team level where the team directly works, maybe with the business department, I’m more looking, you know, how are the teams generally set up, how does the collaboration work and what is maybe the technical roadmap that affects multiple teams.

Kovid Batra: Right. Makes sense. I think one very important point here, you mentioned that right now you are leading, you’re Director of Engineering. Ideally, it is supposed to be a bunch of managers and tech leads working along with you to deliver, right? But in this stage, you are directly dealing with multiple teams. And I’m sure this is a situation with a lot of companies where Directors of Engineering are directly involved with their companies. Maybe they’re hiring right now, or maybe that’s a lean structure that they’re following due to cost-cutting. The most important problem one could face is context switching, right? Different teams are working on different technology, different problem statements. A lot of things get escalated in that form. Of course, there would be some people who would be, like Senior Software Engineers, but would be helping team members to solve those technical challenges. But what happens if in this, a lot of escalation comes to you, how do you handle that? And along with that, you have to do your own piece of work also, right? So, managing all this as a Director of Engineering where you have to handle multiple teams, how is that experience coming out for you?

Claus Höfele: Yeah, definitely. The management, a manager’s schedule is very super-fragmented, right? I try to block out some time also to do some more strategic thinking and have a bit more time to do, you know, deep, deep work, but at the end of the day, a good part of the job is really, like having different kinds of context, which is all over the day. You cannot completely control this. So usually, the way I work with the teams, obviously I cannot attend every meeting, but I usually define with every team a little bit on, you know, how would I be in touch with the team and with the people on the team. So, I have a lot of 1-on-1s, where we discuss potential challenges. And, I also kind of attend a few meetings, uh, one or two meetings for each team, so I get a bit of an impression on how they are working and how they are also collaborating. And, in terms of conflicts and maybe incidents or stuff coming up, I think it’s really important for me and for, for leaders in general that they try to keep the business out of their schedule, right? Like, I see, or I’ve been such a leader as well, where you have from nine o’clock in the morning to six o’clock in the evening, you know, a meeting scheduled every half hour. And, you know, I have absolutely no downtime. First of all, it’s, it’s really bad for, for your mental health, but it also leaves no space for unforeseen things. And I feel you really have to also leave space open in your schedule that people can come to you, “Hey, I have clouds, I have an issue. I want to discuss that with you.” And, to organize your work in a way that you know, you have deep work, you can do this context switches, but also you have time for unforeseen work, which always pops up, right? I think this is a real challenge, but, that’s a bit the way to make this work.

Kovid Batra: Yeah. Yeah, absolutely. I think scheduling your day properly, compartmentalizing things that you want to do would be the first step for anyone to handle chaos, right? So, definitely a good piece of advice here.

Claus Höfele: And in the end, it’s also, you know, if you feel that you have too much on your plate, it’s also about finding people to delegate work towards, right? Like, it’s always a really nice, like a step-up challenge for other people to maybe get into hiring or to tackle important projects. So, I think a lot of leadership is also, you know, if it’s too much, getting too much for me, then I also have to organize my team in a way. And often people feel really great about these sort of challenges.

Kovid Batra: Right. Absolutely. One thing that pops up in my mind is that when you’re leading so many teams, you have so much going on in every team each day. How do you look at their success, like whether they are achieving on a sprint-basis or daily basis or monthly basis? How do you define that success for your teams? And, what kind of methods you use to actually measure that success?

Claus Höfele: Yeah. So, I’m not too much metrics-driven. In this regard, for me, it’s more a bit like a quantitative approach to having checks on the team. So, I’m attending team meetings and I see how the collaboration works. I’m in touch with them on 1-on-1s. At the end of the day, of course, also the business, the stakeholders of the team is a good feedback board to understand, you know, how well, does it currently work. And, I think for me, it’s not so much about, you know, pushing people to work harder and faster; it’s more like setting up a system that, you know, people can do their best work. So, I need to be able to organize, you know, the collaboration, the teams and how they work together in a way that, people naturally will want to do a good job. So, I’m responsible for the system, not necessarily for the day-to-day operations and outcomes.

Kovid Batra: Right. Makes sense. Makes sense. Perfect, Claus. I think that was a great talk and it was really interesting to have this discussion with you. Before we leave, I think it would be really amazing for our audience to know: what could success for an Engineering Director look like? So, just tell us about maybe one of your successes that you feel that you have accomplished so far in your career as a manager or as a leader, and what made you achieve that? Just, if you could think of an experience from your career.

Claus Höfele: Yeah, I feel the major of success of my career was also that I feel I always adapted to new challenges. So I had a really good time as a Software Engineer, but then also I felt, you know, what’s the next thing? And I was a lot into maybe user experience and understanding this kind of perspective. And I got into management and now I’m getting a bit more into facilitation. So, being super-adaptable, understanding that maybe what you have, the kind of approaches that you have used before might not work in the next challenge that you are tackling. And so, always be adaptable and always growing and always learning. I think this is my pleasure as well, because I think learning and growing is really good fun.

Kovid Batra: Cool. So, that’s your success mantra then, “keep growing.” Cool. All right, Claus. Thank you so much for your time today. Would love to connect again, discuss deeper into different aspects of management and leadership. And audience, please follow Claus his newsletter. We’ll share the link in the comment section.

Claus Höfele: Thank you so much, Kovid. It was a, was a great discussion. Thank you.

‘Tackling Communication Gaps in Cross-functional Teams’ with Ariel Pérez, VP of Engineering at Split

In the latest episode of ‘groCTO: Originals’ (formerly: ‘Beyond the Code: Originals’) host Kovid Batra welcomes Ariel Pérez, VP of Engineering at Split. He has also previously contributed his expertise to JP Morgan Chase & Co. and Berchbox. The core of their discussion revolves around tackling communication gaps in cross-functional teams.

The podcast begins with a fun fireside chat with Ariel, during which he shares his passion for Latin dance and recounts a pivotal moment in his life. Later in the main section, He delves into his daily tasks and the challenges he faces at Split. Ariel stresses the importance of fostering trust and transparency through open communication channels and streamlining the onboarding process for engineers to better equip them for problem-solving within complex team structures. He also sheds light on assessing engineering success by not solely relying on DORA metrics but also addressing the age-old question, “Are we building the right things?”.

Lastly, Ariel offers parting advice to the engineering leaders, encouraging them to recognize environment-building as their primary responsibility.

Time stamps

  • (0:06): Ariel’s background
  • (0:33): Fireside chat
  • (6:45): Ariel’s core tasks & challenges at Split
  • (11:13): Strategies to bring teams on the same page
  • (15:54): Handling cross-functional collaboration at scale
  • (21:31): How to streamline onboarding for engineers in a complex team structure?
  • (25:15): How to assess the success of engineering teams?
  • (29:31): Aligning engineering teams with business values
  • (33:10): Parting advice for the audience

Links and mentions

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who has 20+ years of engineering and leadership experience. Currently, serving as VP Engineering at Split for Measurement and Learning. Welcome to the show, Ariel. Happy to have you here.

Ariel Pérez: Thank you for having me, Kovid. I’m glad to be here.

Kovid Batra: Great. So Ariel, today I think we’re going to have a good time, good talk with you regarding your experiences throughout your career, engineering leadership, but before we jump into all that, I would love to know more about you, our audience would love to know more about you. So, we have this quick fireside chat wherein we’ll ask you two or three questions from your personal space. I hope you would be comfortable answering them.

Ariel Pérez: Absolutely. So let’s dive right in. Go ahead. What are your questions? Shoot.

Kovid Batra: All right. So, let’s start very simple. Your passion, your career is all around tech, right? But there must be something that you love outside of tech. What is it?

Ariel Pérez: Outside of tech, if I were going to say, two things. One of them is people understanding, how people work and understanding how people think and feel and get motivated. So that’s a big piece there, people in general, understanding what makes people tick. The other one is actually dancing. I have been,  you know, not as much recently, but for the past 20 years or so, a little, actually more than that, I’ve been a professional dancer, primarily in Latin dance, Salsa, Cha-Cha, Bachata, Afro-Caribbean dance.

Kovid Batra: Oh, nice. That’s really nice. Great. Next question. How has your interest in doing what you’re doing right now evolved over a period of time? Like, whether it be dancing, whether it be tech, how have you seen that evolving over the years?

Ariel Pérez: I think, you know, in the early part and, you know, I can say this is probably similar for many people. Of course, I’m basing it on my experiences. It’s trying to get better, trying to get proficient at the thing I was doing, whether it was dancing and trying to get really good at dancing salsa and getting better and better and better. So, going very deep in salsa. And then later on trying to get some breadth. I think the same thing in my professional career, you’re trying to get better at software development, trying to get better at coding, trying to get better at coding practices, individual coding practices, and then going deep on, let’s say Java or C++ at that time. And then as I built more skills, it wasn’t as much as going depth, but building breadth. And the breadth on this, on the engineering side was everything from different technologies, different parts of the stack to different domains and more complex domains. And then further than that more about people management, leadership and product. So, along three different axes, he’s building breath and becoming more T-shaped, I would say.

Kovid Batra: Oh, that’s a good thought actually. So, what did you learn when you started, let’s say they talk about salsa, right? You said going into that depth on like initial day or initial months of your learning to becoming a proficient salsa dancer. What was your thought change around that dance form?

Ariel Pérez: I think for me early on was, well, it was something I enjoyed doing. It was something I could go out social dancing and enjoy at a club beyond just learning in a class and practicing. I think for me early on, it was, ” Why does this work this way?” I think there was an aspect of my, the engineering mind and, you know, background and training and, you know, and engineering and university. I wanted to know how things work, not just, “Here’s a movement, here’s how you do it.” It’s like, well, hold on. Why do we do it that way and not this way? Why did my feet have to be here and not there? How does the timing work? Why is it on this timing versus that timing? That was a lot of my initial focus, because for me, those were the core basic fundamentals that were required, not just learn a bunch of moves which a lot of people do. It’s like, well, hold on. I want to have the basis and the foundation to then build moves on top of that because that foundation never goes away. That foundation becomes the way for you to really put things together later on. As opposed to learn this, learn this, learn this, learn that, but you never learn the ‘why’. So I think that’s been a very important piece, the ‘why’ of why we do certain moves. And then after that, once I had that strong foundation, completely flying through and building the repertoire, here’s another move I didn’t know. Here’s a different move I didn’t know. Learn from this instructor, learn from that instructor. Add these to that foundation that keeps getting bigger and bigger, but it allowed me to go faster and faster through learning each of those things because the foundation was there.

Kovid Batra: Cool. Nice. I mean, everything that you do, be it a hobby or anything, I think this approach would be really nice to have, actually. And I mean, that helps us keep going. Great. I think amazing.

One last thing, what has been your biggest life-changing or life-defining moment? Of course, there would have been many, I mean, we are not just formed out of one experience, but just one which comes to your mind right away.

Ariel Pérez: Um, The birth of my son. My son was born in 2017 and I had just taken on a new role. I think what I’ll say about that in terms of life defining is in many ways it changes my perspective on how I prioritize, how I make decisions, how I have to care even more deeply than just what’s necessarily good for me, thinking about what’s good for my entire family and how is that everything I can do, at the end of the day builds a better life, a better future for my son now. And thinking from that perspective not that things that are important to me are no longer important, but now I have another angle to look at things from. And also, even a longer term perspective than, you know things beyond my own lifetime. Like, that’s something, that’s something, that idea that changes in your head, like not only am I thinking about my lifetime, I have to think about beyond my lifetime, and what do I, how do I prepare my son for things that will happen beyond my lifetime, because ideally, of course, I expect that his lifetime will extend past mine. So it changes the time horizon of the things I’m thinking about and considering.

Kovid Batra: That’s super cool actually. I mean, I am not a father, but I have spent time around kids and I definitely can just relate a bit to it, like when you transfer that learning of your life to the person, to the child, and then help them grow and learn in certain direction, caring about them, understanding their emotions, even when they’re not able to express it the way you, you might understand. I think a lot of things change when you have a kid around yourself. So cool. I think that that’s true.

All right. Thank you so much for this beautiful, beautiful intro. I think let’s jump on to the main section where we get to learn more from you about engineering and leadership. So let’s start with your current role of VP Engineering at Split, right? What’s your day-to-day responsibilities and to-dos look like and how do you navigate through them?

Ariel Pérez: Yep. I mean, I think my day-to-day revolves primarily around creating the right environment for my team to grow and develop, make the best decisions that they can, feel unblocked on any decisions that they need to make, and at the end of the day, can deliver value to our users. That’s primarily, you know, that sounds very generic, but that’s really what my day-to-day focus is on. It’s creating an environment, that’s the big pieces. My job is to create the environment for success. What does that mean? In many ways, it’s, you know, discussing and really being on the same page with the SVP of Engineering and look at engineering as a whole. It means meeting with my managers on a regular basis, understanding how their people are doing, how the people are progressing and growing and understanding blockers and challenges. It means connecting and regularly meeting with my product peer, then to co-create strategy, understand strategy, what are the biggest problems and where we’re going and leverage all that information to really, you know, prepare and enable my teams to achieve success.

Kovid Batra: So, as a VP of Engineering, when you say your primary role would be to get software delivered from the software teams that would take care of the business as well as the tech strategy, right? So it’s a kind of a role where you bridge the gap between the tech teams and the business teams to head into the right direction for the company goals. While doing this, I think one important thing you just mentioned about managing the people, right? Making sure that they are having the right context, right mindset to deliver, right? If I understood you correctly, this is what you mentioned about, like when you’re talking to your managers and then trying to understand whether people have the right direction and context or not. At scale, I hope I got you right over there?

Ariel Pérez: Yeah. Well, there are three things that would change there as actually, or slightly adjust.

Kovid Batra: Yeah.

Ariel Pérez: One of them, while this may happen in many organizations, it’s something I’ve, you know, I think I tend to focus on and it ties back to what I said. One of my other big passion outside of just my day-to-day work is how people work and what makes people tick. So because of that, I don’t necessarily see myself as the bridge between technology and product and the business. I am one of the people on that bridge, but in reality, my job is to make sure that my entire team is on that bridge and is connected with the business day in and day out. So, I think that’s a key part of how I think about the enablement of my teams, because then I don’t become the bottleneck. Then I don’t become the translator of from the business perspective over down to the engineering teams, which happens in many organizations, right? There’s an engineering chain. There’s a (quote unquote) “product” or “business” chain and never shall the two speak, except at like management and leadership levels because of that, your teams, the people on the ground lose a lot of context, lose a lot of understanding, and they’re forced to go through translation layers where you lose things. So that’s one of the big pieces. I am not the bridge. I am part of that bridge. I enable that bridge to be built. I enable that bridge to become much more open. And I create the environment for my engineers, especially to be in that bridge on that bridge all day, day in and day out as part of the work they do.

Then the second thing I was going to say is like, you know, when you were saying, yes, the important, my job is enabling to create a context for my teams. That’s part of it, but it’s really more about not creating context. That’s an aspect. It’s removing all the impediments, all the roadblocks, all the challenges that stopped them from doing the best job that they can. That’s, I think, even more important. Context fits within that way of thinking about it.

Kovid Batra: It’s one part of that, yeah.

Ariel Pérez: Context is one part of that. It’s like whatever stops them from solving the right problem, that’s my job to deal with, remove that impediment. And that impediment can come from anywhere. And that’s the key piece. It doesn’t stick to just the engineering realm, just the coding realm, just the technical decisions realm. It’s anything that stops them from doing the best job that they can. That’s my job to get rid of and figure out how to get rid of.

Kovid Batra: Totally. Makes sense. I think I was about to ask the next question that, at scale, how do you handle this where you can actually bring context to the complete themes and actually bring them onto that bridge where you stand. So, I think you answered it in a way for me. But I think I’d love to take a deeper dive into this where I would want to understand from you with certain examples of execution that you have done to bring the teams onto that bridge with. In general, what I hear is that only the leaders are doing that job. So, yeah.

Ariel Pérez: Yeah, absolutely. So, I’ll keep going back to this idea, it’s like my job is to create the environment, right? So, one approach that I’ve seen very often, right? It’s like I speak to my engineering managers. Those engineering managers speak to if they’re, you know, depending on how deep the stack is, they might be speaking to their engineering managers. And those people speak to the engineers. And I set strategy as a whole. I set processes as a whole. I set guidelines as a whole. And I don’t do it myself, right? I get it from the ground up and understand what’s necessary and working with my team. So, we figure out the strategy and then communicate it downward, right? So that’s one way, one approach, right? And I’m not saying that’s my approach. I’m saying it’s an approach you see very often. So I work through my managers to really set strategies, set goals, set approaches and understand what is needed, and I communicate context and vision and downward.

Now, an alternative approach is the following. I lean on my teams to figure it out. And that’s not, you know, that’s easier said than done to say, you know, it’s not saying, “Hey, here’s no context. Here’s no help. Figure it out.” Right? You figure out the business context. You figure out how to work. You figure out what are the problems and you figure out how to solve them without any empowerment, without any enablement, without creating the right supporting structures for that. The key piece that I focus on and really care about in execution aspect is ensuring there’s always a two-way street of communication up and down. That’s one piece of it. And it’s free-flowing information and creating the trust and transparency necessary for that. That takes some time and effort. Make sure that people feel always confident in escalating issues, challenges, concerns, and blockers upward and also down, you know, across to each other. And then I think the key piece is asking a lot of questions. Even if I might feel I know the answer and I often feel, you know, often as leadership, we often feel we do because hey, we’ve been through this. We’ve seen it. We’ve seen a lot of things. We feel we know the answers, but it’s important to listen a lot more than we speak. And I struggle with that, right? And 100% honest, right, I struggle with that. It’s important to listen more than speak. So, ask a lot of questions of your people in terms of, for example, how would you do this? Why is that a problem? Why is that a problem right now? Who does that affect? You know, what would you do about that? And then if they propose solutions or alternatives, well then what might go wrong with that alternative? Are there other alternatives? How many alternatives have you considered? There’s an aspect of just helping your people think through the problem as opposed to giving them the answer or giving them the actual solution, helping them work through the problem and actually saying that is the way we work and have however many levels down, have your people be very good at doing the same, driving downward on asking a lot of questions, helping people figure out the answers. for themselves. Why is that important? It creates an immense sense of ownership across the entire stack up and down. It creates an immense sense of involvement and beckoning inclusion and saying, “I had a part in this. I’ve been listened to.” And taking that back to when I thought about dancing and the importance of fundamentals, the importance of building the basic blocks, that aspect of people feel empowered, people feel included, people feel listened to, people feel like they have ownership; that is an important and critical building block for anything you want to do.

The other key building block is trust and transparency. And that’s hard to build, easy to lose. Building trust and transparency, we can speak openly about challenges and issues. We can challenge each other and question each other. But at the end of the day, we do that to make sure we get to the right answer, to the right solution or to the best answer and best solution we can together. We’re on this boat, we row together, and that’s how we figure things out. That becomes the basis for then all the hard things you want to do. This is hard on its own, but none of this is even about this technical problem or that business problem. This is all about building the right foundation as people to collaborate and work with each other and trust each other and depend on each other day in and day out.

Kovid Batra: Right. Now, taking this piece of collaborating with people day in, day out and working easily, probably within one team, you can set some structures, drive them towards certain aligned goals. And of course, like for a company, there would be specific goals that you’re achieving and then that translates into individual team initiatives and their goals and their results, right? But, when it comes to collaborating with cross-functional teams, like. engineering coordinating with product or engineering coordinating with design; at that time, as teams scale, I mean, this is kind of inevitable that that communication gap comes in, right? And there are a lot of other problems that start popping up. How do you deal with that at scale? How do you make sure that collaboration across teams when you scale is handled well?

Ariel Pérez: So, I’ll talk about two different kinds of collaboration across teams that needs to occur. One side is whether it’s product, design, engineering, which in my mind actually, those shouldn’t be separate teams ever. Those are the same team, right? Where some places call it the three in the box, some places call it the triad, but those three must be part of the same team, regardless of the management chain. But in, you know, in many places those are siloed. So, that’s one side of the question. The other one is different engineering teams cross, you know, collaborating with each other, right? So those are two different aspects.

Let’s talk about the first one. The first one, how would I solve that? One of the first things I aim for, push for it as part of any organization, ensuring that there is no division from the aspect of how these people work together, that these aren’t treated at separate pillars and silos. It means that product, design and engineering is one of the things I push for from the beginning. From wherever I am, either I join a place that already has that, or if they, if I’m joining it’s one of the conditions, I’m like, this is what’s going to happen and it has to happen, is that product, design & engineering must work together as a single team at all levels. And something I drive, whether it’s my peer on the product side at the executive level and work down with every team, I challenge my teams, my managers and the individual engineers to also push for their same with their peers. So, we push for this at every level and drive saying that communication barrier has to disappear. We work as one team all the time together. And that can take many flavors.

The other side of it is different engineering teams working together. And these can be engineering teams within my org or give me engineering teams across the org, right? You can think about vertical product teams. You can think about horizontal platform and enabling teams. One of the biggest ways, and I found, you know, found this to be very successful, especially in my own orgs is as much as possible, erase the boundaries between individual teams. Now that might sound almost like blasphemy, right? You might have, there’s an accounts, let’s think about the financial. I mean, there’s an accounts team, there’s a payments team, there’s an investments team or e-commerce. There is a, you know, a products team, there’s a subscriptions team. And you create those teams because you want long-lived teams that have, own a vertical slice of functionality end-to-end. And that is what we’ve learned for so long that is the best way to build things. The problem that occurs is that when one team depends on the other, the system breaks down very fast. And I’ve rarely, if ever been in any organization where any team is working long enough without a dependency on one other team, at least one other team, dependencies become one of the biggest blockers to progress because team one has their goals and their priorities. Team two has their goals and their priorities. When they need each other, the system breaks down because whose priorities matter more? And you can try to solve this at a higher level and say, well, let’s make sure we co-create priorities. But you’re still working from two separate places. So one of the things I’ve done with my teams in the past, you know, few years, especially at Split, and I’m not saying it was easy, is using an approach that blends the lines between teams and at the end, creates what’s called the more ‘super team’, which allows you to scale almost indefinitely. What does that mean? The team definition changes from an individual squad of let’s call it a ‘two pizza team’ or like a six-person team or nine-person team, right? The traditional size of team that we think about. And instead say, we have a superstructure of a fluid team, which is 30 people, 40 people in a fluid team. But now how does this work? Like, how do you create a team of 40 people? The idea is this. As the work comes in, as the priorities come in, that structure of 40 people fluidly breaks into smaller teams as necessary to attack the work. They might become three teams of 13-ish people. They might become seven teams of about six people. But the teams reform dynamically around the work that’s coming in. And they form dynamically around the work that’s coming in to make sure that they can actually adjust and take on dependencies. So, if you are going to work on something in a traditional structure, where one team depended on another team in this structure that doesn’t exist because those two, the folks from either side come together and they form one new team that now solves this problem holistically across the domains. So we can go, dive into this in so many different ways, but it’s dynamic fluid reteaming out of a bigger team, that bigger team creates the cohesion, the home, the static, a long-lived nature, but they can, they can reform and adjust and adapt to the problems at hand to get rid of dependencies as one part. You know, one particular outcome is get rid of dependencies, but there’s so many other outcomes.

Kovid Batra: Sounds really, really amazing to have such an ideal structure and I’m happy to hear that you are working in a similar style. My first question on that is that if these are the teams, any engineer joining the team would have to gain a lot of context before you can actually say that this person is equipped to handle any problem, right? So..

Ariel Pérez: Absolutely.

Kovid Batra: I broadly have an answer to my question, but still would love to hear from you. Like, don’t you think you would have to invest more time in the learning of anyone who is getting onboarded here?

Ariel Pérez: I’ll say yes and no to that question. One is, do I have to invest more time in learning? Absolutely. And yes, across my entire team, we have to continually invest on learning and that only pays massive dividends over and over. So that’s why it’s not a problem that I have to invest more in learning.

Now, in terms of onboarding someone new, that specific question, someone new comes into the superstructure of a team. The superstructure of a team has to figure, you know, someone coming in has to figure out the broad array of your domains, have to figure out all the services, all the technical aspects, has to figure out the interpersonal relationships. The way you help solve for that is, one of the things that’s hard to do in many organizations for many reasons, but it’s, well, in reality, no individual person works on any one thing by themselves. What do I mean by that? One of the things that happens in many teams, regardless of whether you’re doing Kanban, or Scrum, or XP, or whatever, you know, flavor of project development, project management style you have, this happens very often. Here’s a piece of work we have to do. It’s broken up into five pieces. We have five engineers. We’re going to get five engineers working on five things, right, on the five pieces. That creates many, many problems, many, many silos and knowledge and it creates many challenges with now we all depend on each other because this person can’t complete it with that person finishing. This person needs a PR review before people are working. So, how do you potentially solve for that problem? More people working on less things and working on them together in real-time. At the end of the day, what is that? It’s either a lot more pair programming and a lot more ensemble program.

Now let’s talk about where the question started. That one person that comes in and how do we get them enabled to understand the whole domain? One, immediately pull them into pairs and ensembles of programming because they gain a lot of context very fast from other folks. Number two, you start learning the team’s practices, the team’s techniques, the team’s shortcuts very fast, and you start becoming a lot more embedded into how we work and what we do and our domains. And you do that continuously and regularly. Why is it that that happens when you have an ensemble or when you have a pair? Because you have hands-on, real-time knowledge transfer between folks. But here’s the other piece. When you get into that level, you realize that one person does not ever have to have the full context of everything that happens. The context is shared across the team. Across the team, you have context of the whole thing. One person might have context of the whole thing, but you don’t need that because you don’t have single-person dependencies. The team as a whole understands the entire domain. And that’s the key piece here. That makes it easier to onboard the ensemble and pair programming, easily pulling you in, merging in, but also immediately ensuring that you’ve set the expectation that I don’t expect you to ever have the full context of the whole thing. You don’t ever probably ever have to have a full context of the whole thing, but the team as a whole does. That 40 percent superstructure of a team, that entire superstructure of a team has context over everything. That’s the key piece.

Kovid Batra: Totally get it. I think this is an amazing way to operate in here, starting with the very first thing where you not only bring context to a lot of people, which brings a lot of accountability also when you’re working on a day-to-day basis, but it also makes it easier for the organization, I feel, to deliver at a much faster pace and maybe not delivering too much, but delivering less with more effectiveness, I think. So, I think the structure really, really works well, I hope.

And with that, I think one question that comes to my mind is that when you’re looking at making the engineering team successful, what are your parameters of success for an engineering team and how do you go about measuring those?

Ariel Pérez: Okay. Awesome. Assuming we have the piece of trust and transparency and the constant working and collaborating closely together. That’s one aspect, right? Like, how easily does information move around the team? How easily does information move up and down? That’s one aspect. And how you measure that, that’s hard, but part of it is constantly speaking to people. And actually, me as a leader, skipping levels and talking directly to folks at every level and making sure I can also hear them. So there’s a question of triangulation of the flow of information. That’s one side of it. I don’t know if I have an exact measure of that, but there’s a sense and a gut of these things don’t line up. Now, moving beyond that, right? Assuming that the communication lines seem clear and open and there’s transparency and candor. Then I start thinking about, as a baseline, you know, my engineering metrics. And I, you know, there’s no need here to reinvent the wheel. I do think, you know, the DORA metrics are a really good starting point. What the DORA metrics help us measure and understand is how good are we at shipping quality code regularly. That’s the way I’ll call it. I didn’t say solutions. And I didn’t say definitely like value because there’s no guarantee in that. But, can I get really good at shipping code regularly without breaking things? I think the DORA metrics are really good for that. Right there you have the deployment frequency. There’s a lot of practices that have to go into, come into place and really be in there for you to deploy very frequently and do that without breaking things where that’s the guardrail of your change failure rate. So I’m deploying frequently, but I’m not breaking things. Great. That’s awesome. It means I’ve built the engine to pivot very fast to deliver on value very fast, or if something comes in, I can react to it very quickly and ship it. Then there’s also the lead time for changes, right? How good am I from something new coming in to be able to get that out? So many practices that have to come into place to make that much more effective and efficient. And then the last one, obviously it’s the beyond the change failure rate, it’s the mean time to recover. Um, they are the mean time to recover. How good am I at fixing problems? If there is a problem, how good am I at fixing them? So all these things really tell me that the engineering team is humming, it’s buzzing, and it’s getting really good at shipping things. But here’s the problem with that alone. You have no guarantee that you’re shipping the right things, right?

Kovid Batra: Yeah.

Ariel Pérez: That’s only telling you that you’re shipping things, right? But it’s not telling you’re shipping the right thing. So then what do I do then beyond that? Well, then I start thinking about a measure of how many experiments are we running and why do we care about experiments. And ‘experiment’ not to use that word broadly, but how many things are we shipping for the purposes of validating that we understand what the customer wants? How good are we getting at putting things out there and collecting feedback and gathering feedback from customers? How good are we at learning from that feedback? And how do I know we’re learning potentially? One way is saying, “Well, over time, are we getting better at delivering solutions that the customer loves, that the customer finds value in? Are we getting better at shipping solutions that don’t degrade value, that don’t reintroduce friction, that don’t cause challenges for our customers?” So there’s a question there of over time, are we getting better at increasing value and reducing the destruction of value? That’s what I care about the most when we talk about “Are we building the right things?” And that aspect is often missed out on many teams. That’s where you get to effectiveness because if you can ship the right things, then you can continue focusing on shipping the right things as opposed to fixing the wrong things.

Kovid Batra: Absolutely. One thing that I feel that when you set these metrics for engineering teams, everyone is looking at those metrics as performance indicators, right? They look at that whether they’re doing the work, quantity of work, they’re producing it right or not. But as you said, like you want your teams to have the right context every time from the business side. So if engineers on one side would be aligned towards improving those KPIs, how would you bring that focus or how would you bring that intent into the engineers to focus on delivering the right value also? Like for efficiency, you have metrics in place they can see, but then how are these engineering teams relating to the business context by saying that, okay, we are delivering in the right direction, we are delivering the right value or not?

Ariel Pérez: Yup. Awesome. So, I think the first part of that is ensuring that it is a cross-functional team and product and design are embedded and working very closely hand-in-hand as an actual part of the team. It is not product and engineering, it is a cross-functional team. So that part is absolutely critical and essential. The second part is this is through these conversations with coaching and asking questions and working, you know, up and down and down and up the stack, some of the questions, you know, to work on with the teams is the following. Ensuring that every engineer on the team, when there’s something to work on something next, one of their first questions is, why are we doing this? What problem is this solving? Do we know that this is solving that problem? And do we know that that’s the right problem to solve right now? If you can actually help engineers, not only ask that question regularly as a way to learn, but also be as a way to really challenge assumptions that are often, not always, but often coming from product and design, It really helps the engineers have a very strong ownership over what they’re working on. And it also helps them in some ways protect their own time, not because engineering time has to be protected, but because you want to ensure that you’re always working on the most valuable thing. And if you don’t understand the value of the things, it’s really hard for you to ensure you’re working on the most valuable thing. It also ensures that our product and design partners are really working really hard to help figure out, “Is this the right thing?” “Is this the best thing?” And get really good at communicating that and very clearly laying out the value of what we’re doing. So, that’s the first part to start with. The engineers getting really good at asking those questions. That’s then bolstered and supported by continually and regularly communicating, not only from product and design, but also from engineering leadership, what is the vision? What is the strategy? How do we get there to that vision through that strategy? And what are the most important customer problems to solve? That needs to be communicated regularly to the point that every person on the team understands the vision, understands how we get there. That’s a big part of context building.

So I think it’s two directions. Continually communicating that to make sure it’s there. But the second part is really enabling and empowering your people and expecting them to always ask, “Why this? Why now?”

Kovid Batra: Totally. I think, I would love to talk more, but in the interest of time, I think we’ll have to take a pause here. The discussion won’t end because this is one of those podcasts where I didn’t realize that 35 minutes have passed and I’m just talking to you. It was really interesting. Appreciate you for executing the way you are doing. I’m really amazed and would definitely love to have another show with you. But for today..

Ariel Pérez: I’m looking forward to it.

Kovid Batra: But before we leave today, I won’t let you go without a parting advice for our audience, the engineering leaders, the upcoming engineering managers who are listening to this podcast. What would be your parting advice?

Ariel Pérez: My parting advice would be, especially as a leader, your biggest responsibility is to create the environment and the system that allows your teams to thrive. That is your biggest responsibility. It’s your teams that are the most important. And in order to help them get really good at that and at really good at thriving, how do you ensure that you’re constantly removing blockers? Rethinking the system in which they work in to remove dependencies. And then most importantly, how do you empower and enable every single member of your team to be able to make the best decision possible for the company and for the organization without you having to be there day in and day out. That’s the key piece. How do you enable and give them that ability to make decisions independently on their own and feel like they own that decision in the service of your customers and the strategy of your company. That’s the key piece. Think about that day in and day out. How do you create that environment?

Kovid Batra: Amazing advice. Thank you, Ariel. With that, we will say bye to you, but we’ll see you soon again.

Ariel Pérez: Thank you. Kovid. It’s been a pleasure, and I hope to talk to you again.

‘The Power of Insourcing and Self-Determination’ with Sebastian zu Erpen, VP of Technology at tonies

In the latest episode of ‘Beyond the Code: Originals’, host Kovid Batra engages in a thought-provoking discussion with Sebastian Heide-Meyer zu Erpen, VP of Technology at tonies and a professional mentor at the Mentoring Club. The heart of their conversation revolves around ‘The power of insourcing and self-determination’.

The podcast begins with a fun fireside chat with Sebastian, allowing the audience to see his candid side. Later in the main section, He delves into the transition from an IC to a managerial role, sharing insights into his daily tasks and the hurdles he faces. Sebastian provides insights into the criteria to build a strong team and the strategic shift towards insourcing over vendor diversification. He also sheds light on four crucial dimensions for defining and measuring engineering success: outcome, output, tech health and team health.

Lastly, Sebastian underscores the significance of self-determination theory, advocating for an outcome-oriented approach and value-driven delivery model within tonies.

Time stamps

  • (0:07): Sebastian’s background
  • (0:39): Fireside chat
  • (8:42): Sebastian’s core tasks & challenges at tonies
  • (14:05): Hiring strategies for building strong teams while scaling up
  • (17:22): Why build in-house over diversifying vendors?
  • (22:02): Maintaining accountability & handling failures
  • (25:34): How to define success for engineering teams?
  • (28:19): How to ensure an outcome-oriented mindset for developers?

Links and mentions

Episode transcript

Kovid Batra: Hi everyone, this is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing guest. He’s a believer of self-determination theory. He has 18+ years of engineering and leadership experience. He’s one of the renowned mentors on mentoring club. Currently, he’s serving as a VP of Engineering at tonies. Welcome to the show, Sebastian. Great to have you here.

Sebastian Heide-Meyer zu Erpen: Thanks for having me. Glad to be here.

Kovid Batra: Thank you so much for taking out this time. And today, we’re looking forward to learning a lot of things from you, whatever you have done in your career, in your personal life. And to start off, I just wanted to touch base first on the personal life so that our audience knows you more. So, there’s a quick fireside chat we have for you. I’ll be asking a few questions there. Should we go ahead?

Sebastian Heide-Meyer zu Erpen: Sure.

Kovid Batra: All right. Thanks a lot. So, first question. Apart from technology, I’m sure you have been a techie for so long. I am sure that’s a passion for you, but apart from that, there must be something that really excites you. Can you tell us about your hobbies, things that excite you outside of tech?

Sebastian Heide-Meyer zu Erpen: Yes, of course. And for sure tech is one thing that, that excites me still. But it is still, I’m still into music a lot. So when I was younger, I was actually, like DJing and was also a music producer and, yeah, there was a time when I had ample spare time. Since I have kids, I have much less, so hence less DJing and music production, but I still enjoy music very much.

Kovid Batra: Cool. So what kind of music you’re into?

Sebastian Heide-Meyer zu Erpen: Yeah. So I was, like into Caribbean music. So, there was dance also reggae, and also mixed with more American style hip hop and other more modern musical genres later on. Yeah, so that was the basic picture that I was into.

Kovid Batra: Oh, that’s so nice. Cool, man. That’s an interesting hobby.

All right. Moving on to the next one. Now, as you said, like, tech is one of the passions. I wouldn’t skip that thing for you. Tell us about your first experience, your first coding experience. How was it and what did you write?

Sebastian Heide-Meyer zu Erpen: Yeah. So, and the thing is, I don’t actually remember the first thing that I wrote. But the first coding experience was a basic summer course that I did. And, I was so fascinated that later on the first thing that I can actually remember that I built was a context manager where you could enter basically a first name, last name, address and phone number and such things. And then store it on your hard disk was, all, I think it was still MS-DOS based and was only text interface based, but I liked it so much that I even started to pitch it to my family. So if they wanted to use my context manager, that actually never took off, but, I was really into that. And then what I liked about it was that I could build something, very, like, exciting and professional-looking out of nothing basically. So, that I really enjoyed it.

Kovid Batra: Hey, I totally feel you there. How old were you by the way at that time?

Sebastian Heide-Meyer zu Erpen: That’s hard to, to say probably around 11, 12-ish something.

Kovid Batra: Oh, that’s, that’s pretty early actually. My first line of code was probably at around 17-18. But yeah, that’s nice. Nice to know that.

All right. Apart from your experiences, right now today you are at such a position in a company where you have to take a lot of decisions and anyone who is taking so many decisions, I’m sure has to have a source of learning so that your decisions are good. You have the right mental model in place. So, I would love to know what are you learning these days. What are your learning sources? Any specific books that you are reading?

Sebastian Heide-Meyer zu Erpen: Yeah. So I’m actually reading less today than I’m listening. So I’m listening to audiobooks, actually a lot also for, for learning purposes. And the last audiobook that I listened for learning purposes was on systems, I forgot exactly the name, but it’s one of the standard books on systems in general, how do systems behave and scale, and such. But, I also actually occasionally listen and re-listen to learning fast and slow. Sorry, is it, how was it?

Kovid Batra: Thinking fast and slow.

Sebastian Heide-Meyer zu Erpen: Thinking fast and slow. Yeah.

Kovid Batra: Yeah.

Sebastian Heide-Meyer zu Erpen: This is one that I occasionally re-listen to because there’s always elements that I take from that I like. But I have to admit that my general learning is more now focused on other channels or ways, or I think I learn different, um, topics in different ways. Actually,  when my kids were younger, I rarely had like 30 minutes of uninterrupted time. And that was a time when YouTube, actually started to become a part of my life because YouTube videos are very short, right? And I can take in information in a very short amount of time. And, even YouTube shorts nowadays can be quite good. Yeah. So, I still do enjoy these tutorial videos. Fireship is a good channel. Primogen. So, these standard coding channels I like. I do read Gergely’s newsletter, ‘Pragmatic Engineer’.

Kovid Batra: Yeah, I know.

Sebastian Heide-Meyer zu Erpen: Yeah. This is a really good one. So, I really enjoy it every time. ByteByteGo is a good source to basically refresh on some concepts and strategies, right? But then I still read a lot on LinkedIn and get a lot of new content. But also my teams, quite frankly, they catch new technologies and I learn from them. And, podcasts. So these are the main learning sources for me.

Kovid Batra: Cool. Thanks. Thanks for sharing all your learning sources secrets with us. All right. With this, we move on to our main section where we will be talking about how and what did your journey look like from starting from your developing days to a leadership position.

So, before we jump into that, I just wanted to know one more thing from you. This is of course related to your career. This decision of moving into leadership and management as compared to somebody who is at the core, a very techie guy, not moving to a Principal Engineer kind of a role; was that a conscious decision or it just happened to you?

Sebastian Heide-Meyer zu Erpen: Yeah. It’s part this and part the other. So, let me explain. So, when I joined my first company, actually, it was in the middle of an Agile transition. So it was just starting, or had just started with Scrum and had reset basically and restarted Scrum. And, in that period, they, for the first time, really placed a role called Scrum Master. So they didn’t have that before. And at the time they introduced it. And because I didn’t like my first boss, I had the urge to do something else and I saw a chance at being Scrum Master. Right. And then, yeah, I was chosen as one of the two Scrum Masters of the company. So, became that. And, was Scrum Master for a couple of teams and still a Software Engineer in one team. And at some point, they asked me, “Okay, decide for one. So, you can only be good in one. So, decide for one.” And with a tear in my eye, I made the decision to focus fully on Scrum Master because I felt I worked with three different teams. I helped solving them more of these like organizational problems, but then also like helping improve the relationships with the Product Manager. Still was, supporting on the tech side occasionally. So it felt like my scope and my impact was way bigger than pure coding. And that was basically when I made the decision and later on, then turned to Team Lead and whatnot. Yeah.

Kovid Batra: That’s cool. I think for a lot of folks, to whom I’ve talked, who have moved into management or leadership, this is one of the most important reasons for them to switch to that. They see that impact. They see that adrenaline in them when they are managing teams and getting more people empowered to do more. So yeah, I think that’s so cool.

All right, Seb. Tell us more about your experience at tonies, your routine. What are those important responsibilities that you hold as a VP of Engineering at the company? And what are the challenges that come along with that? So it’s a big question, actually. You can take your time to explain it. Yeah.

Sebastian Heide-Meyer zu Erpen: All right. So I, I’ll try to make it short. So first of all, I think I need to explain what the tonies are. So tonies are the producers of a small audio player for kids. Unfortunately, I don’t have one right now with me, otherwise I would show it to you. It’s a cube basically that looks cute. And then on top there, go these little figurines that you can place on top and then it plays the audio that’s connected with this little figurine. So, we have lots of Disney characters and Paw Patrol. So, all the stuff that kids know, but you can basically use this as a creative one is what we call it. You can put your own stuff on it and it plays, what’s on the Tony. And kids can use it from the age basically of one and a half to, because it’s so easy to use and it’s more natural to them than, I don’t know, using a CD player or whatever if, if it’s existing in households anymore, right? So yeah, and that’s what we’re building. So, basically we have this tech device, right? We have the back end. We have obviously an app with which you can control it and buy additional content. We have a shop. We have other outlets, basically. And that’s within the scope of responsibilities for me.

And quite frankly, what my job has been at tonies, but also at other companies is always like looking that everything is moving in the right direction, right? So nothing is crashing and we are really making progress on the things that we need to. And then, I’m going deep on one or two topics that are really important or really complex where I support with my expertise and my also connections, quite frankly, in my understanding, to move these topics forward, right? And I always constantly, and this is a big part of my job, try to combine the.. I have a very broad overview of what’s happening in the company. I talk to many stakeholders, but I then try to deliver this broad perspective to my teams and then get the deep perspective that they have on the specific technical topics that they own,  in order to formulate the best decisions as a connection between the broadness and the very deep expertise. So that I would say is pretty much describing my job and my day-to-day routine.

Kovid Batra: Cool. Cool. I think what I’m interested in knowing is the challenges that you see. Of course, these are your responsibilities. And I totally understand, as a decision maker for the whole team, you have to get down to that each and every integrity. I have a lot of questions on how does this device also works. But, let me just start off with the challenges that you see in the responsibilities that you have taken up. What is the most difficult thing for you in day-to-day?

Sebastian Heide-Meyer zu Erpen: Yeah. So, this has shifted massively over time. So when I started, the team actually was probably 60 percent external. So, because the product itself was invented by folks that have been working in agencies, and they have been used to working with agencies, so, all of the IP, all of the knowledge and quite frankly, the effort was outsourced. So external partners were doing the work, right? This is a good idea short term, but long term it’s quite expensive and also risky because, if you are, and we had situations with one of the suppliers who were suddenly saying, “Hey, we want more money. Otherwise, it’s not working out.” And then, we had very tough negotiations. So, uh, what we did is we started to insource, basically, the development massively and have flipped the script or basically actually most of the development now is done by FTEs within the company and the, the know-how and the IP is generated in turn.

Then the next thing was, um, During COVID, we had to navigate also supply chain issues. Quite frankly, there was a chip provider that told us, “Look, we can deliver, like the next nine months of the quantities that you need, but then we will not deliver meaningful quantities.” So, we had nine months to rebuild the whole hardware around a new chip, which means basically you have to rebuild the whole thing. And that was very short notice. I turned grey during that time. I learned a ton about hardware development and firmware development. And then, also tried obviously, my, like very Agile-driven, software engineering background to bring this in. So how do we do shift left quality assurance? How can we test, as small of a unit as possible to keep feedback loopers, loops as short as possible, right? And then, like have different layers of tests. And I think we learned a lot and we built a team along the project. So we started with external providers, but built an in-house team, and created the knowledge in-house. And now we have a really good, like foundation to, yeah, build basically future devices that we’re working on in the future.

Kovid Batra: Cool. So I think this is very interesting, Seb. When you scale a small team from a few single-digit folks, the number to 60, 70, as you said, in this time, of course, that knowledge creation, that culture creation, everything becomes important. I think very important is the first step, which is hiring the right folks. So, tell me about how did you start hiring. What were your criteria there? And how did you build this strong team of developers that are working on hardware as well as software, as I see? So please go ahead.

Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. So, the number one thing for me is obviously I scale or through my expertise only with people, right? So if I have people that are very aligned with me and I am aligned with them, then we can scale better. So what I did was at first I made with the existing, we had existing leads, I made my expectations towards them and their expectations towards me very explicit. So, had a role description, that I agreed with them and then I held them accountable and they really liked it. So then, because we were growing in size, right, I hired a bunch of new Engineering Managers. Some of them I actually knew from, from past companies. So, I had already a great trust relationship, knew how capable they were, right? Some of them were new and some really surprised me at what they basically were able to deliver and how also some of the internal folks that have been there have been growing time was really, uh, amazing. So with that in place, a great team, I could then use them to scale. And we hired a bunch of folks into the teams and invested heavily in select areas. So, as I said, right, due to the supply chain issues, we had to invest heavily in the hardware and embedded space in order to insource the IP production and also be capable of building new products ourselves.

And then, also we did a similar thing in the app. We had a, like reasonably, no, actually a mediocre app before, wanted to build a top-notch app and had to build a team from scratch, basically. Had no single mobile developer or only one, when I joined. So did that there, hired a great leader for this team, scale the team. And now, like there’s this flywheel that’s always starting to flow, right? Because the leader is like working with the team, I’m working with the leader and then they’re bringing in new expertise and new practices. And this then sets something in motion that the team understands, “Okay. If we do that, then we get faster or quality gets improved. And we get more freedom, get more time and can do more.” And that’s what’s happening, and that’s what we’re seeing, all along the teams basically.

Kovid Batra: Cool. Perfect. Yeah. I think holding people accountable, giving them autonomy, and yes, of course, hiring from some known folks and references always works better, probably. And that really helps it because at the end of the day, it boils down to trust. And people whom you know, their working style. And once you are comfortable, it really becomes a motion where all of them are pushing towards one thing. So that’s really cool. That’s a great piece of advice.

Seb, one thing that you just mentioned, like during COVID times, there was a supply chain issue and we know that this chip industry was really taken back at that point of time. And it’s not just tonies, probably a lot of such companies who were dependent on hardware were struggling to source chips, right? At that moment, you decided to build things in-house, right? Usually, this is a question that I ask that ‘buy versus build’, right? At that time, why didn’t you think of probably going down to a few other vendors if one vendor was moving away from commitments? Then you could have two or three in the pipeline supplying you the same thing so that if one fails, you can rely on the other, because I mean, I have had that personal experience of dealing with such hardware vendors. And this is what we did. We didn’t start building things in-house. But your story is different. Can you tell me some rationale behind taking that decision?

Sebastian Heide-Meyer zu Erpen: Yes, of course. And also, to be fair, we did not build the hardware in-house, entirely. So it was rather done by a supplier as well, a different one with support from our in-house team. And we anyway had the plan to build a second source. So we knew we were dependent on one chip supplier, on one like development partner, right? And we wanted to have another chip supplier build a second, also, development partner in order to do this or be prepared. Unfortunately, it hit us and we weren’t prepared. So, we had to do this on the fly.

However, what I insisted on at that time is that we build the firmware in-house because what I wanted to do is to iterate as quickly as possible, as much of the feature set as possible. And, what we were doing is we made the explicit decision. The app should be the new basically digital centerpiece for, for the interaction with the product, which is natural. If you have an IoT device, then you usually control it with the app. And this is the panel for the parents. And we also wanted to get In touch with the parents more often via the app so that we have a touch point with the parents via the app and with the kids via the device, right? So, we invested heavily in making the app better and more appealing to parents and also more useful. Quite frankly, we focus on the jobs to be done by the parents and make better offerings in order to help them overcome these kind of get these jobs done basically. And by doing that, we also want it to be able to enable parents of doing certain things in the box that they couldn’t do before. And in order to have this cycle as short as possible, we wanted to have all the capabilities that we need, including the firmware capabilities in-house to really basically make all of this one month at best from idea to production. And what better way than having everything ideally in within the company, very closely connected, right? And that’s how we ultimately, came up with this setup.

Kovid Batra: Yeah, I think I get your point here. It’s more around the concept where you want to deliver value, you know that part of your value chain, your supply chain, how much is it going to impact the overall delivery of that value to the customer. And, that’s when you decide how much control you want to have on it. And probably from there, you decide whether we should have it in-house or probably get it outsourced. That’s cool. That makes sense. Perfect.

Sebastian Heide-Meyer zu Erpen: Quickly, if I, if I may add, like, worldly maps are a great tool to basically do exactly this analysis that you just did, right? So the more, the closer something is to the customer, the higher, the, the basically impact, that you can have on like developing pieces, closer to the customer in-house. And also the, the closer something is to your IP, meaning to an innovation. So, the more commoditized it is, the, the less like differentiation you can have as a company, but the closer it is to an innovation, the more differentiation potential there is, right? And that’s how we approach the, the whole thing as well.

Kovid Batra: Totally, totally makes sense. I think that’s a very good way of looking at and making a decision about whether to buy versus build. Of course, it comes down to the capabilities also, how much capital you have, how much it would take in terms of resources. Of course, that also matters, but ultimately the decision-making should start from this point of how much control you want to have on value delivery there, and then probably, think backwards. Makes sense, Seb. Great piece of talk.

Another question that I have here is that when you are owning so many things, uh, you have such a big team, everyone is autonomous, you have given them that accountability. There is a possibility that some small fuck ups happen, right? Sorry to use that word, but yeah, that happens, right? At such a scale, the impact of such failures is very big, right? And you need to have an eye on that. How do you deal with such situations? How do you make sure that you proactively control these situations? How do you do it in your company right now?

Sebastian Heide-Meyer zu Erpen: Yeah. Yeah. The good thing actually is that with our, like product, we have resilience built-in because we always have this, this audio player that works on its own. So, if you put a figurine on top that already has been played on the player, it is stored on the player and it will just, just play it from, from the disc. So there’s not even a connection to our system. So if the box itself is functioning, no battery problem or whatever, right, then it will generally work. This already, like makes our overall offering quite resilient. However, there’s obviously still like a lot of systems that can break. We have lots of microservices that fortunately have a limited blast radius, but that can break. And this occasionally happens. So, what we do there, so we have an extensive set of metrics that we’re monitoring. And so we focus, a lot on observability in general. And we also like, use more and more business metrics so that we basically, whenever something breaks, we, we catch it, even though we might not measure the specific or see the specific technical metric go out of bounds in a range, right? But we, we see the, the business impacts, quite frankly, we also have customers that are very quick in letting us know when something is not working, so we detect it very fast usually. Yeah. And then basically the incident management process run. So, we have an incident manager that is defined. It’s usually the Engineering Manager from the area of  incident that, that sort of responsibility where the incident happens. Then we have kind of a war room chat where folks get together. Everyone who thinks who can contribute is welcome to contribute there. And it’s actually an all-hands-on-deck situation. So whoever can support should be also there. Then we do root cause analysis the normal stuff, right? So we try to find out okay, what, what is actually the root cause of what, what’s happening there. We focus on mitigation, try to basically build hypotheses, follow these hypotheses, validate them, invalidate them, come back together. And then, once the root cause hypothesis is validated, we will think about how can we mitigate it. And once it’s mitigated, then we have a post-mortem where we discuss how can we A detect this sooner and even more important, how can we prevent this from happening in the future, right? So pretty much standard, but it’s working pretty nicely. And usually, our incidents are quite short, luckily.

Kovid Batra: No, definitely. These processes, these tools definitely help, and you just have to have that discipline in yourself. And I’m sure teams who are using these things and following these things are at a much better position as compared to those who are always firefighting. So, cool. I think that answers my questions really well.

Apart from this, what I think is that when you’re leading a team, there is a sense of accomplishment that you feel when your teams succeed, right? It’s not just limited to yourself, it’s for the team. So, how do you define that success for your team when you feel that, yes, they are succeeding? What are those ways you measure it? How you define it, first of all. Measuring is probably second. First, how you define it for them in your company.

Sebastian Heide-Meyer zu Erpen: Yeah, yeah. So ultimately, when defining success, I’m looking at four different dimensions of basically, yeah, measurements if you wish. So I’m looking at the outcome, which is ultimately what we’re striving for, right? So, we want to have an outcome that’s good for the customers of the company. Hence, it’s good for the company, right? And hence, it’s also good for the employees and blah, blah, blah.

So, the next thing I’m looking at is output actually. So, this is purely the amount of work that flows through a system. Because like over the years, right, you can measure, the size in T-shirt sizes. You can do story points. You can, whatever, right? I tend to follow the idea of trying to make stuff small. And if you try to make stuff as small, so units of work as small as possible, then you can simply just measure the amount of units of work that are flowing through a system. Law of big numbers. If you have enough units of work that are flowing through, then If the amount is not going down, then it’s a good thing. So it doesn’t always have to go up, right? And you don’t need to measure 10-minute units of work, right? But as long as it’s not going down, then it’s a rather, rather a good thing.

Then there’s obviously tech health because we like producing output in order to generate outcome. We also want to do this sustainably and therefore tech health is important. So we’re looking at the amount of incidents, mean time to recovery, but that general DORA metrics would be helpful there. Tech debt should be also assessed, analyzed, ideally measured in some form, right? And then, not to forget, team health is super important so that the people, the folks in your organization are actually engaged. They feel committed to what they’re working on, uh, aligned, right? And they’re, I’m a huge fan of the self-determination theory, which pretty much says, okay, you have this relatedness, you have, the mastery. And you have the, the autonomy, which are the three main like, big dimensions, when it comes to motivation and, and this motivation that leads to, to happiness and ultimately, engagement. Yeah.

Kovid Batra: Perfect. I think that sums up a really good vision for us to drive or tell the audience how to drive tech teams, actually. On the very first point when you talk about, like talking about the autonomy, looking at the outcome, right? You talked about outcome. In that moment, leaders, managers still align with that. But I have felt, of course, it could be a different scenario at tonies, for sure. But with developers, this comes with a difficulty, right? They just write code and they really don’t, like most of the time they don’t tend to see the value they are delivering through that code because it is, I understand it is indirectly related. You first write code, then the product works and then the product is adopted and then the features are adopted, people use it. But we definitely know that if the developers, the teams themselves are so aligned with the outcome-oriented approach while writing the code, that makes the best mix for a team, right? Do you practice that or are your developers already trained in that mindset? How it looks at tonies? And if it is not like that, how are you working towards making it work?

Sebastian Heide-Meyer zu Erpen: Yeah. So, it’s not equally distributed within the org. So for example, we have one team that is focusing on the so-called IoT platform, which is the backend that the Tony boxes, our audio players are sending their requests to, like if they request new audio or whatever, right? And those engineers are a little bit further away from the product than let’s say, those who are producing the actual box, right? Or those who are working on the app, they are consuming their product themselves, right? They’re interacting or are much closer to the customers when developing their product, right? However, that being said, I mean, we have one big advantage in that we have lots of young parents who have children who have the Tony box at home, which makes it very easy to connect to the product, right? But even if this weren’t the case and for many folks, this is also not the case, they don’t have kids and they are not so well connected, right, but we’re always trying to focus on the ultimate outcome for the customer. So, that’s when we talk about a new feature or a new, like let’s say epic, that, that we’re kicking off, right? And we are always talking in like starting from what’s the value for the customer that we are planning to generate. And we’re actually trying to do the discovery already with engineers so that they ultimately are part of selecting the solution. Exactly. Because it’s ultimately always like starting from the jobs to be done, right? You have an idea of a job to be done that’s unmet not, or undermet, in terms of offerings, right? Then you’re trying to validate this idea first. So, is the problem that you’re trying to solve actually the right problem, right? And then, you’re trying to come up with what’s the quickest solution for this job to be done. So, what’s the fastest way to build it in order to then validate it, right? And now, we’re trying to include the engineers already in this discovery phase so that then by the time we’re actually building it and rolling it out, we have the minds of engineers already on the consumer problem. So they are like, strongly connected.

Kovid Batra: Perfect. I think this is a very good idea, actually. Involving people from the design process itself would really help them connect, looking at what those jobs are to be done by the user and then probably have that relatedness while writing the code. So, that makes sense. And of course, as you said, for tonies, it works even better because they can use their own product and see what needs to be done. So, cool.

Great, Seb. I think it was a very good talk and thank you for sharing such in-depth things that you’re doing at tonies and giving us that insight. So, I would love to have another chat with you sometime again on another episode, maybe because I see that these 30 minutes are very less for me to know what you have in your work and in your mind. So, cool. We’ll look forward to connecting again and thanks for today. Thanks for taking out the time and sharing your thoughts with us.

Sebastian Heide-Meyer zu Erpen: Thanks for having me. It was great. Great fun. Thank you.

Kovid Batra: Thank you, Seb. Have a great day. See you.

Sebastian Heide-Meyer zu Erpen: You too.

‘Pair Programming, Remote Work & Developer Well-being’ with Eric Heikkila, Technical leader at Ford

In the latest episode of ‘Beyond the Code: Originals’, host Kovid Batra welcomes Eric Heikkila, Technical Lead at Ford with a rich background in organizations such as Arbor Insight, Gene Codes Corporation, and more. Their conversation revolves around ‘Pair programming, remote work & developer well-being’.

The podcast starts with a fireside chat with Eric, giving us a glimpse into his journey. As the conversation progresses, he delves into the transition from working at a startup to his current leadership-cum-IC role at Ford. Further, he shares effective strategies for remote team management and the pivotal role of pair programming and DORA metrics in ensuring team success and developer well-being.

Eric concludes by offering parting advice to the audience, emphasizing honesty, embracing failure, and learning from mistakes.


  • (0:05): Eric’s background
  • (0:35): Fireside chat
  • (3:38): Challenges faced in transitioning to a leadership-cum-IC role
  • (6:03): Daily tasks and challenges as the Head of Software Engineering
  • (8:25): Managing remote teams as both a leader and an IC
  • (10:40): Remote pair programming vs. working individually
  • (13:04): Defining the success of an engineering team
  • (14:47): Motivating the team by leveraging metrics for leaders and ICs
  • (18:58): How to ensure team well-being and developer motivation?
  • (21:18): Parting advice for the audience

Links and mentions

Episode transcript

Kovid Batra: Hi, everyone. This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest. He has 30 years of engineering and leadership experience. He has been the founder and ex-CTO of Arbor Insight. Currently, he’s working as a Technical Leader at Ford. He’s also an active Modern Agile community member. Welcome to the show, Eric. Great to have you here.

Eric Heikkila: Thanks. Great to be here.

Kovid Batra: So Eric, thanks a lot for taking out time and coming to the podcast, sharing your thoughts with the community. They’re really looking forward to it. But before we jump into that, we want to have a quick fireside chat with you to know you a little more. Are you comfortable with that?

Eric Heikkila: Absolutely. Yep.

Kovid Batra: All right. All right. So let’s just start with your hobbies maybe, outside of work. What do you love?

Eric Heikkila: Sure. I love building things. We do, you know, all day is mental work. So, doing things like, you know, woodworking or putting up drywall, even painting, love doing all that. Just something tangible that, you know, after all day working on stuff that doesn’t exist.

Kovid Batra: What was the last thing you built?

Eric Heikkila: Recently I took up leatherworking. So I built a prototype really for a dice pouch. My son is an avid Dungeons and Dragons player. He’s at college right now. So building him something to take with him to his gaming sessions.

Kovid Batra: Oh, that’s so cool. Perfect. All right. Tell us more about, something about your life, some life-defining moments.

Eric Heikkila: Yeah. I guess for me it was right after 9/11, I really wanted to just, you know, drop what I was doing and go to New York and help out. But I couldn’t do that. I have a small family, I had a job at a startup as it, as it were. I found out a company in Ann Arbor was working on DNA matching software. So a fellow I used to know, got me an interview there, started working there, and then spent nine years working on software to not just do identification of 9/11 victims, but also to help fight child trafficking using forensic work, used to help, like in the Thailand tsunami. And that’s when I discovered I could use my skills for, you know, it may sound corny, ‘for the greater good’ as it were. And so since then, I’ve always kept an eye out for any of the opportunities that come along to make sure that I was still fulfilling that, that need to, uh, you know, help not just, you know, someone with a counting software, but, you know, somehow contribute to bettering everyone.

Kovid Batra: Oh, that’s so nice. Great. We’ll definitely talk about this more.

Apart from that, like it’s been almost 30 years into engineering. I just want to know, like, how was your first experience with coding or maybe your first experience with your computer? Tell us something about that.

Eric Heikkila: Yup. So my dad was an elementary school teacher and when I was seven, he brought home an Apple II, uh, to do grading. They gave him to do grading. And I was just fascinated. And so I bought a book on quick basic and taught myself how to write code. It was really terrible, but, you know, I was able to do, make a character generator for Dungeons and Dragons. Cause you know, that’s where my son gets it from, I’m a big gaming geek. And so, that was, that was my first foray into that, getting the computer to do all the dice rolling and then eventually print out all the character sheets. I wouldn’t have to write them out by hand.

Kovid Batra: Oh, that’s so nice. Perfect. Thanks a lot for sharing all this with us. Now I would like to move to the main section, where I would want to know your journey from a tech founder at Arbor Insight and then moving into a leadership-cum-IC role at Ford. So tell us about this transition, like what you used to do at the startup when you were working there. And then now you have transitioned to this leadership-cum-IC role. How is it different? How is it better? How is it bad? Just tell us about that.

Eric Heikkila: Sure. Yeah, it was definitely a transition. So at the startup, which was a lot of nights and weekends and all the time I wasn’t at my day job and we had a fairly small team, so I wasn’t just setting, like building roadmaps and, and setting technical direction, it was also, I had my hands in the code as well for a lot of it. But then moving from, from that to not just another programmer, but certainly not a, you know, not high up in the executive food chain, say at a large company like Ford. Definitely took a bit of time to get that mindset of, yeah, I’m not setting the direction technically. But their team is really good. Our leadership is very supportive. So I’m still able to bring in ideas and techniques and tools and say, “Hey, we should try this. We should try that.” I’ve got the leeway to experiment with on my team and then bring that to the broader technical leaders. You know, once I’ve kind of vetted it with, you know, on a team, a project and go from there.

So that transition was, you know, interesting in a number of different ways, but while I’m, you know, not at the top of the food chain now, it’s also a lot less stress because I’m not at the top of the food chain. So it was a nice kind of, you know, mental break to get back into more just, you know, more day-to-day coding and still making technical decisions, but, at a smaller scale than at the, uh, like the CTO-level.

Kovid Batra: Makes sense. So basically, all these years where you have worked, you wanted some break from the stressful situation or stressful work that as a CTO you would be doing at a startup. Now you wanted to move to something which was less responsible, right?

Eric Heikkila: Right. Yeah. Yeah. And the, and our, our startup had gotten acquired. So it wasn’t good to stay with that company in particular, but, yeah, I definitely needed something a little more stable for a while anyway.

Kovid Batra: Totally makes sense. Perfect. So tell me more about your role at Gene Codes Corporation, right? You were Head of Software Engineering there. What exactly were your responsibilities in day-to-day and how did you used to execute your routine, the challenges that you faced at that time? Can you tell us more about that?

Eric Heikkila: Sure, sure. And that was the company where I was doing the DNA matching software previously. I had left explored some other, other jobs and then ended up going back to that company after the President reached out to me and said he needed some help. One of the really interesting challenges was only two of us were in the same time zone and the rest of the dev team was 8 time zones away. So there’s a lot of, you know, get up at six in the morning, get into work, have a couple hours of overlap time to go over what the team had done, you know, the previous day. And then I’d spend the rest of my day working on technical feasibility of what they were doing and like how they could move forward to the next step and what the, you know, direction to give them on the stories that they were going to pick up when they came back online. And then at the end of my day, I was offloading that to them and then going home and, you know, coming in the next day and finding out how it went. So that, that lag was definitely interesting to deal with. That was pre-COVID too, so we weren’t used to working remote, but, that certainly helped me anyway, when we transitioned to more of a remote work environment, having that experience with a team, you know, many timezones away.

Kovid Batra: I think still, I mean, a lot of companies were already before COVID were working remotely, and post-COVID it has become even more normal to have a remote team. But I’m sure you have been doing that, now at least at Ford it’s not a remote role, right? Before this, you have been in a remote role, right?

Eric Heikkila: Currently Fort is, is remote.

Kovid Batra: Oh, that’s also a remote role?

Eric Heikkila: Yeah, yeah, it’s all remote. We do go into the office on occasion, if we want to do like some whiteboarding in person or get a couple of teams together and, and brainstorm some things. But day-to-day, on the team I’m anchoring, we’ve got people in California and Colorado, New York, you know, kind of spread all over the place.

Kovid Batra: My question was actually that if you are working as a remote leader of a team and you’re working as a remote IC, like these two roles working remotely, there is a whole lot of a difference. As an IC, like you, you just have to do your own work most of the time, right? So it’s okay for you to, like be remote and do it. You are motivated enough and you are so senior that you know what to deliver, when to deliver. You remain committed to that most of the time. But, if you look at it from the leadership perspective, that the role that you are into and handling teams remotely, I’m sure it would have been a little difficult compared to having people in-person, like keeping them motivated, checking on what exactly their enthusiasm is when they’re at work because it changes when it is remote. So, at that time were you using any specific tactics or I should say, strategies to handle your remote teams better and take care of their well-being as well as their overall output of the work?

Eric Heikkila: Yeah, we didn’t get into too much of that with the Software Director position at Gene Codes. Currently at Ford though, in my position, the team around, we set up, our core hours to make sure we had at least six hours of overlap regardless of where we’re located. And then we’re always pairing our ensemble programming.

Kovid Batra: Oh, that’s nice!

Eric Heikkila: And then, so we’ve got, and then we moved stand up, so now we do that just before lunch so that we have some contiguous time in the morning with everybody. And then, just before we’re going to take a break anyway, do a quick stand up and then after lunch, continue bobbing, ensemble programming, pairing. And that seemed to work out pretty well. And then we’ll for like morale building, we’ll do like, you know, once a month or so just to have like a couple hours of, you know, playing some online game together or one time, we did a ‘ask me anything’, but it was around each of the individuals and you could put, like two or three questions that you want to ask the other person. And we did sort of like a lean coffee on that and, and got to know some interesting things about our team members.

Kovid Batra: Cool. So when you are doing it remotely, even right now at Ford, as you said that you have this setup where you try to overlap and do pair programming, this experience of pair programming, how do you find it? Like, is it beneficial in terms of getting more or better code done? I understand the point that if you have an overlap, at least you get to know each other, you stay connected. But if you look at the core work done through pair programming, what’s your thought on that? When you’re working individually, you are more focused and you deliver more quality, how does it work out? I’m interested to know that.

Eric Heikkila: Sure. Yeah, for me, when I’m, when I’m not pairing, I’m way more stressed at the end of the day. Whereas when I’m, if I’m pairing all day, I’ll be mentally tired, but not stressed, because, I’m not alone, right? I’m always working with somebody, you know, sometimes two or three somebodies, at a time. So it’s, we never get into a place where I’m stuck, I can’t move forward because we have, you know, multiple brains all working in the same context and the same goes for either motivation or energy level. If I may be, you know, starting to flag, my partner or the rest of the mob may be, you know, on the upswing. So it’ll balance a lot of that, a lot of that out as well. And then just the knowledge transfer, right? Just being able to, you know, it doesn’t matter if I’m pairing with somebody who’s senior, somebody who’s junior, someone who just came in from college who doesn’t know what they’re doing. I still can learn from them, depending on, you know, what we’re doing, maybe some shortcuts in the idea that I didn’t know about, or maybe some new TDD tool or a different way to look at an algorithm. And so there’s a lot of a lot of give and take, and I find a lot of value in pairing, and, or, ensemble programming, especially for onboarding. Like on any of my teams, day one, you are committing code, right? It’s not, “Oh, welcome to the team. Spend three months reading the manual over there in the corner. And then we’ll get back to you later.” It’s, you know, hands-on right away, get in there and get some work done, which, uh, I think is beneficial. And so far I’ve heard nothing but positive feedback on that from the people coming into that environment too.

Kovid Batra: Yeah, absolutely. I think that really works there also.

Cool. So now, coming to this point where we are looking at pair programming, helping teams become more productive, in general, in so many years, you would have worked with different teams, build different teams, right? But the most important question always comes, as a leader at least, how much effort the team is putting in? How much effort is aligned to the business goals? How would you define the success of your engineering team, right? And as a leader, you have to take accountability and responsibility for that, right? So, tell us about different experiences with different companies, of course, the way you have defined success for your engineering teams and how do you go about it?

Eric Heikkila: Right. So I guess it depends. Like at the startups, it was very much, “Are we getting the features out that our customers want?” Because they’re waiting for it, right? They said, “Here’s what we need.” We don’t have any time, get it out the door so we can get it in their hands. And a lot of that ties into the metrics that, you know, DORA, tracks and, you know, supervises. And then, for me, the time between when we, you know, put pen to paper and say, “Here’s an idea.” to when that gets, you know, not just deployed, but released out to the customer. That’s really, one of the main metrics I look at. And then also, you know, number of defects that get released and, and things of that nature. So I’m not, not so worried about lines of code, not so worried about, you know, effort or how long does the story take, but really, are we, are we generating value for our customers? And, that may not be writing code necessarily, depending on what the feature is.

Kovid Batra: Cool. So even now, when you are part of such a big organization, right, we see a lot of frameworks, a lot of engineering metrics coming into the picture. So for smaller teams, when you have almost complete visibility, like what people are doing, what is getting delivered. I personally feel that this approach of setting the fundamentals of delivering value as a success for the engineering team is perfect, right? But, when the size becomes bigger, like you have so many people working along with you, having clarity for yourself as a leader and for the person who is working as an IC, as a developer, on a day-to-day basis, it’s very difficult to keep them motivated just with this long term vision of delivering value, right? On a daily basis you’re writing code, you really need to have a push where you know, “Okay, I need to do this today” and you have to win every day, right? Not every day at least, but you have to put in that effort. So a lot of companies we see putting metrics in place, right? Putting certain KPIs in place. What’s your thought on that, or for that matter, how do you do it right now with Ford? Are you guys implementing something? If you’re comfortable sharing, please do.

Eric Heikkila: Sure, sure. Yeah, we’re, yeah, it’s, it’s interesting because we’re kind of going through that phase of, yeah, “What should we be measuring? And how do we communicate that to the teams? And how do we break it down at an executive level and at the next level and get on down to the developers?” So what we’ve been trying to do is create, you know, objectives at a, like a division level, you know? And then, and then at a more like a product line level. And then from there having each of the teams in that product line look at those, OKRs and then say, “Okay, is that something we impact?” You know, is it? Then, “How do we impact that?” And then, you know, generating their objectives and, and the metrics for success based on how they think they measure up to the, the overall objectives that the, you know, the company has set. So, doing a little bit of top-down and then a little bit of bottom-up. Hopefully, they’re kind of meeting in the middle and making sense.

Kovid Batra: Making sense. Yeah. Yeah, absolutely. Is it okay for you to share any of the examples that you have recently seen getting implemented at your organization or somewhere else where you can actually tell us with clarity which metrics would be suitable for what kind of measurement? Do you have an example in your mind?

Eric Heikkila: Oh, yeah, part of the problem, especially at Ford, it’s kind of a moving target because they’re, you know, changing technologies, you know, partnered with Google now and, you know, things are kind of moving at a, at a fast pace for the, the development teams. So we’ve been looking into automating more of the DORA metrics, but like actually tying that into, to get for, so we can track commits and tie that to stories and then track that, you know, through its life cycle, it’s a bit of a challenge due to the different technologies in play right now. So hopefully, they’ll settle down and then we can get some of that automated. Right now there are some dashboards in place, using a tool like Datadog to be able to generate metrics and then post them someplace that’s, that’s visible. So we can track, yeah, a lot of the not necessarily velocity, but you know…

Kovid Batra: Production failure, basically the observability there, right?

Eric Heikkila: Right. Right. Yeah.

Kovid Batra: Makes sense. Makes sense. So I think this is also a very important metric to, I think one of the most important metric to track because ultimately it links to customer satisfaction also, wherein if there are more bugs, more failures on the production, then the customers would be dissatisfied. So cool. I think, yeah, that’s a very relevant example.

Eric Heikkila: Yep. So we’re going and we’re taking not just that, but looking at, okay, how can we make that predictive? So, you know, starting with, you know, measuring uptime, downtime, but then, working on instrumenting it so that we can tell, okay, it’s about to fail.

Kovid Batra: Yeah.

Eric Heikkila: We need to intervene before it impacts our SLAs.

Kovid Batra: Perfect. Perfect. Absolutely. Apart from looking at the efficiency, I think one more important thing which has recently become very important is looking at the well-being of your team members, right, their experience. So how do you guys do it at Ford or how you have been doing it at other companies where you have worked? Can you just give us a few examples, like how you executed developer well-being, probably if there were some metrics you were looking at to ensure that people are feeling happy, motivated?

Eric Heikkila: Sure. I mean, one of the big things is, we do a retrospective. It’s about once a month now. We did it for every two weeks. That was a little much for the current team size. So we pushed it out a little bit longer. But on that, we have a, a wheel that has all kinds of emotions around those around the side. And we’ll, you know, put a dot vote those.

Kovid Batra: Okay.

Eric Heikkila: And then we’ll just go through it and say, “Okay, I’m feeling excited because we’re working on this project. I’m feeling worried because we said we’ll get this done by the end of the quarter. And, you know, maybe I’m tired because we’ve been, you know, working extra hard because of the worry around what we promised.

Kovid Batra: Makes sense.

Eric Heikkila: So a lot of that, and then spending more time on the retrospective on the, more like emotional or personal side, rather than the technical side. We’ll save, you know, the technical stuff for the day-to-day standups and interactions. But, really for the retrospect, we try to focus on, you know, like you’re saying, well-being, how are people feeling, you know, what should we try changing to, you know, maybe reduce some of the stress or, you know, at least spread it evenly across the team.

Kovid Batra: No, at least the important point is that the teams, the organizations should have a focus here. There could be multiple ways to do it, but at the end of the day, if you have an intent to actually take care of your teams, they would reciprocate back in terms of the output that they’re bringing in the value they’re creating. So it is cool. Like, everywhere I see these kinds of things happening where there could be pulse check-ins, there could be things like what you said, that there is this dart you put on, different emotions and try to understand. So that makes it more gamified and interesting for people to express themselves and come up with things that they are feeling. So, really cool for sharing that with us. I think we’ll try that in our company too.

Eric Heikkila: Cool.

Kovid Batra: Cool. Eric, I think, more or less, these are the questions that I had, but before we let you go, I would like you to share some advice from your 30 years of experience that you would like to give probably to your younger self or the audience who is coming into this role. Any parting advice from you would be welcome.

Eric Heikkila: Really the, some of the things that have, that helped me out, also got me in trouble is being honest, just be completely open and honest and, you know, and say, here’s, here’s exactly what’s going on, right? Good or bad. You know, I just need to have that honesty and the other, the big thing I’ve seen too, especially from people new to the industry, they’re so afraid to be wrong. It’s like, go ahead and be wrong. It’s okay to be wrong. We’re wrong all the time. We don’t know what we’re doing. Welcome to the club. Be wrong, fail fast, but be able to recover from that. So do, you know, make small mistakes. You know, go ahead and make mistakes. Just make them small and then learn from them.

Kovid Batra: No, that’s a very apt, perfect advice. I think someone who comes in to the system and this is what the first time they’re working in a particular role, they are too conscious to fail. They’re too conscious to express themselves as being wrong. So people get into that different direction if they’re trying to defend themselves. So, it’s a very good advice. And honesty is definitely something I personally appreciate. When you are transparent, when you are telling what the exact situation is, people around you feel more comfortable, take better decisions and it becomes easy for you and the other people around you to operate in a better way. So, great piece of advice, Eric.

Thank you so much for taking out this time and sharing your experience with us once again. Looking forward to having more discussions with you in the coming time.

Eric Heikkila: Sounds good. Thank you very much.

Kovid Batra: Thank you, Eric. Thank you so much.

‘Driving Success with Dev Autonomy’ with James Samuel, Software Engineering Manager at Reddit

In the recent episode of ‘Beyond the Code: Originals’, host Kovid Batra welcomes James Samuel, Software Engineering Manager at Reddit and author of the blog ‘Effective Software Leads’ with a rich background in organizations such as TIER Mobility and AlphaHill. He engages in a compelling discussion focused on the theme of ‘Driving success with dev autonomy’

The episode kicks off with a fun fireside chat with James, followed by an insightful discussion on the core responsibilities of an Engineering Manager at Reddit. Further, he imparts valuable wisdom on striking the balance between technical leadership and effective people management and sheds light on encouraging developers to think like Product Managers and the critical pillars of building high-performing teams.

Lastly, James provides actionable insights into effectively measuring team efficiency and performance using DORA metrics.

Time stamps

  • (0:07): James’ background
  • (0:44): Fireside chat
  • (7:35): James’ core tasks & challenges at Reddit
  • (9:51): Balancing tech leadership with people management
  • (12:54): Core expectations of an Engineering Manager
  • (17:02): Does learning new tech influence technical strategy?
  • (19:19): How to inspire developers to think like PMs and build high-performing teams?
  • (24:31): Gaining visibility into indirectly managed teams
  • (28:20): Metrics for tracking team efficiency

Links and mentions

Episode transcript

Kovid Batra: Hi everyone! This is Kovid, your host, back with another episode of Beyond the Code by Typo. Today with us, we have a special guest who has 12 years of engineering and management experience. He is the author of the ‘Effective Software Leads’ blog, which totally focuses on the difficulties of building and leading software teams in the 21st century. He is currently working as an Engineering Manager at Reddit. He’s also been ex-Head of Technology at TIER Mobility. Welcome to the show, James. Great to have you here.

James Samuel: Thank you so much for having me today.

Kovid Batra: So James, today, I think we’ll have a lot of questions to ask from you, a lot of things to learn from you, but before we get into that, I would love to know more about you, the audience would love to know more about you. So, we have this ritual of a quick fireside chat where we ask questions from our guests which are outside the scope of the work that they do so that we know you more. Are you ready for that?

James Samuel: Yeah, absolutely.

Kovid Batra: Great. Thank you so much. So, let’s get started. Let’s start with a very simple question. Tell us about your hobbies that you really like to pursue.

James Samuel: It’s an interesting question. I enjoy a variety of sports ranging from tennis, badminton, and sometimes volleyball. But one thing that I really like so much is playing tennis. In my free time, you either see me playing tennis or badminton, you know, either of the two.

Kovid Batra: Perfect. And tennis is a fit man’s game, I’m sure. I have tried it multiple times, but I’ve never been able to hit the ball inside the court, either it’s outside. Cool, cool, cool. So, do you play like state-level or something, or it’s just a hobby?

James Samuel: No, it is just a hobby. Something that I spend time with friends, I kind of like play, in my free time. Not really a professional level.

Kovid Batra: Okay. Got it. Got it. Got it. Cool. Perfect. I think this, this another thing, which probably is a passion for a lot of techies, like, you get started at an early age. Most of them whom I am talking to on these podcasts that they start early-age, coding or early-age interaction with computers. What was your first experience? When was your first time with the coding and the technology?

James Samuel: Yeah. great question. How I moved into programming or coding was really an interesting story. And it began around 14 to 15 years ago during my second year at the university. I was studying industrial chemistry. So, a friend of mine was also studying computer science at the same university. So one day, he came to my hostel and was writing some code on his computer. Later, I knew what my friend was writing was C++ and around this code and I saw the output and that piqued my interest. And I started to ask questions. How did you do it? Like, because it was just so, it was magic, you know, writing something that doesn’t make sense and then you could compile it and run it and then you see the output. And that day, I picked my computer, installed everything that I needed, and a week later, I bought a programming book and started practising. And I discovered that I really enjoy writing code and seeing the output of the code that I wrote than actually studying chemistry that I was doing at the university. So..

Kovid Batra: That’s quite a transition actually, from chemistry to actually coding, I mean. But, I think for a lot of techies, this early-age experience with coding has always been magical, right? I mean, which was your first code that you wrote, if you remember?

James Samuel: Yeah, so it was a game. I was trying to write a game where you kind of like guess a number. So it’s going to give you a box where you can input something and then you put the number and then it will tell you how far away you are from the number, how, how many. And if you get the exact number, you win. So, that was a very simple game that I programmed.

Kovid Batra: But back in that day, I’m sure this would have been another magic trick for people.

James Samuel: Exactly!

Kovid Batra: Cool. Cool. Cool. How old were you at that point in time?

James Samuel: So I, I think I was around 18-19 years old at that point in time.

Kovid Batra: Cool.

James Samuel: Yeah.

Kovid Batra: Perfect. All right. Moving on to my, my next question. What is that one quality about you that you really feel proud of or you think that this is something that you have really accomplished?

James Samuel: Yeah. If I’m going to look back, I’ll say kind of like pushing myself outside of my comfort zone. I’m kind of like, I tend to, I can, I get bored easily. And one of the things that excites me is trying something that I’ve never done before and kind of like pushing myself outside of what I’m comfortable with and kind of like testing new things, taking new challenges, and all that. And this has really been an interesting one. It has really helped me right from the beginning, even from pushing myself outside of, you know doing chemistry and moving into programming and finishing programming, trying to create software and moving from one school to another school to sell the software that I built. And at the same time, also kind of like pushing myself from, from one city to another and ultimately from Nigeria to Germany. So kind of like trying to, you know, find a new challenge and pushing myself outside of the comfort zone.

Kovid Batra: So, is it the curiosity in you that pushes you outside of your comfort zone? Or is it something like that when in needy situations, you push yourself out of your comfort zone, you get great rewards, and now you are trained, your brain is trained in a way that every time you have pushed yourself out of the comfort zone, you achieve something. What is it actually? Is it like innate curiosity or is it the reward mechanism that actually made you move in this direction of moving yourself out of that comfort zone?

James Samuel: Yeah, I think it’s a mix of both. At first we start with curiosity, being curious. How does this thing work? And what would this thing feel like? And then when I become curious, I tend to venture a little bit. And, when I get there, I’m challenged. I want to see this to the end. I want to do this. And half of that, the rewards that come kind of like something that helps me to keep doing that over and over again. So I would say a mixture of both, curiosity is there and also the rewards you get when you try something new and then you can say, “Oh, I’ve done that.” Yeah.

Kovid Batra: I think that’s amazing. And having a mix of both is actually cool because if that innate curiosity is missing, there are more chances of not letting you move out of that comfort zone for a very long period of time. So if you have both the things in place, probably it plays a much stronger role and then can take you even farther than compared to somebody who has either of those. So, cool. Cool. I think that’s nice. It was great knowing you, James, and thanks for sharing all this with us.

And now I think, we, the audience are eagerly waiting to talk to you about what you have done in your career, take some learnings from there. So, you have been an EM in Reddit, right? And you have been into this role and responsibility for, for quite some time now. So tell us about, let’s start with this. Like, tell us about your daily routine. What are your core responsibilities? And then you can tell us about the challenges that you see.

James Samuel: That’s a great question. Yeah. One of the things that I do at Reddit as an Engineering Manager, it depends a lot on the day and the challenges of the day or what my team is trying to achieve. I work on the core consumer product at Reddit and a typical day for me at Reddit could be hiring and interviews, for example, trying to fill the open positions that I have for my team. And, it could also, after I work also spend, I spend a fraction of my time sourcing candidates for those roles as well. And also reviewing a couple of codes sometimes, and also the experiment my team is running. At Reddit, we have a culture of experimentation, how do you kind of like build something and see how users react to it. So, we experiment a lot. And sometimes, it requires digging deep into code, looking at the data and see, the output, the impact of that feature we’re building. And, it could also be meeting with managers of other teams to sync on what we need from them, or what they need from my team as well. And also, partnering with stakeholders like Product Managers on defining the strategy, the road map for the team as well. And a huge percentage of my time is also spent in 1-on-1s, trying to kind of like, you know, coach the engineers, my team partner with them, support them as well, and also kind of like growing them because one of my roles is to make sure that I grow every one of my teams and understanding their strength and also leveraging their strength as much as possible and also helping them to level up where they need to improve as well.

Kovid Batra: Cool. I think there are quite some responsibilities that you have here in this role, but I’m very curious about one question here. A lot of EMs remain in this dilemma of, uh, taking up that technical lead kind of a role also, responsibility also in the team, while also managing people and taking care of the project deliverables. In your case, how do you manage or how do you keep this balance in place? Or do you even think that you should be moving in the technical direction where you are taking the decisions, the technical decisions for the team? So, you just gave me an example that sometimes you are reviewing the code. Is it something that you think the EMs should be doing on a regular basis and how do you do it? So can you just tell us about that?

James Samuel: That’s a great question. And it’s also something that I struggled a lot when I ventured into engineering management early. So one thing that I, I think that I used to assess myself that I think managers also assess themselves is whenever there is a technical task, ask yourself, “Is this the most important and the most impactful thing I could be spending my time on right now?” And this question, if the answer is yes, then go for it. Most of the time you might find that the answer is no. And the couple of reasons why it could be no, for example, there might be a strategy problem that your team might be having, the direction where the team is moving, the technical direction, that could be the most impactful thing an Engineering Manager could be spending his time on. And depending on the state of the team, it could be filling a critical position in the team. So if you kind of like line all of those things up, with reviewing code with, you know, making technical decisions, most of the time you might find that there might be something that is (more) impactful than doing that. And the second thing that I also try to do is if you are the sole decision maker for your team, technical decisions, then you are not growing the people on the team. So, you want to make sure you build a team that is able to function without you. Let’s say, you are only there for a month, the team should be able to run and still drive you back.

Kovid Batra: Right.

James Samuel: And by, by empowering them, you allow them to take decisions and support them from behind, from the back.

Kovid Batra: That really answered the question well. Realizing the impact of your involvement in the technical decisions would be the answer to take it up or not take it up. So, I think code reviews on a daily basis would be something that I wouldn’t do as an Engineering Manager, but if that particular code review is so important that it is going to impact, let’s say, or it can create a lot of technical debt or it is misaligned from that particular technical strategy that you have decided for the team, then probably reviewing in that particular week or in that particular month for the things that people are working on would be important for sure.

And apart from that, how do you, like as an Engineering Manager, I know that my team, like the business counterparts, basically the product team, right, they have certain expectations from me if I’m an Engineering Manager. What do you feel as an Engineering Manager is your core responsibility? Are they looking into this technical decision-making quality of yours at all the time, or are they relying on you to give them clear timelines, keeping the team happy, delivering projects with quality? What exactly is there in, in their mind as an expectation from you?

James Samuel: Yeah, that’s an interesting question as well. And before I answer it, one thing that I have seen in the past having worked with different Product Managers is expectations of Product Managers can be different, depending on where you are, depending on the team, depending on the company. And one thing that I try to do is to get together in the same room. Hey, what do you expect from me? How can I support you? Sometimes I see a little bit of differences between what the Product Manager might expect from another one, but overall it’s usually, there are usually some key things that I see across the board. And one of them is they also want to know the timeline. When is the project going to be ready? And sometimes they want to know how complex, should we build it or should we not? Usually there are a lot of computing priorities with different costs, engineering costs. So, they want to know these ideas that I’m thinking of how expensive is it going to be to build? And they also want to know how the project is going, regular updates. And at the same time, they also want input. Usually engineering would know how, uh, maybe if it’s expensive to build, if it’s not expensive. So they want to be able to know, get input from the Engineering Manager, like how expensive it is. Is this something that we can do? How feasible it is. And usually, these are things that I see across all Product Managers that I’ve worked with, in terms of expectation, what aligns.

Kovid Batra: Makes sense. Cool. So, I think here automatically there is a certain expectation from you in terms of timelines and to have those timelines, obviously, you cannot have clear timelines every time but to even have a tentative idea of what things look like you have to have a good understanding of what’s going on in the team, how this module which you would be working on could impact the other module which is already running, right? So, you have to have a good context of the code being written, how it is being written, where things are moving. My question to you is though both the things are required, creating that balance, taking out time to read about different technologies and to that depth where you are able to guide the people in the right direction, how much time do you attribute to this in a week or in a month?

James Samuel: That’s a good question. If I’m going to put a time on it, I think a huge chunk of my time is also trying to figure out what is happening across my team. And this goes around how the engagement of the team, what is the adrenaline, and also understanding what is happening in the code base that we are working in. All of these impact the timeline of what we’re building, like you mentioned as well. If it is very difficult to deploy, or maybe there is a bottleneck elsewhere, it will also impact the lead time delivery. So, most of my time in 1-on-1s, I try to understand how is the person in front of me feeling. Are they feeling engaged? And what are the bottlenecks, they are having right now? What are the technical challenges? What is wrong with the environment they are working on? And all of this kind of like, help me to be able to know how early is this team and at the same time, helping to know our throughput basically. Yeah, and I could go for that in terms of how I actually measure these, the dimension things that I look at.

Kovid Batra: I think we’ll, we’ll definitely come to that as well. My thought behind asking this question that how much time you attribute to learning new technologies is probably to find out how much a team needs from an Engineering Manager in terms of those decisions, right? So let’s say, you know, that your responsibility is to have 1-on-1s because that is very important to have a connection with the team to understand their problems, as you said. So you are allocating a certain amount of your time in that particular month or week for these activities. Do you dedicate time to such technical reading that really helps in taking those decisions, adopting new technologies? Maybe you are not building something from scratch, you are adopting something which is already existing, or it could be you’re building something on set, but the thought of bringing that piece into the architecture, into the code, into the day-to-day technical strategy, how does that work for you?

James Samuel: Yeah, that’s interesting. I think as engineers and Engineering Managers, I think technology evolves a lot and we need to constantly keep ourselves up to date. For me specifically, I spend a huge chunk of my weekends and maybe after work reading technology blogs, reading books, and also reading about emerging technologies. And it’s a little bit complicated because when you are a full stack Engineering Manager, you also have to read about mobile, iOS, what is happening in the Android world and what is happening backend infrastructure-wise. So there’s a lot, I spend a huge chunk of my time learning this and I also actively encourage my team members to kind of like go for conferences, buy books, even recommend books and things just to kind of like, you know improve, and then how can we apply new ways of doing things to how we work.

Kovid Batra: I think when, when you want to empower your team to like perform, deliver, right, they, they look up to someone, they need that figure in the team. So, probably when you have the context of how the business has to run, how things have to be delivered on that end along with the technological understanding, I think that inspires the developers the most probably.

And, I was recently, like reading this article and then I shared it through my LinkedIn post also. It was about that most of the high-performing teams are those where developers actually are able to think like Product Managers. They don’t have to do that exact role, but at least if they have empathy, if they have an understanding of what value they are delivering through their code, I think that’s the best scenario to be in. So as an EM, you can actually inspire your team to do that. And with that, I want to know, like how you actually bring in this practice into your team, into the developers and how do you, what’s your style of building that high-performing great teams at Reddit?

James Samuel: That’s a good question. So, there are two things here. For example, how do I enable engineers to think like Product Managers? Kind of like reason about the impact of the code, right? And how do I build high-performing teams? Those are really great topics that are actually very close to my heart.

So, one of the things that I do when I onboard a new engineer to my team, I start to let them know this is not about the code you write, it’s about the impact you are going to create. So when you assign a task or you are to do something, don’t think about the end goal, me writing the code and deploying, that it doesn’t end there. It is me writing the code, what is the assumed impact that this is going to bring to the company, and also seeing it through to how customers are using it and also tracking the metric to see if it’s actually bringing that in part. And one way that I try to build this is through performance reviews and all that. Rather than looking at output, we look at the impact you’ve created. And also enabling the team to kind of like if you are going to pick these tasks, what impact will they bring to the team? What impact will they bring? Will they kind of like maybe move us closer to our KPI or the goals that we’ve set?

And to the second question around building high performance, how performant is the team, I think there are four critical pieces that I think are crucial to build a team that is high-performing. One of them is something that I call ‘synergy’. And, one thing if you see a team that doesn’t have this, you see people moving in different directions. I like to use an analogy of a football, if you are a soccer fan. So one thing you see everyone’s playing, the goalkeeper knows his role. The striker or whatever, they all, everyone playing on the field, you know, supporting each other. And at the peak performance, one of the things that you see is that everyone is in sync. They all know their role. And this is where the peak performance happens. In software as well, synergy has to be there. It has to be working towards a common goal. Everyone has to know their role, what role they have to play in getting that. There has to be a clear direction.

And then the second one that I think is crucial is a culture of continuous learning and improvement. So, one thing is no matter how performant your team is, there’s always going to be a time when they will drop the ball. Something will happen. So, for them to continue to perform is to learn from that mistake. Can they reflect on things that didn’t really go away, improve on those things and keep moving? I think these are, these two key things are very crucial in building high-performing teams.

And another one is also ‘autonomy’. Something that I call empowering engineering teams, kind of like similar to what I mentioned. If you are leading a team that cannot exist, they can’t do anything unless they have their leader, then that is not a team that is empowered. You want to make sure that you take yourself outside of the job. Can you empower them, allow them to be able to own things end-to-end in such a way that if you are not there, the team is still working and working? And this is about allowing them, empowering them, supporting them from behind and not being a sole decision maker. Help them even to come to you, help them to reason how they can, help them to arrive at the decision, not to make the decision for them and this, I think is very crucial in building high-performing teams.

Kovid Batra: Cool. I think these are very good points. Having that synergy, autonomy in teams is very crucial. And I think, engineers themselves are, I believe intelligent species, right? They, they like that autonomy. They like to question things. So automatically, if you are imbibing that feeling of questioning things, what is the impact of what you are doing, if you’re just reinforcing it time-to-time, bringing synergy amongst them to deliver towards a similar goal, I think that really really works well for the team. So great piece of advice, James. And I think you are driving some great teams at Reddit right now.

Cool. With that, I think one last question I have. So, I’m sure there would be people who are directly reporting to you, right? Then there could be some indirect reportees too, right? So, in those scenarios where you have indirect reportees and you don’t have direct visibility, you can bring in that culture, give them goals, do the right hiring, right, set great examples. But I feel on a day-to-day basis when you’re running your sprints, right, when you’re seeing the performance over quarters, you just have to make sure that teams are being efficient, right? You don’t want to, like stress them out with too much work, but you want to see them being efficient. And of course, you have to take care of their wellbeing. How exactly do you gain that visibility when you are not talking to those five folks, there are indirect people also working along with you whom you’re responsible for, what are your ways of looking at and measuring that efficiency for them?

James Samuel: Yeah, that’s also a very good question. So when I was Head of Engineering at TIER, so I had this problem a lot. So I was managing 4 teams, engineering teams. And each team has an engineering lead directly working in this team. So, one of the challenges that I had is getting to know what is actually happening in all of these teams that I don’t directly manage and to be able to know how to support them as Head of Engineering. And there were four key frameworks that were really, really crucial in gaining this visibility. I do think for managers, leading teams that they are not directly managing, they need to get both quantitative and qualitative data that will help them to know or understand how these teams are building what they are building on time and within the budget they have. So, I call this ‘process’. And they also need to be able to get data that will help them understand if the things that these teams are building will continue to run at this higher level of performance and reliability, and they will continue to do so in foreseeable future. I call this ‘operation’. And they also need to be able to get quantitative and qualitative data that’ll also help them to understand the people building all of these things. Are they engaged? Are they happy to continue to build it? And they also need to get data that will also help them to understand if users they are building all of these things for, if those users are getting value and deriving satisfaction from them. And I call this ‘product’. So, these four pillars are very important to have visibility into teams that you don’t directly manage. You want people to know how are they approaching the software they are building right now. What is the process? How do they come across? How do they decide what to build and what to work on? How do they do prioritization? And you also want to be able to understand the state of the software they are building. Is it reliable? So what is the SLO like, and what is the infrastructure like? And then you also want to be able to understand the people that are building it. Are they engaged? Are they working on things they are interested in? Is someone about to leave the company? So, and you also need to be able to understand the people you are building for. If engineers are super happy, they are building that thing. And they are building it with all the reliability and performance you can think of. And at the same time, they have strong process. They can deliver, they deploy on time, and at the end of the day, users that you are building for are not getting value. They don’t like the product. You see no one. So, you need to be able to get data across all of these to know to be able to support the teams effectively.

Kovid Batra: Is there any specific tool or any specific method, any specific metrics that you are using to track all this? Like, some things are very qualitative, I’m sure those cannot be measured through objective numbers, right?

James Samuel: Yeah.

Kovid Batra: Like, how they’re prioritizing or how they’re making their decisions is something which you can understand through 1-on-1s or through pulse surveys where you can, like gather feedback from them on different questions, but is there anything else that you look at objectively when you look at the efficiency of the teams or the performance of the teams?

James Samuel: Yeah, that sounds good. When it comes to performance and productivity of the teams, one thing is certain, it cannot be measured through one single dimension. So, there are people who just look at, like how many times do you deploy in a day? And that’s it. How many pull requests? How many lines of code? It can be a tough one to measure, but one of the things that we’ve used or that we use a lot that I’ve used in the past is DORA metrics. And this can be very, very important because it allows you to get data from multiple dimensions to understand how the team is doing. And this is how a lead software engineer or software teams use to kind of like measure their performance. And one of them is the deployment frequency where you measure how frequent or how often do you release code to production. And this is about how fast can we get value to users. And when you see a team maybe deploying once a week, there’s a chance that the process is not right or something is wrong somewhere. And another one is the lead time, the amount of time it takes to get a code into production. How long does it take to deliver value to users? And there could be a lot of things responsible for this. It could be that the team is spending time, you know, not breaking the work into smaller, they are not doing rapid iterations, like small iterations. It could be a number of things that could be responsible. And another one too that I look at is what percentage of this value, of this change we are making is effective. And this is change failure rate. If we are trying to be as fast as possible, deploying as fast as possible, and at the same time it’s getting to production and it’s defective, then something is wrong with the process.

Kovid Batra: Right.

James Samuel: And yeah, and the last one is the time to restore service. No matter how, how great a team is, there’s always going to be a time when something will not go right. You will have an incident. So, and what matters is how long does it take an organization to recover from the failure when it happens, how fast can we get back up running?

Kovid Batra: That’s cool. I think that was a very detailed view of how you’re using DORA metrics and I’m happy to see that you’re using it to the fullest in terms of understanding not just one metric and looking at it from one dimension, but correlating a few things to actually understand the picture. So I think James, what I should call you, a ‘super EM’ then? No, actually this, this was really cool. I think, at your age, the level of experience you have, the kind of thoughts that you have of leading the teams, I feel are amazing.

So, thanks, James. I think this discussion was really amazing. There was a lot to learn from you and I think this 30 minutes of discussion is not sufficient for me to get all the things that you have experienced and implemented to make great teams at organizations, wherever you have worked. So, I would love to have you back on the show sometime again and talk about these topics in more detail, probably.

James Samuel: Absolutely. Thank you so much for having me as well.

Kovid Batra: Thank you. Thank you so much for your time. Have a great day, James.

James Samuel: Yeah, you too. Bye.

‘Tech teams: Assess, Adapt, Transform!’ with Andrei Gavrila, Agile Coach & Fractional CTO at Pentalog

In the latest episode of ‘Beyond the Code’ Originals, host Kovid Batra welcomes Andrei Gavrila, agile coach and Fractional CTO at Pentalog. He has also previously contributed his expertise to Eurofins Group, Trace One, and Accenture Technology Solutions. The core of their discussion revolves around assessing, adapting, and transforming tech teams.

The podcast starts with a fireside chat with Andrei Gavrila, providing us with a glimpse into his personal interests. As the conversation progresses, he takes a deeper dive into the challenges faced by fractional CTOs in startups and large-scale organizations. Further, he sheds light on implementing agile at scale in large organizations as well as measuring the success of engineering teams, especially when determining team structure and topology.

Lastly, he discusses the ‘Maturity Model’, a valuable tool for engineering leaders and CTOs aligned with an agile mindset.

Time stamps

  • (0:06): Andrei’s background
  • (0:39): Fireside chat
  • (5:01): Does Andrei primarily work with small or large organizations?
  • (6:40): Challenges for fractional CTOs: startups vs. large-scale organizations
  • (9:35): How to balance strategy in uncertain startup environments?
  • (12:45): How to implement agile at scale in large organizations?
  • (18:22): How to assess the success of engineering teams?
  • (20:29): Examples of setting team context over metrics
  • (24:28): The four states of maturity models

Links and mentions

Episode transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today we have a special guest from Romania with us. He has 16+ years of engineering and leadership experience. He’s working as a fractional CTO with Pentalog. He believes in consulting, and not just consulting, but then implementing solutions with the clients. He does technical audits, MNAs for all the tech teams. And he’s one of the highly recommended mentors on MentorCruise and Plato. Welcome to the show, Andrei. Happy to have you here.

Andrei Gavrila: Happy to be here too.

Kovid Batra: Great. Thank you so much for taking out time. And before I get started and our audience gets a lot of learning advice from you, I would like to know a little bit more about you, the audience would like to know a little bit more about you and we can, like start off with something like, how do you, how do you unwind your day? Where do you spend most of your time when you’re outside of work?

Andrei Gavrila: Good. So, I like to spend time with my family, so that would be number one. Then, I relax through learning. Maybe that sounds funny, but not to me. I really enjoy learning. So, usually at the end of the day, I am trying to squeeze one, one hour, maybe half an hour, so that I learn new things and I also like to play video games.

Kovid Batra: Oh, nice. Video games. So, this is like a childhood thing and is it like something which started very early on?

Andrei Gavrila: Yeah. Yeah. I started playing, I think, video games when I was five years old.

Kovid Batra: Oh yeah!

Andrei Gavrila: I don’t even remember what the name of that computer was, but the first game that I played was called ‘Prince of Persia’.

Kovid Batra: I remember it completely, man. All right. Which one are you playing these days?

Andrei Gavrila: Nowadays I’m playing a game that’s called ‘Total War: WARHAMMER’. It’s a strategy game. I think it works really well with the role that I’m doing that has a very strategic part. So yeah, I enjoy strategy games.

Kovid Batra: Perfect. Perfect. That’s an interesting find about you. All right. Apart from like unwinding your day with games and maybe taking some learning from there, what are the other learning sources that you have in your life? Like, do you do, read books or watch videos, listen to podcasts?

Andrei Gavrila: So, I’m trying everything, but maybe what the best learning tip that you might get from me is that not necessarily sources, but the way that I learn. So to me, first of all, learning is not reading or watching videos. To me, learning means changing behaviors. When, when we do that, the learning cycle, in my opinion, ends. And I think a lot of us associate learning with maybe reading or watching videos, but I think until the moment that your behavior doesn’t change or you don’t change anything, uh, I wouldn’t call that learning. And one of the things that I do to learn is I use a framework that’s called the 70/20/10 that says that for every, let’s say 100 hours, you should try to learn 70 of them through experience. So your job, the regular day-to-day stuff, 20 of them by learning from peers. Even what we do now, I would call it engagement learning from peers. So, it doesn’t necessarily need to be too formal. And 10 of these hours, learning in a structured way. So things like books, videos, podcasts, exactly what you said.

Now, if I were to recommend some of the let’s say some of my learning sources, there are many. I will share with you and maybe the audience, Trello board that I have where I’m keeping track of the learning that I do, but most of all, I would like to say that since I’m using ChatGPT many times a day, I feel that that boosted my learning significantly. Sometimes I even do let’s say, interviewing styles with ChatGPT where I’m asking it to ask me questions about a specific topic or a book I might have read. I think that’s really, really amazing.

Kovid Batra: Oh, that’s really interesting. We have always been asking questions to ChatGPT, but we never asked ChatGPT to ask us questions so that we are able to learn more. That’s, that’s very interesting. I would love to see that Trello board also. So whenever this podcast is going out, I’m sure, in our comment section, we would love to see that coming from you.

Andrei Gavrila: Sure. Definitely.

Kovid Batra: Amazing, Andrei. And, thank you for sharing your personal way of learning and some thoughts on that.

Let’s move on to the main section, uh, where we would love to know what you do in day-to-day as a fractional CTO, like things like how you’re managing your teams there. First of all, I just wanted to understand, when you work as a fractional CTO, right, are you specifically working with small-size teams or is that these large-scale organizations? What kind of organizations do you work with?

Andrei Gavrila: Yeah. The term ‘fractional’ can be confusing. Sometimes it might be confused with just ‘consulting’, sometimes it might be confused with ‘interim’. We will not get in the depth of the term because I don’t think it’s that interesting, but I like to work with all types of companies. Most of my experience is around, let’s say medium to larger companies. In reality, the term ‘fractional CTO’, I think works a bit better for startups. For example, you can be a CTO for two to three startups and you’re fractional there, fractional there, fractional there. But me, my, the things that I enjoy most doing is work with bigger companies that have problems around scaling, that see opportunities around these economies of scales delivering to millions of users that are looking for more efficiency, that are looking for predictability, they try to mix a world of legacy with the innovation that we can do today. And they are working a very fine balance between, let’s say those two domains.

Kovid Batra: Makes sense. Perfect. So, when you say it makes more sense with startups, I think you must have had some experiences with startups and you must have seen the challenges of being a fractional CTO with these startups, right? And I’m sure if you, if you got a chance to work with large-scale organizations, there, there would be a different set of challenges. So let’s start with the startups first, like what kind of challenges do you see and how do you tackle them, and then maybe we can discuss about something, for large-scale organizations, how to effectively build teams there and, like execute with teams there. So..

Andrei Gavrila: Sure. I would tell you first that in Pentalog, we define a CTO assessment. So, because we work with so many CTOs and we see the role implemented differently, we said we would like to help people better understand what the role of the CTO is, how it should be done and what different implementations of this role we see in the industry. And because of that, we define services around that. One service is CTO assessment, helping CTOs understand how they’re performing their roles. This is used both for growing or for recruitment. Then we have services around mentoring and a lot of the consulting that we do, also helps this role. But the idea is that in general, what we see is that in the startup world, the role of a CTO is more, is closer to a technical lead role, right? So, somebody who is coding and driving the technology very hands-on. So, sometimes the startup CTO is the person that has the most development experience, somebody who will code the hardest parts. And that’s normal because that’s what startups do. They try to put a product in our hands as quick as possible. You want to create the product. But, they are in a way exposed to the risk of missing the strategic part of the role of the CTO. So things like governance, things like how do we make sure that the decisions that we take today are still in control and will still be in control, once we succeed, once we want to scale, once we reach a phase of hyper-growth. These kinds of things are not really the best things that technical lead or startup CTO could answer. So, that’s the kind of work that I do when I work with a startup CTO. So, bringing more of that strategic governance, efficiency, decision, cost of ownership review.

Kovid Batra: Great. Perfect. But don’t you think, like with startups, which are in early stage figuring out product-market fit the strategic thinking could not be very, like long-term, right? Because they don’t know what they are going to build. Sometimes it happens, the customer itself changes, right? You shift from one segment to another. So, in that scenario where there are so many uncertainties involved, maybe you yourself would want to keep things streamlined in terms of strategy, but how do you communicate that and create a balance with that dynamic environment?

Andrei Gavrila: Yeah, that’s a, it’s a really good question. It’s not about bringing the kind of order that you would find in medium or larger enterprises, but it’s about finding the right balance as you say. I would give you an example. Startups usually decide without really analyzing and really understanding their decisions because they are in this space where they need to take a lot of decisions and there are some decisions that can really impact the long run. And also there are some decisions that become a problem after a while. One of the things that I do when working with startups, I’m saying we can decide whatever we want, but how about we try to keep track of the major decisions, and to explain it to our future self, why we took them in this way, and maybe when this decision will expire, or we need to revise it because something happened. I think this gives a lot of clarity in the life of a startup because it allows it to plan the development. So for example, you would take one decision around hosting or infrastructure or several capacity. But if you don’t specify that that decision will no longer work when you reach 10,000 users, you might reach 10,000 users and face that problem just then.

On the other hand, if when you decide, you know when that break up point might be, maybe when you go towards the 10, 000, you go close to 6, 000, we’ll start working on that because you have this clarity around what you decided and when these decisions are not working anymore, right? This is the kind of, let’s say, strategical or governance-thinking that is not natural for, uh, as I said, the startup CTOs, because their context is much more now let’s put the product with the right set of features in the hand of our users, but nevertheless, they decide and sometimes these decisions don’t remain in control.

Kovid Batra: No, absolutely, I get it. And it’s, it’s more about just taking a conscious decision whenever you are moving ahead. And at least you would be prepared, you would take a few better steps to handling the future problems also. So, it makes complete sense, absolutely.

Other than that, like moving on from startups to some, let’s say large-scale organizations, you mentioned in our last conversation, when we were talking that you take care of the agile, implementation of agile methodologies in the teams and you do that with different companies, right? So when it comes to large organizations where you see these methodologies are being wrongly perceived or people are executing in a wrong way, how do you bring that agile transformation with such large organizations where there is so strong cultural set up already there when you are entering as a fractional CTO? So, is there a good piece of advice for people who are looking to implement agile methodologies at scale?

Andrei Gavrila: Yes. I hope I got your question right. I will try to answer it and let me know if you, I understood it right. A lot of companies today are in a state of continuous transformation and constantly wanting to do more and better. I think the term ‘agile transformation’ has its benefits. I think it has less and less benefits, because kind of gives this impression that there is a finite thing that needs to happen and then we are transformed somehow. I think the context today is much more one in which this constant adaptability to what happens around us is permanent. And I think we are less in a phase to speak about agile transformation than speak of somehow the new normal, which is, how do I make sure my company is fit so that it can adapt no matter what happens somehow?

Kovid Batra: Exactly, exactly.

Andrei Gavrila: And a lot of companies that are maybe trying to work on that now are going through two main ways, especially the big companies. One which is the ones that we see most often where their transformation is very tied to frameworks and methods or topologies or in a way, processes, if you want. So a lot of companies are saying, “Let’s put Scrum in place or let’s put SAFe in place.” So that’s, in my opinion, most of the industry, that’s what most of the industry is doing. And that’s one way to approach that.

The second way to approach that we also see in the industry is something around culture, something around the way that we look at problems, mindset. A lot of companies will speak about proximity to customer, which is really nice because in a way that’s what agility is. But, a lot of companies are approaching that transformation saying, “Let’s try to change the mindset, the culture in our company to be closer to the customer.” And these are the two big ones to do, the two ways that companies today are approaching transformation and the reality is that to some, I wouldn’t say most, it could be a debate if it’s somewhat most, it’s not really working. They are not seeing benefits. This is why in Pentalog, what we do is we go to a third way which it’s not that obvious in the industry. And this third way, it’s about structure and government. Maybe I’ll give you an example so that everybody understands what I’m trying to say, but our idea is what kind of rules do you need to respect in order for you to be adaptable?

So, let’s give an example for the these three ways of doing it so that it’s a bit more clear. As I said, for the first one companies would say, “I’m going to be more adaptable because I’m going to use Scrum/SAFe, and this is a structure that allows for adaptability.” So if I’m having the structure, then I will probably adapt. That’s the, the philosophy there. The other one says, “I’m going to try to change people’s mindset, the way they approach things. And they maybe try to go then to a process of training, a process of understanding better, how things should work, speaking more of a customer, placing customers closer to the way that they will, they work.” That’s how they think, it will go. And in our case, we come and say, “What kind of rules do we need to respect?” And one of that rules could be that I’m having cross-functional teams so that I’m all over the organization, I’m having teams that don’t depend on other teams to deliver value. and that’s, for example, one of the, that’s the way that we do transformation, which is in my opinion, working much better than the other two ways.

Kovid Batra: Perfect. I think this is a very relevant example and the thoughts that teams should look into and probably when, when we talk of agile, we probably always look at speed, implementing certain practices like scrum, but the core fundamentals that need to be implemented are around customer-centricity and bringing adaptability with the change. And I think one of the ways that you suggested right now perfectly fits in.

So, cool. This was, this was really nice. But, there is one more question, like quite unrelated, but I feel that when you’re working with large organizations, you divide them, you decide the right structure, topology for the team you’re working, But, at that such large scale, one thing that goes missing is how do you look into whether the teams are succeeding or not, right? Engineering teams are succeeding in what they want to do or not. So, what kind of framework or methods or let’s say the metrics you would use to understand that? That whether these teams are succeeding or not succeeding, how do you define success for them?

Andrei Gavrila: Yeah. I’m really passionate about that question and I think we could talk about it for hours. I will try to answer it maybe in the next two to three to four minutes.

Kovid Batra: Sure.

Andrei Gavrila: The thing that’s most important to me is that a lot of companies are asking that question, how do I know if my teams are efficient? How do I know if my teams manage to do what, what we need them to do? And the approach to that is usually to define KPIs and see if the teams reach those KPIs or not. Some companies look at velocity. I don’t recommend doing that. Some companies look at output. Some companies look at impact, outcome, that’s much better than velocity, outcome and impact. But to us in Pentalog and to me, the question is not, how do I know if my teams perform? Right? The question that I like to ask first is how do I know that my teams are in a context where they can perform efficiently, where they can be excellent? So instead of asking, “Is this team performant?” I like to ask the question, ” Is this team in a context that allows for performance?

Kovid Batra: Makes sense. Perfect. I think that that’s very relevant. So Andrei, that’s a really cool advice. I think setting the context right is more important than looking at metrics probably because that sets the fundamentals. But I would love to know how do you do that in your teams? Like, can you just like deep dive into it a little bit more so that we have some examples? Yeah?

Andrei Gavrila: Yeah. Sure. We are using something called maturity models. Maturity models got a bad reputation, some time ago, because they were used in a very heavy way, very, let’s say, non-flexible way. But we developed some maturity models that are really aligned with this agile mindset and are really one of the best tools that CTOs, engineering managers can use to answer those questions. Am I in the context where my team could perform or not? And these maturity models are very simple to understand. They contain items that you can say they are done or not. And the whole idea is that it will help you understand in which one of the four states you are on a certain dimension.

So, let’s pick security just as an example. You have a software development department, multiple teams, and you are asking yourselves, “Where are we on security?” So, with the help of our maturity models, with which are, as I said, very easy to use, you’d be able to say, if you are in a state of ‘starter’, that’s what we call it. And if you are in a state of ‘starter’, it means you are in a significant risk of failure. Or you could be in a state of ‘almost good’, which usually means that you are no longer in that immediate risk of failure, but you have a lot of waste in the process. And then, there is this column that’s called ‘good’, which means that you’ve passed that wasteful moment, and now you are actually working to optimize the system. The last one is called ‘very good’, in which if you are, you probably have competitive advantages because you do more than what your competition is doing. And you can think that we have these maturity models for everything, security, but we also have them for people engagement and now if you want, we can try to create such a very small maturity model between ourselves around people engagement. So, what is one thing that you think companies should do to no longer be in an immediate risk of failure around people engagement? What, what do you think companies could do to no longer be in an immediate risk of failure around people engagement?

Kovid Batra: Like, they, first of all, like they can go back to the people and understand from them that what are those different areas where they feel uncomfortable, what are the things that are making them not perform or not be the best version of themselves. So we can go and understand from them.

Andrei Gavrila: Exactly. That’s the kind of item that you would find in that column where we are not necessarily going to tell you how to do it. We’re not going to tell you, do it and ask them these questions and check these answers. But we would say, if you’re not asking periodically, asking your team how they feel, do they like what they do, what are their biggest problems, then most probably in terms of people and people engagement, you are an immediate risk of failure, meaning people might leave tomorrow because they are not happy with what they do. They don’t feel respected or this kind of stuff. So this is exactly how our maturity models are created and are populated by these kinds of items.

Kovid Batra: So I think that’s, that’s perfect. You said there are four dimensions, right? So, one is security. One is people. Can you just name the other two? I think I got the context of what you’re saying.

Andrei Gavrila: The dimensions are, are these columns like ‘starter’.

Kovid Batra: Oh, okay. Got it.

Andrei Gavrila: The second one is ‘almost good’, which is waste. The third one is ‘good’, which is efficiency. And the fourth one is ‘very good’, which is a competitive advantage. So, all the maturity models have these columns, but then we have maturity models on people engagement, on skills, on security, on data, on architecture, on infrastructure, on testing, on engineering practices and many more.

Kovid Batra: Yeah, right. I think I got your point. For every, like there are a lot of aspects of an engineering team. And for an engineering team to be successful, all these areas which we define, they should, like keep improving in these segments that you’re talking about. So..

Andrei Gavrila: Exactly.

Kovid Batra: Perfect. I think that’s a very relevant thing. And I’m sure this comes with a lot of experience.

Andrei Gavrila: Yeah. So, last thing that I would want to add here is that when people ask me, how are my teams performing, I feel that they are not efficient or they are not working out. First thing that I do is say, “Let’s try to fill this maturity model, and to understand where we are. And then once we fill them, I’m saying, see here and here and here.”

Kovid Batra: Right.

Andrei Gavrila: You are way below, let’s say safety. So in a way, until you manage to fix this, you will have maybe just marginal improvements.

Kovid Batra: Totally. Great talk. Great talk, Andrei. I think thanks a lot for sharing all these insights and relevant examples. I would love to have another session with you sometime because I think these few minutes are very short for us to learn all those things that you have done in your past. So, we are trying to do that 70% bit from the experience, right? So, cool. I think we’ll connect again for sure. Thanks a lot for taking out time today and talking to us.

Andrei Gavrila: Sure. Sure. It was really great being here. Thank you for the invitation. Have a great day.

Kovid Batra: You too, Andrei. Thank you.

‘Can AI tools Drive Engineering Success?’ with Sayak Saha, Director of Engineering at AUTO1 Group

In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Sayak Saha, Director of Engineering at AUTO1 Group, with a rich background in organizations such as Wipro Technologies, Amazon, and Dell. He engages in a compelling discussion focused on the theme of ‘Can AI tools drive engineering success?’.

The episode kicks off with a fun fireside chat with Sayak. As the conversation progresses, he addresses the key considerations for scaling a development team. Furthermore, he explores strategies for fostering seamless collaboration among engineering, design, and product teams to enhance product development efficiency, particularly amidst challenges such as ambiguous requirements and communication barriers. Sayak also shares valuable perspectives on integrating cutting-edge AI technologies like GitHub Copilot and ChatGPT into existing legacy codebases, addressing concerns such as tool fatigue and optimizing resource allocation.

Lastly, Sayak talks in great detail about ‘Build vs. Buy vs. Run’ framework and essential benchmarks for evaluating the success of an engineering team.

Time stamps

  • (0:06): Sayak’s background
  • (0:35): Fireside chat
  • (4:07): Challenges to consider while scaling up dev teams
  • (8:56): How to prevent process overkill with optimization & efficient communication?
  • (11:33): Enhancing collaboration between engineering, design, and product teams
  • (16:21): Effectively riding the AI wave: Tools & Tech
  • (23:29): What is the ‘Build vs. Buy vs. Run’ framework?
  • (27:10): How to define the success of an engineering team?
  • (31:22): How can developers be aligned with business goals?
  • (34:41): How to assess the efficiency of your engineering team members?

Links and mentions

Episode transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have our special guest who loves to talk on podcasts, share his knowledge with the community. He has 16+ years of engineering plus leadership experience. And he’s one of the engineering directors at AUTO1.

Welcome to the show, Sayak. Happy to have you here.

Sayak Saha: Hey. Hi, Kovid. Thank you for hosting me and looking forward for a nice conversation with you today.

Kovid Batra: Thank you, Sayak. Thank you so much for taking out this time and willing to share your thoughts with the community. So, before we get started, there is a quick fireside chat, where we talk to our guests about their personal space so that the audience knows them well.

So, are you ready? Can we get started?

Sayak Saha: Yeah, sure.

Kovid Batra: All right, perfect. So, let’s start with your favorite travel destination.

Sayak Saha: Okay. I love to travel a lot, but especially seas because you have a chance to, to mix, play sea sport and enjoy good food. I think my favorite destination is Langkawi and to be honest, any sea beaches.

Kovid Batra: Cool, cool. We meet another beach person then. All right. Perfect. What about your heavy days? How do you unwind yourself at the end of the day?

Sayak Saha: Okay. So, my day starts with my daughter. So in the morning, first thing to drop her to school. Okay, so that’s how the day gets started.

Kovid Batra: Okay.

Sayak Saha: And after that, it’s like reading some books or news and then having a coffee and starting the day with a walk. And then I don’t know how the day just gets going.

Kovid Batra: No, that’s cool. And what do you do usually at the end of the day? Like, let’s say it’s a hectic day. How do you unwind?

Sayak Saha: Okay. Generally, if it’s nowadays I started doing is like in between meetings, I am always keeping 5 to 10 minutes, uh, to do a a bit of reset because that helps you to focus in your next meeting or whatever you are doing. Okay and apart from that, I love to play chess and this is something I started this year.

Kovid Batra: Oh, cool!

Sayak Saha: So, I try to play at least two to three games a day.

Kovid Batra: Cool, cool, cool. That’s nice. What was your last book that you read and could you share some learnings from there?

Sayak Saha: Okay. The last book I read a little while ago, maybe a few months. So it’s ‘Measure What Matters’ by John Doerr. He is a famous venture capitalist and engineer. And this book majorly talks about how you set your priorities and you drive things and basically setting up OKRs and KPIs. We talk about OKRs, KPIs a lot, how this translates to engineering organizations, how you measure it, how you can define your stuff, right? So, this book talks in more detail about it. And there are actually classical examples, how Google, Microsoft, Amazon, they did it for themselves. Okay.

Kovid Batra: Oh, okay.

Sayak Saha: And John Doerr himself, he’s a board director in this company. So he has guided that how he convinces people and how he improvises OKRs and stuff. So this is a great learning because as engineers, we often see that there are company goals that, hey, I want to increase revenue stuff and all, but how this translates to engineering orgs is something that gets lost, and this book is a great guidance for that.

Kovid Batra: Amazing. I think we’ll talk about this in the later part of the show also. I think I have a few questions there, but let’s get started. Thanks. Thanks for sharing your personal space with us, telling us about yourself. I think that was quite good.

We can move on to the main section. And in this, we would be talking about challenges that you see with a growing team. And of course, there would be a lot of other questions that might not be related to it. But, I think what we want to learn from you is what you have experienced in your career so far.

So, probably starting off with something that is related to the topic of challenges that we come across when we grow as a dev team, right? So, what are the important pointers that one should keep in mind when they are considering to scale teams? Because let’s say you have raised your Series A, and then you already have found a first-level of product-market fit. And now you know that, okay, this is the trajectory for next one to two or three years where you want to scale the dev team. What are those important things that you as an engineering leader would take care of?

Sayak Saha: I think this is a very difficult and easy question both way, okay? Because everyone has done it probably at our experience the same thing in their course of life, right? But I think the major challenge, right, what happens is every company has their own culture and their way of doing work, right? And probably the example which you have mentioned that when you are a small company, you might have a small engineering team who are doing a great work, right? Every member in the team is super contributing. They are taking charges and stuff, right? So, when you scale team, you think that, “Hey, I will have another super-awesome team just be there. We’ll be performing in the same pace, the same motivation.” Right? Or maybe two, three, whatever. But, when you scale teams, right, that gel or that thing doesn’t happen that way because you have to build organizational hierarchies, the communication path changes and all.

So I think in that way, right, there are probably top 3-4 things that we look into. One is find the magic what works for your team, what is working for your current team, what is the team composition, right? I mean team composition means that composition of the developers, like how many front end developers do you have? How many back end developers do you have? Or how many product managers do you have? Do you need an engineering-focused product manager? It depends product to product, right? Okay. So find the right composition for your team. That’s first.

The second thing is that what would be the communication model for your team, right? In small organizations, generally, it directly comes from the founders that, “Hey, I want to try this experiment. Let’s do this.” Right? When teams are small, generally the founders sit with the developers, maybe in some cubicle and start saying, “Hey, let’s do some whiteboard, blackboarding, whiteboard sessions.” And we start doing it. But when you scale teams from maybe 20 to 50, 100, doing such whiteboard sessions always is not possible. So, how you set up the communication model to flow the ideas top-down and effectively that, that matters. Okay.

I think the third part is we scale team with some hope that I will meet some goals, right? It’s important to set up those goals and objectives and set up clear expectations before the teams that, “Hey, I expect this from you.” Otherwise, the objectives are lost at the point that we have the big team and then start saying that the priorities change. What is like the ‘must have’ vs ‘nice to have’ somehow gets diluted when, when teams grow. So setting up the right OKRs, KPIs, these things matter, right? And I think the other part is that when you are small, your teams at times are very autonomous. So, it’s very important that how your team composition and this communication and leadership is structured so that the autonomy of the team is not lost.

Kovid Batra: Right.

Sayak Saha: It should be very hierarchical and stuff, right? And apart from this, I think the other thing comes up, right? When your teams grow, there is an inherent challenge of bottlenecks, right, with the DevOps, IT, and, and others’ things, right? And the things whether we’re, we are supporting a 20-member dev team is much easier or much easier than when you have a 100-member or 200-member team.

Kovid Batra: Correct.

Sayak Saha: Which asks for automation. So, which means that an early stage, if you look for all those automation scopes that, that these are the areas, these are the things I need to automate, it’s not only about the CI/CD pipelines. It can be as simple as onboarding a team member, right, onboarding a team member and creating his accounts across all the systems, right, how you can onboard him, that simple. I mean, what are the dev tools you can support, how quickly a developer can onboard, because someone cannot sit next to him and all. So, I think building that automation around it. So I think these are the major things which people learn while doing like when you are really scaling the team. Definitely there are other challenges like hiring, the internal conflicts, growth and other stuff. But I think these are the major things that I have faced.

Kovid Batra: That makes sense. Yeah. I think one point really intrigued me, like when you’re, when you’re scaling, you just have to make sure that the processes, the communication together should be like shaped up properly when the team is scaling, right? It is very important. But, how would you define that you don’t end up overdoing something, right? So, while you’re scaling the teams, that’s not the only goal. The goal is also to deliver the products, the features, right? At that point, you also have to be cautious about that you don’t end up doing or overdoing things, right? So let’s say, how would you approach this part where you have to ensure there is automation at the right places, there is a communication channel set up in the right mode? So, can you just give us a few examples how you dealt with some of this situation, like just to get more relatability in the situation?

Sayak Saha: See, to be honest, there are different ways to do this. There are different approaches, right? And when you get in leaders, like when you scale teams, when you get in leaders, it’s always not so good that you, you force some specific processes on them, right, that maybe you follow Agile, Kanban or this metrics and all. But what I feel is that when you say this entire process, right at the end of the, what is it? Like, it’s like, there is an idea which comes. Someone needs to define that idea that what I want to expect from it, maybe some mock up, screens and all. Then you define some KPIs from it. Then there’s a tech spec, design, testing and finally get it released doing some A/B testing, right? So, in order to define that what are these phases for your company, and based on the size of the idea, maybe a short, medium, large, how much time this idea should, should spend in each of these phases. Let’s say, ideation phase can be two to three days for a small scale feature, but maybe two weeks for a big size feature, right? If overall I’m having, let’s say 20 ideas which are cooking.

Kovid Batra: Right.

Sayak Saha: Different phases. Each phase, it should not spend beyond this period. If it is spending more than beyond this period, then that means the process is overkilling there and this requires some optimization.

Kovid Batra: Makes sense. Perfect. I think that’s a very relevant example.

Sayak Saha: Because finally if you look at any CEO or any Co-founder, right, what they looked at, how fast I can make this feature live. I mean, I have an idea, how fast I can do it. So if the expectation is to make it live in, let’s say one month, it means that how much time each of the slices, windows should have.

Kovid Batra: Yeah, the process should support it basically, and that’s how you should plan for it. So I think from this, I’ll move on to like one important point that I have always been struggling with, right? This is more around collaborating effectively in these times. So, engineering teams collaborating with design and product teams to define smooth and effective product development. And there are always these fights, back and forth communication, the requirements have not been defined properly, this PRD is not up to the mark for us to like start working on it. On that note, I’m sure you would have also faced a lot of challenges. Just give us one good example from your journey where you actually ended up solving such problems and things were working smoothly. I know that would be very idealistic to say working smoothly, but still, yeah, what was your contribution in your team to solve for this process?

Sayak Saha: I think the first and foremost is that let us accept the fact that things will not be smooth, right? When you’re moving fast, It’s very hard to accept that I will get something really in a very neat manner and stuff. This won’t work, to be practical because each of the actors in this process, right, whether it’s designers, developers, none of them know the entire thing, right? The designers know how a good interaction can be, right? Maybe the QAs or the PMs they know the product the best, how users will use it. The developers know how to code and the challenges of the system.

Kovid Batra: Right.

Sayak Saha: It’s good to build but what are challenges in my system, right? So, in a way to build anything, you need skills from all of these places. So, I think fundamentally the first and foremost, I think is like the team need to have a nice bondage and they should start feeling that it’s a shared success, right? Because unless each one of them help each other, right, this thing will never be successful. Okay. So, that initial gelling and building a team bondage, I think is the first and foremost thing. There is no other recipe for, for, for it. Okay.

The next part what I think is like for each of these things, right, when the design is built, involve everyone in these phases, let’s say involve the devs, involve the PMs, involve the QAs. Run, run these mocks with them to understand because the mock phase is very important, ’cause when you run the mocks, you understand the bottlenecks of the system, right? And, and run it as a perfect user. Maybe at times it’s, it’s, it’s okay to run it with an actual end user and ask him for feedbacks that, “Hey, this is what we’re planning to build. What do you think?” Does it make useful for him, right? And, and even it’s useful that you run the mocks with the operations people, because finally you might have a product, but when the final reconciliation or stuffs are getting handled from operation standpoint, or maybe if some complaints are coming from customer support, right? How they see this data? Maybe there are like they should have sufficient logs and all these things so that they can debug those complaints. So, involving every stakeholder while designing a product, maybe the big products I’m saying or big features, it is very important because when you identify it early, it’s always important, right?

And second is developers, you will see they always have a mentality that “Hey, I’m not comfortable delivering something every two days or three days. Let me build everything in two weeks and I will dump you, or three weeks.” They, they try to, I mean, there is a general in, I mean, tendency of people that I will not make incremental commits, but I will make a single commit. I think this is culturally one of the things if a team can develop, it’s like having incremental commits and, and see that how it works with the big picture. That solves a lot of problems.

Kovid Batra: Yeah, I think probably 70-80% work is done when people start believing that it’s a, like wholesome success, right? It’s not one team’s success. So, the main thing is done there. It’s more about, like the teams which are working smoothly, I should say I have seen that thing, which you just mentioned, like there should be a cooperation there, there should be a feeling of success together. So, I think only then things work out. You will have that patience. You will understand other standpoints. So, things would work better that way. Makes sense. I think a pretty good advice there actually.

Sayak Saha: And also one last thing is actually, most of the times, right, if you see that teams, they got bit they’ve shared very like stiff deadlines and stuff, right, because there is a sense of fear. I think from leadership side, if, if they can be given a comfort that, “Hey, even if you fail with the commitment or if this feature fails or if the deadline slips, it’s okay if there is a valid reason.” So, I think when teams have this comfort, they just outperformed. So..

Kovid Batra: Yeah.

Sayak Saha: Comfort needs to be provided to the teams, the comfort and trust.

Kovid Batra: Totally, totally. Makes sense. Moving on to one important topic related to how we end up implementing technologies and now, because you have this ChatGPT coming in, all the AI wave going on, right? And there are a lot of changes happening. You have suddenly so many tools around you that already tech teams were having this tool fatigue, but now you see developers using things like GitHub Copilot and people are talking about it, let’s implement it. So, how do you use these technologies and how do you implement it when you already have such legacy code implemented? What is the overall process and as an Engineering Director or as an Engineering Leader, how do you make sure that it is utilized at the right point of time and in the right spaces?

Sayak Saha: Okay. So first of all, if you look at, uh, with the introduction of ChatGPT and Generative AI in the last 6-8 months, it has been a total disruption, right?

Kovid Batra: Yeah.

Sayak Saha: All these days, what we have been hearing of AI from some, from some very specialized teams, this is no more a specialized team. Now it is everyone started using, exploring and every, every morning when you open LinkedIn, you will see that someone posting that these are the top 20 AI tools to be used, right? So, there is a, like a huge blast of ideas and usage. And to be honest, no one, I think everyone is adapting. So, there is no defined strategy as of now that if you follow this strategy, this will give you success or this results you can achieve. So I think at this point, what is important is identify first of all, for your organization, what are the bottlenecks and where you think AI can optimize, okay? So, let’s say the example which you said, we all are thinking that it’s code assistant, it can be Copilot, or AWS CodeWhisperer or anything, anything else, right, that we all think that this will help developers code faster, easy and stuff. Okay, we don’t know the real benefits yet. So, I think what the best thing is to run a pilot project within the company. And end up any of these tools and see how useful it is. So let’s take an example. Let’s say for example, if you are using any of these tools ideally what these tools are doing, so they are providing you two types of course, one, they already have a learning based on the course in the internet and other repositories, and this like code on that, right? So, this is a one set of output which they give you. It can be as simple as, “Hey, give me a code, to drop a file in S3.” or “Give me a code to read a file from S3.” You get all these things. Or, or it can be any other cloud providers or, or any other use case.

The second is what, where it’s more tricky. There are organizations which are enterprise organizations. They might have a large code base of several years, legacy code. And many companies use their own customized libraries, right? So if I need to code, I need to code using those libraries. So, can this code assistant work with this? So, many of these code assistants are saying that their LLM models can learn the internal code base and suggest code snippets according to that, right? So, the best part is that it was a pilot project. See how this works. So one of the ideas which we are trying to do is that, I would not name the vendor that they have a metric which suggests how many snippets of code are accepted by the developer, right? It will suggest, but you need to accept it, right? Accept it. Overall I have X commits happening through these things, then it’s a productivity improvement, right? And the other part is that the second measurement is that the code which we are accepting or getting accepted, how much it is custom code, means which are very internal libraries or internal to the organizational code it’s suggesting versus very generic. Can we get a metric very detailed to that level, right? So this is another thing which we are trying to measure.

And, and also a few aspects to look into is like many of these tools, this might be very accurate, but there is a software licensing issue, right? So, because they can pick code from Apache license or some other licenses. So as an organization, do you support all this licensing stuff? What makes sense? So, you need to do that right mapping also.

Kovid Batra: Yeah, yeah, yeah. Absolutely!

Sayak Saha: So this is one of the things which we are trying to adopt and learn. But in general, there are a couple of low-hanging fruits, let’s say, from operation side. They’re doing some translation service or some, someone collecting feedbacks and summarizing the feedback trains. So, these are pretty classical use cases, which ChatGPT is doing wonderful, right? So in, in this case, it’s important that people learn how to write effective prompts. So this is another skill set now.

Kovid Batra: Exactly, exactly. Right.

Sayak Saha: So prompt engineering is another important part. So, so this is, I think this is, these are more like operations or used to stuff, but what’s important, I think was what’s very, uh, there are other use cases coming up, let’s say you have an incident management, right? So, often we have repeated issues having the same cause. Can AI solve it, right? I mean, can I have, can I make my LLM learning happen on my all Slack messages for last three years and make it learn that in future if a similar issue happens, these are the steps to be done, right? So, so we do not spend time or at times when you have an issue later when you do an RCA, based on the chat history and stuff, can the AI summarize it, so we don’t spend time in building a RCA? Okay.

So, AI is more like a tool now. So, how we use it matters. So I think one to, to summarize, I think what’s important is that we need to, to make the engineers learn what’s available in the market, these are the things available and make them decide that what’s more effective for them, instead of building a strategy that, “Hey, I want to onboard this 4-5 tools and this is what, what I want to achieve.” There are a lot of tools. Now it’s better that you, that the teams understand what’s best for them and then start getting a result out of it, because once you see the results, it matters. And then, definitely I think one of the things which is deviating people that there’s so many tools right now, jumping on a tool and tying up with some vendors or company probably is not the right thing. First internalize.

Kovid Batra: Yeah, we should understand the need first. Like, if there is a real problem that needs to be solved and.. Correct.

Sayak Saha: Yeah. So, understand your problem, maybe explore a few tools, build an internal team or a pilot team, see how it works for you, and then go for a commitment in terms of money, effort, and everything.

Kovid Batra: Makes sense. Totally. Perfect. I think with this like we are talking about GitHub Copilot and there are other, other tools out there in the market. There are a lot of times, not just with AI, but even before that, there is always a question of whether to build something. Let’s say you have a problem, you want to like solve it with productization, you want to have a product for that. How do you go about making that decision of building in-house or buying it from a vendor? How do you take that decision usually?

Sayak Saha: Okay. So, probably I will frame this question a bit more.

Kovid Batra: Yeah, yeah. Please go ahead.

Sayak Saha: It is like build vs buy vs run, okay? Because when you maybe buy a software intruder, you are also running the software for a longer term, right? So there is a cost in running the software, whether it’s built in-house or out. So let’s come to that point.

So first of all, like whenever you build a product or build a tool, right, I think what’s important is that every company has its core offering. Let’s say, if there’s an, it’s an insurance company or a fintech company, that’s their core, right? But, as a general IT company, nowadays we need to do a lot of generic functionalities. Let’s say, you need a, let’s say a message provider which is responsible for sending SMS or maybe WhatsApp messages, emails and stuff, right? So, do you need to build it in-house or do you want to tie up with some company and use their services for the same? There are many such things. It can be a payment gateway, it can be a, this kind of a messaging service, email service provider and whatnot. So, I think what’s important is that it’s a fundamental strategy that, that as a tech company, I will only solve my core problems or my core business cases and rest all I will outsource, or I will tie up with something, someone else, right? Because this helps in prioritizing your focuses. Okay. So, this is one of the strategies which can help, right?

The next point is that, okay, you strategize it. The second point is that how much cost it takes, right? At times there are solutions which can be built in-house and it’s much cheaper to build. So, it might be worthy to build it in-house. I can take a small example, like a tiny URL. So if you’re building emails and you need a tiny URL, there’s a cost. It’s a very minimal cost, but you want to build it in-house, right? I mean, the cost value proposition, like is it really worth it? Okay.

I think the third part is, which I was saying the run. When the organization is small, if you take a software, it often won’t pinch you much. Let’s say, you buy a software for some for 50, 20 developers, 10 euro per month, it’s great. But, when your organization scales to 500 developers..

Kovid Batra: Then it’s going to be..

Sayak Saha: It starts pinching you, right? So this is something strategy that if you really have such a growth strategy and you feel that this might be a pinch, it’s a decision, how you want to plan that, okay? And this has a cherry on the top in recent years, when because of business decisions, let’s say if you need to shrink your organization, this, this gives a different perspective because you, you make a commitment that, “Hey, I’ll take your license for 500 users for next three years.” But, let’s see if your organization shrinks to 300 users, then you’ll need to still pay the same money to the external vendor, right? So how, how you plan these things, so these are the aspects which I think one should consider.

Kovid Batra: Yeah. Makes sense, totally. And last thing that I just want to discuss with you, like when you are using these tools, bringing in automation, using AI, ultimately we are trying to impact the overall productivity of the team, right? The question that arises from here is that how you are defining that productivity and even I should like take a step back. I should ask how do you define the success of an engineering team? Because productivity, I’m sure it’s, is a very core part to it, but in general, how do you define the success of an engineering team? How do you measure productivity? How do you measure success is what I would love to hear from you.

Sayak Saha: It is a wonderful question. So if you look at right as an engineering leader, I mean, the best part is that you start talking with the other peers in your organization or in your company, and they might not be tech. So, everyone is trying to promote the good work of their part. It can be from finance, it can be from business and everyone. So, when you are in that kind of a forum, what matters is that finally how much revenue you are adding to the company through your team’s work or how you are building in optimizations and cost-saving initiatives to save cost, right? So I think these are the, for any two teams, these are the main two factors, which, which comes out, which drives benefits.

So now, the question is that how these two things can be related to engineering teams. So, what we do is that as an engineering team, we, we develop multiple features, right, features or products and stuff. So, so for any of this, right, when you deliver a feature, we start, we actually measure the ROI of these features that, hey, this feature, if it’s built, this is going to bring so much revenue for me, for my customers. This can bring in so much new customers or so much new business. This is, this is one way.

The other can be, let’s say it’s a, it’s an experience that if I build this experience, let’s say I limit my customer journey from 10 clicks to 7 clicks, it’s a better customer experience, right? If I can reduce my number of app crashes, it’s a better customer experience. It will improve my customer NPS. And maybe in turn, this will reduce my customer churn rate. So what I said that first is definitely increasing revenue. Second is customer churn. And third is the cost savings. Like when you build softwares and stuff, there’s an operational cost of running it, running the software, which is purely an OpEx cost. I mean, which involves OpEx cost spent by the developers. It is OpEx cost of the of the hosting the software. It can be in cloud and in-house. So, what are the optimizations can be done to, to save those costs around because, I mean, because as developer teams, they, they keep on adding features, right? And if we keep on in consuming the hardware resources, this cloud cost, your cloud cost be also linear and it would happen, right? Because every organization needs to limit the cloud cost, so that we limit our cloud cost to some budget.

Kovid Batra: Correct.

Sayak Saha: Right. So, what are the optimizations which can be done to limit those? I mean, there can be strategic decisions that, hey, we will build services with serverless vs microservices, based on the volume and other tech factors, right? So these are the aspects which needs to be taken into. So anything when we build, I generally try to categorize into these three buckets. Right.

And, also the third part is, I think is innovation because innovation can give you something which you cannot maybe measure upfront, maybe the code assistant one, which we discussed, right? We don’t know the direct outcome of it right away before investment, right? So we should keep some bandwidth for innovation because otherwise, you might lose the train. It depends from organization to organization, but I believe at least 10-20% efforts to be spent on innovation so that we don’t miss the bus.

Kovid Batra: Totally. When you say these goals are kind of, I would say broad goals to understand, and of course, everyone should have a realization towards it. First question that comes to my mind is that when developers are actually working towards building the product, and product is of course related to these business metrics of customer satisfaction, revenue, saving cost. Maybe saving cost is something that they can also see in the GCP bill or the Azure bill or AWS, right? But the other two factors are kind of indirect, right? Like when you write the code, you complete your sprint. You don’t really end up looking at the goal of customer satisfaction immediately because the feature is rolled out then you will get. So, the feedback loop is first of all, little time taking and then it is kind of indirect also. So, how do you, like motivate developers or like ICs for that matter to be feeling the same as a product guy would feel or a sales guy would feel in a business? What do you usually do to do that?

Sayak Saha: Okay. I think I got it. But I think, I think that what’s important is, right, that every individual in an organization, they have some counters and metrics to measure for their work, right? So, what we do is let’s say, in my previous company, let’s take an example. We were managing a payment gateway, right? So, in the platform, if everyone is doing payments every day, it’s all good. I mean, it’s like, you’re not making a lot of changes in the gateway every day. So, the motivation level of people comes down that, “Hey, it’s a software. It’s running as usual. What new shall we do here? Or what, what’s the scope, right?” What we started doing is that we started developing the funnel, the gateways, how many people are adding their items in the cart, then clicking in the car details and finally making a payment, and then the successful payment at the end of the day, right? It’s a funnel with the full steps, right? So, we started measuring that in this full funnel, what’s my, uh, expected daily users in each of the stages of the funnel, okay, and average it out over a month. So, and every day, if any of these counters are dropping, then there is something wrong. Let’s say, if I expect 200K people to visit my payment site, right? Okay. So, if all of a sudden I have a 10K, then there is something wrong. So we had counters, like I expect so many successful payments per day, right? And this will be my success percentage. So end of the day, this report comes in that hey, my conversion should be 80%, payments should happen successfully. So all of a sudden, if it’s 67%, that means there’s something wrong in the platform and the developers are responsible for it. Okay. And this in terms comes to the operational metrics, right? The system uptime, the API, success rate, the TPS of stuff and all those things. So, what I try to mean is that if you give a user experience metric and then let developers decide that what are those internal metrics in the tech architecture they should measure. It can be the APIs, it can be the Google events, it can be anything. But, let them take that call. Don’t tell them how to do, but tell them what to do.

Kovid Batra: Yeah. Cool. I think that makes a lot of sense. So I think this is great. Maybe one, one last thing that I just want to talk about is how are you looking at the in-general efficiency of your engineering team members. So, defining success with these goals and OKRs and initiative OKRs, right? So, that’s I think setting the fundamentals for anyone to be motivated and deliver towards what the business is actually needing. But, do you follow any practice? Like, I should change my question, actually. Do you follow any practices or do you do the efficiency measurement using metrics like DORA or something?

Sayak Saha: We don’t do any specific those kinds of metrics. But, what we try to do is that, generally like we were saying that, that in a quarter, we have an expectation that in a quarter, we will deliver so many features, right? So many large size, so many yes, blah, blah, blah. Right. So we try to expect that if a team is able to deliver that, okay, those main signs, so that’s more important.

And then the other part is that, as I said, that since we try to just get the developers, PMs all together, the focus is more towards the outcome.

Kovid Batra: Outcome. Makes sense.

Sayak Saha: Right. And I think that motivates the team more instead of forcing that, “Hey, I developed so much story points, velocity.” Because at the end of the day, if there is no outcome, nothing matters.

Kovid Batra: Right. No, totally makes sense. Cool. I think this is amazing, Sayak. It was a lovely chat. I think I learnt a lot and probably our audience, also learnt a lot from it. So, what we can do is we can have another session with you sometime, like where we can have a part 2 to this episode and talk about more such engineering topics. It was really, really nice talking to you.

Sayak Saha: Thank you so much, Kovid, for hosting me and these were tough questions and all these questions are very close to my heart and it was lovely sharing with you.

Kovid Batra: Your insights were really amazing. I must say. So, thank you. Thank you.

Sayak Saha: Have a nice evening. Yeah, bye.

Kovid Batra: You too. All right, see you.

The DORA Lab – #02 Marian Kamenistak | VP Engineering Coach, ex-VPE at Mews

In the second episode of ‘The DORA Lab’ – an exclusive podcast by Beyond the Code, host Kovid Batra engages in a thought-provoking discussion with Marian Kamenistak, VP Engineering Coach and former VP of Product Engineering at Mews.

The discussion begins with Marian elaborating on two key terms – DevOps and DORA metrics. He then explores the application of DORA metrics within teams and their significance. He provides examples of how DORA metrics can pinpoint team issues, such as utilizing change failure rate to gauge team satisfaction.

Lastly, Marian offers valuable insights into strategies for engineering managers to tackle inefficiencies beyond DORA metrics and navigate execution steps when tackling challenges like high cycle time or low roadmap contribution.

Time stamps

  • (0:06): Marian’s background
  • (0:58): Diving deep into DevOps and DORA metrics
  • (2:31): How do DORA metrics fit specific teams and what value do they bring?
  • (6:46): Examples of how DORA metrics pinpoint team issues
  • (12:51): Are engineering teams facing challenges implementing these metrics?
  • (21:29): What is the typical adoption time for teams to implement these metrics effectively?
  • (26:32): How can Engineering Managers pinpoint and improve areas of inefficiency beyond DORA metrics?
  • (35:05): How can metrics guide execution steps when addressing issues

Links and mentions

Episode transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an interesting guest whom we loved so much that we had to call him back. Our engineering metrics expert from Prague. He has 15+ years of engineering leadership experience. He has been former Vice President at Mews and currently a Vice President Engineering Coach.

Welcome back to the show, Marian. Great to have you here.

Marian Kamenistak: Greetings all! And thank you Kovid for having me once again, looking forward to it. It will be a ride today.

Kovid Batra: Absolutely. So Marian, like today, the discussion topic is all around engineering metrics as last time, and our audience loved it so much that we wanted to deep dive into certain topics. And touch the fundamentals of DevOps, DORA, and discuss more on such topics with you with certain examples that you have implemented or seen as working well for different teams.

So, before we jump into the metrics and how to implement those, the first fundamental questions that I would like to have a clarity is what is DevOps? And, what is DORA?

Marian Kamenistak: Okay. So, let’s start with the DevOps first, I guess. So, the way how I perceive DevOps really is some sort of a system, how to build software faster, like the operational side of things, really. So, to be very specific in that, it encompasses the for example, you know, the configuration cycle, the release cycle all together monitoring and the tooling that we can combine all together. So, in other words, it saves time and, make our developers much more efficient as opposed to taking care of the, you know, low level stuff, let’s put it this way. So, in other words, DevOps saves usually the time to engineers and, increases dramatically their efficiency and basically their time to value.

On the other hand, when it comes to the DORA metrics itself, it’s basically, some sort of representation in numbers, how we can measure the team’s efficiency, making sure that we, unlock the potential of our teams. And, keeping our teams on, let’s say, you know, on a high-performing level, right? And, there is a bunch of indicators. You might be talking about, top 5, top 10. I would be honest, it might be like up to a hundred different indicators. Nevertheless, in DORA’s case, it’s just four basic indicators that we talk about. And we could cover that in much more in depth, you know, at our session.

Kovid Batra: Perfect. Perfect. So, to begin with, I think when we are talking about DORA metrics, can you give some example where exactly you feel that DORA metrics really fit for a particular team? What is the importance that this DORA metrics bring to the table? And like, what results can we get if we work on them?

Marian Kamenistak: Okay. So, I would say these days, DORA metrics is some sort of a standard or established standard due to the fact that there has been a huge research coming from Google. What are the, basically the most impactful metrics that we might want to follow, right? From my own perspective, out of the four DORA metrics themselves, to me, the most important attribute of that or indicator of efficiency is, for example, deployment frequency, where basically we are saying how much time it takes us to basically turn our efforts into a value, to be very practical to basically to move our new feature set into production, for example, right? And the reason why I think this metric is, I would say the most influential is, you know what, let’s put it in a very simple example. If our team goes dark for three months, and all of a sudden they release something, you know how it goes. We’ve all heard the story, right? So, they want to shake their hands cause it’s a huge success. But on the other hand, the Product Manager is saying, “That’s not really what I wanted.” The stakeholders are sort of, you know, reluctant to that. The clients might be saying like, you know, that’s not what we meant to receive underway, how we work with. And there’s a bunch of bugs for another two sprints out of it, right? I think we’ve all experienced this story.

So, in the end of the day, what we want to see is that our deployment frequency’s sort of frequent in a way that we release our increments in an established cadence, I would say, right? Here, I want to, basically pay attention to one of the things, which is usually we have to take into consideration the difference between, let’s say a large corporate company and a small startup, where, for example, speaking of the threshold, it’s totally fine that I can imagine that in the startup environment or scale of the environment, we can have the deployment frequency about, let’s say that we release twice a day right? That’s totally fine. While in the, for example, regulatory banking business, if we release something on a monthly basis, that’s a hell of a good achievement, right? So, including the whole testing, the regressions and you know, regulatory constraints and so on and so forth. So, we always have to take the context into consideration. So, don’t mix, you know, the startup metrics with, with the corporate ones, right? So, that’s so much about the deployment frequency, in my opinion.

Kovid Batra: Right. Actually the, in not just the team size, I think it’s about how you function in, what domain you are and what exactly you’re working on. These metrics could vary for you and the benchmarks could vary for you. So, I think that’s a very good point that you touched on. And I mean, we also generally look this from a very deep lens that, okay, what exactly is needed for this team, how they’re functioning right now, what should be the benchmark for this particular team if they’re working on the front end back end. So, of course that matters a lot. So, deciding on a particular metric and then setting up benchmarks is not just straightforward. Like, you just go and say, okay, we want five deployments for a week and then we are sorted. That’s not something we..

Marian Kamenistak: Yeah. And if I may add another two cents to the story, Kovid, what I really found out is that actually what worked the best is that we set specific thresholds for specific teams cause you might have different teams that work on the platform or enabling teams or basically the new vertical teams and so on and so forth. Some of the things might have a high amount of dependencies and so on, or there is a high amount of, for example, unplanned work due to the maintenance and, other things.

So, it’s really great to basically set up the different expectations or thresholds for the different teams. And the way how I do it, I ask the teams to come up with their own proposals.

Kovid Batra: Oh, great!

Marian Kamenistak: And it works because you don’t break the principle of ownership. So just take it aside as a small tip and we’ll come back to our story for sure.

Kovid Batra: Sure. Sure. Absolutely. Marian, can you give me some other examples around how we can use these metrics to understand the problems of the team? Like I, just to give a head start there maybe. I’m looking for something that if we can understand how the code review process is going on in the team, or how does the velocity of a team looks like, or how does the collaboration looks like for a team. Can we identify such kind of inefficiencies and problems in the team using these metrics? And if you know, like, can you give an example?

Marian Kamenistak: Yeah, totally. Let’s be honest, we can measure like dozens to hundreds of different things, but that’s not very wise, right? We have to start from somewhere. So, usually the way how I approach it, especially when a company invites me to do some sort of internal efficiency audits, there are two types of inputs. First, the first input is really like talking with people with the right people and, you know, open their heart and get all the insights as much as possible. And of course, the second element of that is data itself. So, looking into the data, seeing the improvement opportunities there and digesting the data the way that you can identify pretty well what might be the, the, the top root causes of why the machinery is sort of slower than expected, right?

And here to be very specific, the one metric that I love looking at usually is the change failure rate, which is part of still the DORA metrics, where basically, the change failure rate can be translated as in my opinion, team satisfaction. If we don’t have a team that is satisfied, then we can hardly achieve some sort of a, you know, highly performing team or environment. And the reason why I think there is a correlation between the two is that if me as a boss, I’m coming to my team every second time after they release something and I’m telling them that, you know, they didn’t do the best job. And, you know, the production basically is full chaos. There was a failure and, there was an outage. Then of course, it doesn’t contribute to their satisfaction after they expect some kind of words from my side after releasing some sort of expected functionality, right? So, having the change failure rate pretty low, meaning, so let’s say, 5 to maximum 15 percent that says that, you know, there’s a certain, although yet minimal probability that things go wrong after doing something, that’s quite important to see.

There is a story that I’m usually saying that my developers, they live out of motivation and satisfaction, right? So, the motivation is basically why we are here, what mission we contribute and the satisfaction; what do we get back after we accomplish our work. So again, the change failure rate is something that is, I, in my opinion, highly underrated. And, some people don’t see the correlation between the satisfaction and the change failure rate itself, right? So, I think that this might be yet another practical example how to think of the metrics and translate that to the real world, because without the true culture and, you know, the satisfaction, you cannot achieve some sort of a high efficiency levels of your teams.

Kovid Batra: Yeah, absolutely. I mean, this is a very good example actually. When you look at change failure rate, the first thing that would come to your mind is like, this metric can tell us how satisfied our customers would be. But looking at it from the other perspective where you’re looking at team satisfaction, it makes a lot of sense actually.

Marian Kamenistak: It’s bidirectional.

Kovid Batra: I had this, one of our podcast guests, with whom, I was discussing these metrics. So, he mentioned about using two metrics. One is comments per PR and then comments after PRs are raised for review to understand whether the teams are collaborating well and whether the initial code quality is good or not. And it was amazing. When I looked at the thought process, how he approached that, I was like, pretty amazing. That opened a few more doors of understanding how these engineering metrics work.

Marian Kamenistak: Right. And thank you for introducing this example, because usually, you know, the people are getting crazy about the DORA metrics. In my opinion, it brings certain value, but, we need to read from the context. There are some, I would say, preconditions and better opportunities to check before we start, you know, moving to DORA.

What I mean to say, and again, another practical example, is that I might have all the DORA metrics sort of in a positive threshold and that might signal us that, you know, the team is hopefully highly performing. Nevertheless, if the team or my teams don’t work on things that matter the most, meaning the roadmap, then we go belly up, right? So, what, I rather prefer looking at is, you know, the let’s say the portfolio investment, how much of our, you know, efforts or talents, efforts goes into the roadmap, into the product roadmap or technical roadmap or business as your meaning of roadmap or another, I’ll say improvement initiatives, new features and so on and so forth.

And usually, my advice is that if we speak about, we talk about the, let’s say product engineering teams, the teams that are basically implementing the new functionality. There, I want to see that these teams, usually they contribute to the roadmap at minimum 60 percent of their time, right? So, that makes me sure that actually, I’m basically investing their talent wisely.

Kovid Batra: Right.

Marian Kamenistak: If I have on the other hand, all the metrics that, you know, the velocity and, you know, all the, as you’ve been saying, all the pull requests and comments, seems great. But if they don’t work on things that matter the most, again, we are not gonna shake our hands together. And, that’s a waste of time. And, uh, the funny thing is it’s not the fault of the team. It’s the fault of me as their manager, of the manager of the team, not of the first line manager, that I haven’t taken care of that. So, don’t.. Let’s don’t use excuses about like, you know, this team is, you know, it’s my team, it’s not that highly performing and so on and so forth. It’s bullshit. Sorry to put it this way. We are responsible for making sure that our teams work on the right things that we are able to accomplish our roadmaps and our strategy. Period. Yeah.

Kovid Batra: No, absolutely. I think this makes a lot of sense. What I have felt so far talking to a lot of people about the metrics is that people do know about DORA metrics. They understand what engineering metrics are and measuring seems to be very obvious to, like everyone. It’s just the engineering department, where we are having these kinds of debates, on social media, how to measure developer productivity or how to look at these engineering metrics.

Marian Kamenistak: Yeah.

Kovid Batra: If we talk about other departments or business units of a business, like there are strong measurement tools in place who are using to measure the efficiency of, let’s say for a salesperson, maybe we have tools like salesforce, right? It is one of the renowned examples. You can understand a lot about individual person on what he or she’s doing, how they’re performing.

Same goes for us, but here the challenge. So the main point that I’m trying to bring up here is that the challenge is that probably the engineering community is finding it difficult to make sense out of these metrics to solve their problems. And hence, I mean, this could be just my perception after talking to a lot of people. But, this is what I have felt. I’m not sure what’s your opinion on that. I would love to know it. The biggest challenge is of course how to use them and if you don’t understand how to use them, automatically there is an inhibition to not implement such things. And then, the bias goes towards, why to have these metrics? We should just look at the happiness of the team and that’s all about it. If they’re motivated, we are good about it. So, I mean, this is my observation. What’s your take on that?

Marian Kamenistak: Yeah. Yeah. That’s a very good topic. Thank you, Kovid, for opening that. Sometimes I, although, I see a huge impact as well, which is like, you know, we implemented certain metrics, engineering efficiency metrics, in the company. We turn these metrics into basically, OKRs or indicators that are tied with the bonus, for example, which is crazy because people start to get gamified, if you know what I mean, and it all goes belly up. So, that’s really like the, the, I would say the most severe anti-pattern I’ve experienced, right?

And, to comment on your situation, actually, or your scenario, actually you are disclosing a very good point that I see happening.

Kovid Batra: Yeah. Basically, It’s an implementation challenge. Like, there is a challenge with the implementation. I mean, you must have faced different kinds of situations where there would have been an implementation challenge. So, I mean, I just wanted to have your opinion on that. Yeah.

Marian Kamenistak: So, right. The most, I would say, challenging situation while implementing these metrics is that usually companies start from the middle. The way how I see it, and that’s one of the, you know, the most frequent anti-patterns is that let’s implement a certain solution out of the box that implements DORA, SPACE, or whatever that is. Of course, we have to adjust our existing Jira and to do some cleanup. That’s a secret story and it takes some time, right? To comply with the standards. Then, all the numbers come up, right? And you have a great dashboard with great colors and everything.

But the challenge is exactly as you described, Kovid is to make a decision. What are out of this 20 different indicators, the top three or top four that we really want to focus? And how to set the, the thresholds properly, so we know what it means if it turns, you know, what’s the severity of that metric if it turns from green to orange or from orange to, to red, basically, right? So, without having this exercise and the decision making about like, you know, what are the main indicators that we really want to follow instead of like, you know, you have the full dashboard. It’s your responsibility now as a, as a new team leads to have all these numbers green, right? So, and these guys, they are basically lost in that, right? So, that’s one of the things.

I want to add another, example, which is, you know, basically what I’m saying to the companies and to the clients is that implementing metrics or certain efficiency indicators, it’s one third of the story. Another two thirds is how to adopt these metrics into the company, right? It’s not about like, you know, we just did a Jira. We signed a contract. Here’s the dashboard. From now on, you are good to go and blessed to, uh, be a high-performing team because of the numbers, right? It doesn’t work that way.

So, making sure that people understand why we want to implement these metrics, what’s the motivation, and explaining and massaging them all the time about like, what’s the purpose of that. Because usually, you know, let’s be honest, what’s the most frequent phrase we hear from, for example, the developers or team leads. Usually they are telling us, you know, get screwed with your metrics. You want to basically micromanage us, right?

Kovid Batra: Exactly. Yeah.

Marian Kamenistak: And, turning that, let’s say that change, because we talk about the change management in the end of the day. It’s not about changing the process, but also changing the people’s mindset and their perception on this matter, on this subject.

So usually, what I advise the teams and the companies is to change the narrative from, you know, we want to micromanage you and making sure that you are highly performing to stick to basically two principles. The first principle is transparency, meaning it’s even better if it’s part of our values or openness or something similar to that. Cause in the end of the day, I want to see and have a way to, where to look, to see real time data, which team is highly performing or which is not that highly performing, right? And it’s fully transparent. This is what it is, guys, and let’s digest it and let’s improve, right? The other thing is the other principle that I want to follow is prevention, basically.

And here, the metrics themselves, I’m gonna use some curse words, sorry for that, but it saved my, it saved my ass quite a lot of times. So that’s the fact, right? When I saw that, for example, some of the, some of the indicator goes totally down or belly up, or something is happening with the culture or relationship with the manager, when it comes to some sort of, you know, happiness indicators or that the number of frequency go, you know, it’s getting worse or, you know, the change failure rate is like, you know, moving up to, let’s say 40 percent in the last two months, then that’s an indicator that something is fishy there. And if I have, if I, if I wouldn’t have these numbers, I wouldn’t be aware of that situation. I wouldn’t be able to react. I wouldn’t be able to ask the team lead, my team lead, “Hey, Mike, please, in the next 1-on-1 with all the guys, please don’t ask them the same question. What’s going on? How we can improve it or what’s, what’s happening there? If I don’t have the numbers, I cannot basically, uh, react. And eventually I might end up with a totally deteriorated team and that I will have to rebuild and it will take me another half year. So, what I’m trying to say is having well-established metrics is something that really pays off in the end of the day when you compare it with, let’s say the waste of the time that some sort of inefficiency can create and having the situation when the team is sort of rotting and underperforming. So, that’s usually what I see.

And, uh, the third thing that I want to open here. Kovid, sorry for speaking too much.

Kovid Batra: No, no, please go ahead. I think it’s very interesting.

Marian Kamenistak: Sometimes, while implementing the indicators, sometimes I see that people look at these indicators as sort of KPIs, as opposed to indicators only. So, what I mean to say, you really need to be careful about how we translate the numbers. To be very specific, for example, if I see that one single individual contributor has a low amount of pull requests, right? And we are two weeks before, let’s say the performance reviews, review process. So, what do I do? Do I come up with a number and say, “Hey, Patrick, you, you, you are screwed.”? Or do I take the context into consideration by knowing that Patrick is a senior developer, and his strength is to enable other people. Therefore, what he’s doing for me is that he’s pairing with other guys, right? So he’s sort of, I would say, invisible in the process. But his value is amazing and it’s great, it’s huge, right? So, always take these numbers into consideration, that’s my, it’s indicators. So, be careful about how you, how you basically treat these numbers and how you communicate the numbers.

So, my message would be make sure that you stay on the positive line all the time. Everybody is able to shout. I would be really careful about it. Yeah.

Kovid Batra: Totally. I think, and one more important thing, like you, you mentioned about what kind of prerequisite in a culture you should have, and then how you should go about looking at these metrics where you tell everyone what is the motivation behind doing it. You answer the ‘whys’ for the people and bring in that innate motivation for everyone to look at those metrics as indicators of how work should proceed or how efficiency should look like. And I mean, I totally agree to that. From your experience, can you tell us is there an average time for a team to adopt these metrics? Like, how much duration should people wait for having these phases of implementation? Because I personally have seen with Typo that we are implementing with teams. And sometimes what happens is like, a few teams do it within one to two months of implementation, like they bring in the dashboard and they just have certain goals set up for the team, they identify the issues and they start up with it. And sometimes it takes more than three months also for teams to get gelled up with it. What’s your take on that part? Like, how much time does it take for, usually for the teams to?

Marian Kamenistak: That’s a great topic. And thank you for opening that. My experience tells me that usually it’s roughly three months to onboard, all the teams, let’s say 6 to 10+ teams, towards the metrics to explain them, like what’s the reason behind how to use them, how to translate them and so on and so forth.

Plus, let’s be honest. Implementing this functionality or indicators into the efficiency process of your company, as we are saying, it’s not just the change of the process, it’s also the mindset change, right? The best thing is really to, for example, you know, involve, for example, the team leads into this transformation early on, right? So, they are part of these conversations. Explaining them the motivation once again, making sure that they are in the center of our decision-making process. For example, I may be coming from my internal audit with, let’s say, out of the 15 with the seven or top eight different indicators that I think that are the most influential ones, right? And, but, it’s them who are saying in the end how they see it from their own perspective, right? And what are the, let’s say the final top four that we will start with, right? When it comes to the implementation, of course, the implementation, that’s the hard work. And as I was saying, the dirty secret is that you have to do a clean up of your ticketing system because, because, you know, if your data is screwed, your numbers will be screwed as well. No surprise here. And, in the end, of course, it’s about, you know, doing some sort of, I would say town halls and workshops with all the teams, including the product managers, the developers and others, so they understand the numbers and everybody’s on the same page, right? Including that.

And again, the trick that I’m using quite a lot is that actually, I’m not saying what are the thresholds. Of course, I’m sort of, I would say lobbying for what the thresholds might be, but I’m asking the teams to come up with their own thresholds, right? As a proposal. Of course, we challenge each other. And this way I make sure that basically they own it from zero, from day zero, right? Or day one.

Kovid Batra: Yeah, absolutely.

Marian Kamenistak: And that’s a trick that, that I use, quite often. And that being said, if I see, for example, to be very practical, if I see one of the teams that’s not like, you know, taking up fast enough, basically the agreement is, okay, take it easy. No worries here. Usually there is another, let’s say, situation that is not technical. Maybe it’s cultural or maybe it’s a personal situation. That’s my experience. That makes numbers go down, right? And, we invest a certain time to improve, you know, the root cause and, or to basically work on the root cause. And after the number starts to, you know, go to a reasonable level, then we say, “Okay, this team from now on is enabled and is using the metrics, you know, in full functionality, basically.”

So, what I mean to say, the anti-pattern in other words is say, okay, so these are the generic metrics. Let’s do it without, you know, having the context about what the team is about and, or, and the other anti-pattern is basically to say like, you know, this is the start, and from now on, everybody has to be compatible with the thresholds, which, you know, sometimes, there are, let’s say interpersonal reasons or some sort of cultural reasons why things might not be working as expected.

Kovid Batra: Yeah.

Marian Kamenistak: And here I want to basically double down this message, because usually, you know, the CTO is saying, “Okay, let’s implement the metrics. And from now on, you know, I will have high-performing teams, right? But, if you have a rotting situation or the Product Manager is not in synergy with the Engineering Manager or whoever, and, there’s some toxicity, let’s be honest, in the team, no metrics will help you. So, using the excuse of, you know, “Here’s the numbers.” And, you know, “Work your ass off.” Never helps.

Kovid Batra: Yeah, absolutely. I think I can’t agree more on that. I think once you have this implementation in place, I’m just moving on to the next piece where I, I see teams implementing it, spending those one or two months or three months of time to get that into the picture where everyone is aligned.

Now, how does this process of, identifying different areas of inefficiency starts? And, just for example, like if I have a problem with the initial code quality in the team, or let’s say if I have a problem of deliverability in the team, where, maybe we are taking too long to deliver epics. And, uh, if there are like too many bugs coming in and there is high resolution time for the bugs, right? So which is directly impacting the delivery of the product with the customer. So, there could be a lot of areas where we can just start off. Like today, I’m an engineering manager. I might get overwhelmed with areas where I can work on and I will not be sure that, okay, which metrics should I choose?

So, can you give some examples which not only include DORA, but maybe we can just look at things beyond DORA and find out areas where an Engineering Manager or an Engineering Leader can get help on understanding where things are going wrong and how exactly one could improve on those?

Marian Kamenistak: Okay, perfect. Yeah, that’s a great topic, Kovid.

So, surprise, surprise! In my opinion, the most crucial indicators are not part of DORA. First of all, I want to make sure that, one that the teams, do know what they are supposed to work on and they are able to get focused on that, right? DORA says nothing about it. And usually, that’s one of the most frequent root causes that I see in the companies. To be very specific, the situations that I see the most often is that when we start to measure the, I call it roadmap contribution, meaning how much time we spend, our talent spans on the roadmap, on the things that matter the most. If we start to measure it, and you can do it very simply, you just, you know, put the tasks or stories that are part of, of the roadmap. Usually they belong to certain increments as epics, right?

Kovid Batra: Yeah.

Marian Kamenistak: You can label these epics by, let’s say the, the quarter or something of, of that year, year 2024 Q1 or whatever, right? Okay. So, this way you can distinguish, you know, whether that increments belong to an epic or not. And, if I have a task that has a parent epic with that label that clearly signals me that it contributes there, right? And just measuring, for example, the cycle time as a of these tasks, that’s the basic unit meaning, you know, how much time it takes from start, how much time it’s the ticket is in progress. And, comparing the summary of, you know, the total amount of, of the cycle time in the last three months, for example, with the ratio of only the cycle time of the tasks that, that contributes to the roadmap. That’s already a hell of a good indicator. And, as I was saying, usually I want to see that it’s roughly about, let’s say if we, if we have a, let’s say high-maintenance team, of course, it might be like, you know, just 30 to 40%. I understand that because there’s quite a lot of bugs and support tasks getting in, right?

On the other hand, if we have a, let’s say a small startup team, there I want to see that the contribution, the roadmap contribution is close to 90%. The reason why is that they have no production bugs. They have no production support issues and so on and so forth, right? And if we, let’s be, let’s be real. If we are something about 55 to 60%, and we spend most of the time on things that matter the most with our teams, then that’s a good achievement. So what I need to say, the situation usually is that after we start measuring these things, we find out that our teams have a scattered focus and, you know, there’s quite a lot of unplanned work coming in. And, actually the roadmap contribution is let’s say 35 percent only, and everybody gets surprised about it, right? Nobody has measured that. So the, the top managers, they think that, that our teams work on the roadmap. Product Manager is still complaining that, you know, he doesn’t get enough attention. The support is complaining that, for example, you know, the amount of bugs is still increasing and so on and so forth.

So if you at least, create some sort of expectations and, basically the balance between that, that’s a hell of a good regime already. And say clearly that, for example, yeah, for this quarter, I want to see that this, this quarter we spent 55 percent on, on the, let’s say product roadmap. 25 percent on the technical roadmap and let’s say another, the rest which is 20 percent on the off road map, right? Usually again, if you start measuring it, you will, you might get surprised that the off road map piece is 60% or 65%. Tell me how the DORA metrics can help you if you have this issue. So that’s one of the things that I want to highlight.

The second indicator is focus. No surprise. How much able, uh, my teams are to keep focused, right? For example, what I’m measuring, what I, what I love observing is how many tickets in progress per person in a team we have. You would be surprised how high the correlation is between the, you know, the focus factor and the efficiency of the team. In terms of the focus, I want to see, for example, I’m telling it as a story. So I want to see that, each single person has maximum two tickets open in progress in parallel. I want to see that the whole team has maximum two increments or epics opened in parallel. You might be saying like, why two, why not three? There’s a third hidden epic, which is business as usual, the off road map. Take that into consideration. I want to see that, on the, let’s say department level, we work maximum on two large initiatives, right? On the company level, I want to see that we work maximum on 2 OKRs in parallel, not 5, not 10, right? That creates focus. If you don’t have these sort of work in progress limits, you cannot make sure that the focus is there, right? So, just making sure that this one works, all of a sudden you would see that the teams can start to breathe, right?

So, because the anti-pattern usually is that we have a team of five people and each and every person is working on a different increment, on a different epic. Tell me if this is a team or is this a bunch of individuals, right? There is no teamwork in my opinion, there is no knowledge sharing. You can’t help each other. You cannot, you know, start finishing. You just, or, you know, the system doesn’t work. It’s broken.

Kovid Batra: Yeah. Yeah, absolutely.

Marian Kamenistak: Again, DORA metrics in this case won’t help. Or pull request metrics, whatever metrics based on pull requests will not help us here, right? So, that’s one of the things. Another thing, or the third thing, I’m sorry, Kovid, once again for being too much talkative. This is the one that I love talking about. I will describe it as a story, right? Sometimes I get invited to companies and, I hear that, you know, my teams haven’t delivered on the roadmap for the third quarter. I don’t know what to do. Please have a look. Usually, you know, it’s not about the delivery. Usually the teams are performing pretty well. Of course, you can improve certain things and ceremonies and the flow and improve the overall efficiency of the teams by, let’s say, 10 to 30%, which is pretty nice. Okay. Sometimes what gets broken is, the discovery, meaning like, you know, the specification or, you know, the purpose on what are the things that we have to work on or we want to work on and what’s the most valuable thing that we have to work on? There is some sort of disconnect between the product and the team, the engineering team. So again, you need to rather work on the continuous delivery and these things. That’s what helps the most, because if you, you know, the story, “trash in, trash out”, right? So again, I’m telling the story, why the heck do you do, do you pay high-performing teams? And these teams are usually very expensive. If you throw trash on them, it’s, it’s not worth it. It’s not worth the investment, right?

And the one single thing that I wanted to highlight is synergies. To be very practical, I can increase the efficiency of a team by, I’d say dozens of percent, right? By measuring things that matter the most. Nevertheless, if we create a synergy between the Product Manager and our Engineering Manager and the whole team, then all of a sudden we are getting 300 percent boost. So there is what I mean to say. There is something more than numbers. Surprise!

Kovid Batra: Yeah, yeah, absolutely. There is.

Marian Kamenistak: So, these are the things that I usually, you know, observe. So it’s part of the numbers, the data, talking with people, the culture, the synergies that tells us the most, right? And only after we start to pick the most useful indicators, such as roadmap contribution or focus time or epic cycle time or team satisfaction and so on and so forth. So that’s, that’s my advice. Yeah.

Kovid Batra: Totally makes sense. And I think looking at epic cycle time or roadmap contribution gives a lot of clarity on how, what we are exactly doing and are we headed in the right direction or not. These are two very good indicators. And I think very good for anyone to start off also, like for anyone to start off looking at what are the metrics which we should focus on at this point in time. As a startup or as even a midsize team, this makes a lot of sense, actually.

Marian Kamenistak: Right.

Kovid Batra: One more thing, just,I just want to discuss on this part is, like when we are looking at these metrics, there is of course, not just things around deliverability. And once you understand that part, what are the next steps that you have to take? So, I get to know that, okay, my team has lower contribution towards roadmap or our epic cycle time is high. So, what kind of execution steps should we take there? And are there any metrics involved that could help us understand whether the execution towards those is going right or not?

So just to give you an example, like, epic cycle time is too high for my team. And I started to look at what, where is the problem. And I found out that one of the biggest bottlenecks was my deployment cycle. And every time a PR was ready to be merged to the production, everything was there. The builds took a lot of time. And every month, almost 15 deployments were being done. Whereas, the PRs were already pushed at, let’s say in six to eight hours or 10 hours of time. So basically, what happened was that every month we were wasting 50 percent of the time in getting those deployments done swiftly. And ultimately, this became a reason for epic cycle time to be too high for the team, right? And if you look at it on daily basis, you might feel as an Engineering Manager, there is a bottleneck. But when you look at it from a quarter’s perspective where you see your epic cycle time for a lot of epics was almost two to three times of what you were expecting, you would be amazed to see that. And you would want to take certain steps. So, I just wanted to understand like today, if I understand roadmap contribution is low, what steps should I take and how even the metrics can help in that situation?

Marian Kamenistak: Okay. So, we might picture a couple of scenarios here, right? You described pretty well the epic cycle time and what might be the root cause. And usually we, you know, no surprise, here we talk about our ability to do a drill down just to analyze where this number is coming from, and so on and so forth. Exactly as precisely as you described, if the epic cycle time is, is too large or too high, I want to see what are the specific, sub-sequences in the cycle time of implementing certain increment as an epic. It might be either the deployment time or the testing or, or the adoption and so on and so forth. And, uh, if we identify what’s the, you know, the root cause or what’s the largest chunk that basically consumes most of our effort, then we can again narrow down, what that root cause and, do some sort of, adjustments and basically, healing scenarios, just to make sure that things work, and it might be either some sort of automation steps or making sure that we improve the whole process. So overall, either manually or by the process, or as I was saying, the automation, or basically we say, like, you know, we can have a, let’s say, software constraints in certain scenarios when we, for example, release only some sort of Betas or MVP and so on and so forth, right? So, we don’t have to have or a complete checklist of definition of ready to production, right? In this case. So, there are certain scenarios how to, how to treat these things.

The other example that I find quite useful. For example, I want to close the loop and we started with, with the satisfaction of people. Here, of course, there’s a couple of tools and ways how to basically measure the team satisfaction. And again, this is one of the surprises that, that I’ve discovered, and I was really astonished by that to see how much such a metric can help me to make sure that my teams stay on a high performing level and the culture is existing there. Well, to be very practical, if I have a tool that tells me that, you know, the score from, let’s say 0 to 10 in terms of the relationship with the manager or relationship with the peers or the satisfaction or the wellness is roughly about, let’s say, 8 to 9, that’s totally fine. But if I see a drop from 8 to 2 with the relationship with the manager, then and it’s me being a manager, then I know that there is something that I should be eventually working on, right? So, and again, it’s a great act of prevention. And without this data, sometimes we don’t have the wake up call, right? So, that’s yet another example how we can help each other.

And again, if I see this number, then of course, what we can do is again, to narrow, to do the drawdown, to ask the people for the feedback, to ask for the data, and so on and so forth, because in the end of the day, the data is what matters the most, right? If, If we, let’s say, on the cover, our hypothesis by data, then, we’re probably strong into our assumption and we already know what might be the root cause and how to basically prevent the situation from rotting and destabilizing the whole team or the whole department. So these are usually the scenarios that I see repeated, quite often.

So, the message here is once again, as we said from the very beginning, don’t treat these indicators as KPIs or harder data. Make sure that you understand the context first, you do the drill down, you do your homework and only then start talking about it, because if you use it in an incorrect manner, it will bite you back.

Kovid Batra: Yeah, of course, it will. Cool, Marian. I think this was a great conversation. I think we can have many more such discussions and keep diving into different use cases, but in the interest of time and for this particular episode, let’s close it here and look forward to having another such episode where we are talking more in depth about the problems that the teams face with these metrics.

Great, Marian. Once again, thanks a lot for bringing in such practical advice around metrics. I’m sure people, audience is going to love it. And I love it too.

Marian Kamenistak: Thank you, Kovid, for having me here. Looking forward for our next session and, let’s make the world better. See you soon!

Kovid Batra: Absolutely. See you!

‘Bridging the Gap between Business and Engineering’ with Chris Bee, Startup Tech Advisor

 In the recent episode of Beyond the Code, host Kovid Batra engages in an insightful conversation with Chris Bee, startup tech advisor and ex-CTO at Lessen. He has previously contributed his expertise to renowned organizations like Zillow, Uber, and Amazon. The central theme of the discussion revolves around bridging the gap between business and engineering.

The episode kicks off with a fun fireside chat with Chris. As the conversation progresses, he addresses the unique challenges he’s faced as a CTO, focusing on three primary aspects of organizations: People, process, and product. Chris talks in great detail about translating business goals into technical strategy and emphasizes the importance of aligning the product development process with stakeholders. He also provides valuable perspectives on goal-setting at both the company and team level.

Chris concludes by offering parting advice to the audience, reminding them not to overlook the importance of having fun at work.

Time stamps

  • (0:06): Chris’ background
  • (0:39): Fireside chat
  • (8:52): Challenges faced by Chris as a CTO
  • (14:05): How to translate business goals into technical strategy?
  • (16:16): What key questions should technical leaders ask when crafting team strategies?
  • (20:10): How to empower and lead dev teams and Engineering Managers?
  • (23:11): How to create a product development process that aligns with all stakeholders?
  • (26:26): What’s preferred for Product Managers: collaboration or individual authority?
  • (28:15): What traits foster deep product involvement and accountability in engineering leaders and team members?
  • (31:23): How to define the success of an engineering team?
  • (37:12): Parting advice for the audience

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone, this is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have an amazing special guest who is a seasoned startup CTO/CPO. He has seen a startup journey from a 20 million valuation to a 2 billion dollar valuation with Lessen as a CTO. He has 17+ years of experience in leading software teams and building applications. Currently, he’s working as a technical advisor and consultant with multiple startups.

Welcome to the show, Chris. Great to have you here.

Chris Bee: Thanks for having me, Kovid. Great to be here.

Kovid Batra: Pleasure. All right, Chris. So, we’ll be starting off with a cool fireside chat with you, where I and the audience would love to know more about you through different questions.

Are you ready for the fireside chat?

Chris Bee: Yeah, absolutely! Let’s do it.

Kovid Batra: All right. So, here’s the first question for you. Tell us about the most important event of your life, like that defines you.

Chris Bee: Yeah. Yeah. There’s lots of things I could, I could probably reference. It’s kind of hard to narrow it down to one event necessarily.

But one significant event that I would, I would typically talk about is, moving out west and, you know, took a pretty big leap of faith and left behind a lot of my family and friends back east and really jumped out here without really knowing anyone or much about the area, frankly. But in retrospect, it was a great decision and, it was a huge boost for my career. And, got to work for some amazing companies out here that really didn’t have offices back east where I was from. And, you know, being away also let me focus a little bit. You know I originally worked for Microsoft and then Amazon, Uber and Zillow and, you know, being out here allowed me to have a little bit less distractions, a little more of kind of a blank slate and kind of carve out a new path in life. And, I, that path has been focused around tech and the outdoors and meeting new people, Met some great friends out here that I otherwise wouldn’t have met if I didn’t make the move and actually met my wife out here and started my family out here as well.

So, it’s been quite a kind of pivotal point in my life as I reflect back a little bit when I actually made the decision to come here, but definitely a good one. And, I miss a lot of my friends and family back east very dearly, but, all in it’s been great living on the West Coast.

Kovid Batra: What do you love most about the East that you don’t find here in the West? I mean, I, I’m sure you would have spent your childhood and growing up teenage over there, right?

Chris Bee: That’s right. Yeah. Yeah, I moved out here kind of in my late 20s. So, I had a pretty significant chunk of my life that was, that was on the East Coast. Well, I mean, the family and friends are the main thing and a lot of the people I knew back there. You know, there’s sometimes a bit of a directness about the East Coast that I appreciate. Yeah, there’s a little bit different, food, culture there and kind of cuisine options, although cities have homogenized a little bit over, over the years. But, you know, I think there’s, there’s different food options.

And, I don’t know, I think the main differences are really just around, you know, kind of the general attitude of folks. I think people are a little more laid back here, a little more reserved. They get a little more of that directness on the East Coast, which I appreciate. I think I carry that with me. It actually helps me at times. But, broadly speaking, you know, it’s, it’s the same country. It’s not a wild difference between the two coasts really these days.

Kovid Batra: Cool. Amazing. So, tell us about, uh, your first experience; how did you get into tech actually?

Chris Bee: Yeah. So, I was always inspired by what technology can do. I was an early adopter of the internet back in the 90s, kind of really date myself here. But I studied programming and management in school and more specifically, I got really into software in my grad school years. And, I was actually a DJ during that time, just kind of a source of income when I was, when I was in school and that led me to learning graphic design and then promoting a lot of my events and led me to building a production company that had a pretty comprehensive website of event listings, forced me into learning technology. So I learned, you know, PHP and HTML, CSS, a little bit of JavaScript, and, you know, web servers and analytics and, you know, kind of the, everything I needed to do to basically promote events and keep the website maintained. And I just really became fascinated with what technology can do at that point.

And that led me to go a lot deeper in my studies. I did a lot of like continuing education and you know, kind of nights and weekends programs and got my first job as a Product Manager back in Philly and at a technical company. And I just really kept progressing from there. Every company I joined, I would take on little side coding projects. I still kind of do projects for fun on the side today. And, it’s really a never-ending pursuit. There’s always something new to learn. And, you know, obviously with AI now there’s like a whole new era of things to understand and learn and dive into, which is exciting.

So yeah, it’s been, it’s been quite a journey. But, way back in the day, believe it or not, it was, it was being a DJ and promoting events that initially got me started in actually hands-on kind of coding and building applications.

Kovid Batra: I like that. That’s one hell of a transition. I mean, a DJ turning into a tech leader, if you look at it, I think that’s amazing. I’m sure that that would have definitely brought a lot of different aspect and perspective of how you look at things when you lead teams, when you do your work on day-to-day. I’m not sure how it impacts, but, that’s a different transition that I’ve heard very lately.

Chris Bee: Yeah. Yeah. Yeah. No, it was a lot of fun when I was in college. It was a great job, a lot of the other jobs that my friends were working at the time. And, you know, I did internships in the summer, more professional internships. But, yeah, it was a lot of fun and it led me down the very beginning of this path is kind of where it started when I really think about it. But quickly, the professional world took over and I, a lot of that type of work just really focused on that once I finished grad school and started working professionally.

Kovid Batra: What about now? Do you, do you still play sometimes?

Chris Bee: On occasion. Yeah. Yeah. I’ll dabble here and there just for fun. You know, just at the house, you know, no desire to go play gigs or anything like that anymore. It’s purely just a hobby at this point.

Kovid Batra: So, how do you usually unwind your day? Like how, and there, there is a lot of work, hectic day, then you come back home, what’s your go-to then?

Chris Bee: Yeah. Yeah, it’s varies by the day a little bit, and depending on family activities, you know, can, can change a little bit. But, I guess I tend to be a night owl a little bit more by default. You know, I’ve become more of a morning person with kids, but, I generally like to put some closure to the end of my day. And I actually kind of find it relaxing to work a lot of times when there really aren’t other folks online. And you know, as a busy professional, you can either carve out early mornings or late nights, essentially to focus. I feel like you kind of have to pick one when you’re sandwiched between meetings all day, and you know, usually just bouncing around from conversation to conversation. Um, so I usually find that that time of night and I really like to carve out my next day as much as possible. Kind of prep call notes, set up any meetings that are needed, catch up on the email I might’ve missed, and sometimes do some deeper work, or at least, at least frame it out for the next day is usually what I like to try and do. And what I find that does sometimes is it will sort of allow things to sit in my subconscious a little bit while I sleep and let my mind kind of solve some problems while I’m sleeping. A lot of times I’ll wake up, you know, with the insights or you know, kind of thoughtful approaches to what I was ruminating on.

But I try and stop working at least an hour before bed just to, you know, wind down and you know, usually read before I actually go to sleep is typically my pattern. But that’s based on my routine. You know, it varies a little bit like everybody and I try not to get, you know, super dogmatic about, you know, how I, how I handle it. I think, you know, not putting too much pressure on yourself is also important. But yeah, that’s, that’s the basics, I think.

Kovid Batra: Cool. Cool. Cool. I think it was, it was great knowing you and thanks a lot for being honest here and telling us from where you came, what you did, what you like.

Now, I think I would love to, and the audience would also love to know more about what you did in your career, maybe some successes, some failures, your experiences as a CTO. So, I think let’s get started with the main section where we talk to the new-age CTO.

Chris Bee: Ah, sounds good.

Kovid Batra: All right. So, my first question. So, as a CTO at Lessen, and probably you have been wearing this hat now multiple times, there have been multiple challenges that would have come across when you are into this responsibility and this role. Tell us about some of the major challenges that you have seen as a CTO, and how did you overcome those, and share some hands-on advice there.

Chris Bee: Yeah, absolutely. You know, I think big picture, if you zoom out, you know, the job of a CTO, or any technical leader really is to translate the business strategy into engineering strategy, right? And how you actually do that, I think depends a little bit on the company size and the stage of the company.

I think if you’re in the earliest stages, you know, you’re really going to be operating as a lead developer and a system architect and maybe managing a small team to execute. When you get to that next phase of a growth stage company, you’ll typically be more focused on hiring and guiding the team to follow best practices and, you know, taking on more of a leadership role. And then, as you get to the later stages, I think, you know, it shifts again where, you know, you’re really working with your peers to make sure you’re investing in the right areas, studying the culture, keeping teams aligned, and really working towards achieving business goals in the broader sense. I think you’re delegating a lot more as you know, you get to kind of manage your managers and, you know, department managers and this sort of thing.

But in any of those phases, I think it really breaks down to three primary aspects. The way I think about it is people, process and product. So, ‘people’ is really the most important part, right? The company’s kind of nothing without their people and it can be easy to forget this as a tech leader, especially as you’re deep in the technology. But aligning your team’s passion to the growth objectives with the company is super important. I mean, there’s really no more important job than that. And, you know, focusing on helping people find satisfaction in their work and in their career and really helping people grow in their career is really one of the most important jobs. And I think focusing on that is super important. You know, work is such a huge part of our life. I think you really have to love this part of the job as a manager, and if you don’t, or that’s not appealing to you, then, you know, maybe management work isn’t really the right profession, and that’s okay. And there’s lots of, you know, technical leaders that can lead in other ways that aren’t people managers, but the ‘people’ is really one of the biggest parts. And I talk about that a lot when I’m reflecting on what it means to be a technical leader.

I think the next thing is ‘process’ and kind of setting up the rhythm of the technical organization, you know, aligning the tech team with the broader company objectives, you know, creating a process to set expectations and hold folks accountable. And this can come in the form of goals and OKRs or managing to a delivery schedule that needs to be published by the team or kind of a variety of other ways. But, I do think having a system by which people understand kind of how they’re being evaluated and you know, what the expectations are is really important. And, you know, as a, as a leader, as a CTO, you know, you’re ultimately going to be responsible for kind of setting up, you know, what those expectations are and what the rhythm of the business should be and how you’re going to drive performance in your teams. And, what I found is that high performers, you know, want to be held accountable. They want to know, you know, what the rules of the game are, so to speak. I think there’s nothing worse than, you know, being surprised or not really understanding what your expectations were and having a miss. And, you know, then you’re in a whole, you know, kind of people management debacle that you don’t want to be in. So, I think it’s important to be clear about that and set up a process that works for people to grow within and know what the is expected of them.

And then lastly it’s ‘product’. You know, really leaning into prioritization and having a business lens with it is, is sometimes a new area for, for folks that have really come up from the technical side. But, you have to really be thinking broadly about the organization and the company to help make good prioritization decisions inside your team and what your team’s working on. It’s a lot about architecture and, you know, building the right foundational pieces so that, you know, the platform can grow and, you know, flourish. I think ensuring you have the right investments in infrastructure and DevOps to create a great developer experience so, you know, you’re able to move fast and people feel like they’re working in a system that is modern and doesn’t get in their way. And then, I think just weighing on priorities and making sure that tech debt, architecture projects are fairly represented. And, you know, having that kind of broader view of the product, I think it’s really important as a leader, when you’re thinking about the product part of all this.

And then, there’s some challenges I could probably talk through as well, if that’s interesting or up to you, where you want to take it from here.

Kovid Batra: No, I think the two points that you have touched upon, one is translating the business strategy into a technical strategy and then dealing with people, process and product. Like, these are like quite in itself, quite broad domains to talk about. I’ll try to take them one by one because I have some things to really understand there. And I have been hearing this from a lot of CTOs now, like translating the business strategy into tech strategies, one of the biggest challenges they see.

Just throw, throw some light on how you as a CTO, let’s say, at Lessen or other companies have done that. Can you just give us some example where we could, like the CTOs who are listening to you could relate to that, “Okay. Yeah, this is the scenario we are exactly into. And this is how we can translate some of the business goal and vision into the technical strategy that we are looking at right now.”?

Chris Bee: Yeah. Yeah. And I, I think it really it requires you to kind of take a little bit different view of maybe work than you have in the past if you were previously an Engineering Manager or Engineering Director, and you know, now you’re in this CTO role. And I think there’s, there’s two aspects. One is, you know, looking at it from a business lens that may be a little bit different. I think the other is just really understanding the impact of your leadership and your words and your communication to your organization. On the business side, I think the big change really is that you have to think about the company holistically. You know, it’s no longer just about the technology. And sometimes that can be at odds with how you may have thought about things in the past, because what is the best thing for the overall business may not align with really what you would like to do as a technology leader, or, you know, what you’d like to prioritize or the projects you think, you know, would be kind of fun to work on that no longer is the right lens to really look at things. So, I think keeping the business on block, helping fuel in growth, making sure you make the right investments. And you end up having to look at things from a little bit of an ROI perspective, which I think is a new lens for people, like truly, like how many dollars did we spend to deliver this part of functionality or this part of the platform? And you know, that, that generally isn’t the way in a lot of organizations anyway, how you look at things. It’s more headcount, I’ve got projects and I’m, you know, using Agile, I’m running through my sprints and I need to deliver things by certain dates. But, when you start looking at things from an ROI perspective, and you ultimately own the budget, you know, that’s where I think, you know, your view will start to change a little bit.

So, you know, it comes back to really understanding the business well, like you have to be much more of a business person, I think, than you were before.

Kovid Batra: Right. I think that that’s very true. And I don’t think a strategy, a technical strategy would just come out of two days of thinking and you are through with it; there are a lot of aspects that you need to look into to really say that, okay, we, we have to come up with this strategy and this would work. But, one most important part I feel is the understanding of the business.

So, what kind of questions a technical leader should ask themselves and their business counterparts when they’re thinking on those lines of building a strategy for the team? So, can you just highlight those few questions probably which you would be asking?

Chris Bee: Yeah. I think as you’re trying to kind of make that translation, you know, I’m a big believer in starting with goals, right? And having goals at the company level that are aligned across your peer groups. And that means with marketing, with sales, with your CEO, with, you know, other departments, operations, if you’ve got an operations-heavy style company. And those become kind of the backbone for how you empower your teams. The way I like to operate is to then allow my teams from the bottoms-up to create their goals that, you know, have a level review, but are owned and kind of independent by each team. And then, the projects within should, you know, not be surprises, but generally should be things that are coming from the bottoms-up. So, the teams are figuring out how to get to those goals and how to achieve what you’ve laid out as the objectives for the company. And that framework, I think is the best way to sort of break down the strategy. And then, there’s usually a review process that’s in there, right? If getting into the specifics a little bit, you know, if you’re going on a quarterly cadence and you’ve got quarterly OKRs you’re setting, having teams come up with their objectives, their OKRs at, at the team-level along with the projects they’d like to prioritize, having a review session with leadership, maybe making some tweaks, maybe making some prioritization changes, making sure that the dots are connected between the different teams, because, oftentimes the theme becomes sort of the glue that, that pulls together a lot of teams.

So, I think it’s goals and themes really, I should have mentioned that themes are the other really big part and, and that’s like at the level of leadership you probably want to stop, you know, you don’t want to get down into the weeds of individual projects and, you know, individual work that you want to see done. Sometimes that’s okay. It’s inevitable. You know, if you’re using the product, you know, you’re thinking about all the time, it’s inevitable.

Kovid Batra: Yeah. You gain some context, like you have to understand some of the initiatives that have been taken up. But yeah, I get your point, what you’re saying. Yeah.

Chris Bee: Yeah, you really want the teams to come up with it because I think that that empowers them and gets them excited and gets folks, you know, really eager to work on what they’ve they’ve concocted and what they’ve trimmed up. So, I think that’s important. Yeah.

You know, you kind of also have to understand your impact a little bit as a CTO. I think, you know, one of the biggest changes from kind of the managerial level to the executive level is you have to be a little more thoughtful about some of your decisions and some of your statements. You know, the more senior you get, the more weight your messages will carry. And, it’s important that you’re consistent, right? You need to be a carrier of the vision for the organization. You need to be aligned with your peers and your CEO and how you describe strategy and priorities. I think it’s, you know, a situation where you have to be a little careful about half-baked comments or things that, you know, you haven’t really thought through because people sometimes will take that as direction and as, you know, sort of guidance of what they should be working on. And then, that can cause problems in your organization, especially if you’re misaligned with, say something the CEO said or something the sales team’s talking about, and, you know, that can create confusion and a lot of churn inside the team.

So, you know, it’s, you want to be approachable, you want to be transparent, but you also want to be thoughtful about, you know, sort of giving guidance and direction. And I think sometimes, you know, you even need to specify to say, you know, “This is just a suggestion or a random observation. This isn’t a go-do.” I think actually clarifying that when you’re talking to people from a leadership level, I think is, is actually really important.

Kovid Batra: Totally. That makes sense. Cool. I think that’s, that’s on the, on the technical strategy being formulated. When it comes to like leading teams actually, you have to enable your dev teams, you have to enable your Engineering Managers, your, like senior managers to actually lead their, their teams better. So how, how do you exactly do that? What kind of leadership style do you take up or what process of framework do you have in mind to actually lead and enable teams?

Chris Bee: Yeah. Yeah, absolutely. You know, I’ve been talking about it a little bit already, but I, I really like to lead with the theme of accountability and autonomy.

I think in order to empower teams, there’s really 3 things you have to have. You’ve got to have a system for accountability, you’ve got to have team autonomy and you’ve got to be able to articulate and make sure everybody understands ‘why’, the ‘why’ behind what we’re doing. And I’ll just talk about that last one first, since I haven’t talked about it much. And I think as a leader, you know, that’s one of the most important jobs is to repeat the ‘why’ and really make sure that it lands with people. I think when people really understand the ‘why’, they can work through almost any ‘how’. And that’s, that’s part of your job as a leader so that people feel inspired, so they’re excited about what they’re working on. They understand how their work ties the bigger picture to business goals to hopefully the impact the company’s making out there in the world. And I think you have to deliver that with some passion and conviction. And you need to, need to legitimately feel that way about what you’re working on and what you’re doing. And, and I think when you are able to articulate that and put that out into your organization, you know, people are going to perform at their best and be the most excited. And it’s just a lot more of a fun work environment when everybody’s aligned, you feel like you’re working towards a little bit of the greater good and something that is beyond just the scope of the specific, you know, task or, you know, bug that somebody’s fixing. So I think that ‘why’ part is really important.

And I talked a little bit about, about the autonomy and kind of how to break that down and how to set clear goals at the top and have teams kind of build that from the bottom up. I think, you know, there’s a little bit of, like, just the right amount of pressure in there, that’s important. I think periodically, you know, usually on a quarterly basis, doing some level of sort of public review of our accomplishments from the previous quarter, and what the plan is for the upcoming quarter, I think does add a layer of, kind of a healthy pressure, right? To sort of discuss things in kind of a more public forum. I think demos are another really big piece as well, when you talk about accountability. I think allowing frontline engineers to show off their work, whether it’s weekly or bi-weekly basis to the broader organization. I think that can create, you know, a little bit of a healthy, you know, situation where people feel ownership and feel like they need to deliver something by a certain time.

Yeah, exactly. Exactly. So, yeah, those are some of the big things I think but autonomy and accountability are kind of the themes.

Kovid Batra: Perfect. And now, moving on to the product part. Like, when you are moving down, building the product, there has to be a development process for that. And that has to not only work for the customers, for the consumers, but also for every stakeholder that is there in the system, and that includes your dev teams also, that probably includes investors also. There are a lot of things when we talk about stakeholders there. So, how do you create that product development process that falls in line with each and every stakeholder in the system?

Chris Bee: Yeah. Yeah, I think there’s a couple of aspects to it. You know, and I’ve talked a little about this, but there’s, there’s a combination of tops-down and bottoms-up that I think really needs to be, you know, clearly defined as you’re figuring out how to set up a product development process.

As I mentioned, I think top-level company goals and themes are what leadership should really be responsible for, communicating that clearly,  making sure that’s aligned across functions. And from a bottoms-up perspective, I think team goals and timelines for delivery are really, like the responsibilities of the individual teams. And then, as you kick-off individual projects, you know, a system that I’ve developed with some others over the years that I’ve found to be really successful is what I call “the 4 Ds” and, it’s discovery, design, development, and distribution. And for kind of epic-level projects, you know, these aren’t task-level items, but, you know, bigger projects that, you know, usually measured in, you know, one to three months, having projects go through those phases, I think is really important.

And, that point between design and development, I think, is 1 of the ones that needs to be kind of clear and you want engineering involved in the front half of the process and you obviously want product involved in the back half when development’s actually happening. But, there is a little bit of a point there of need to have things clear enough and requirements specified well enough, and technical design figured out well enough before you go off and start coding and building something in the wrong direction. And that isn’t to say that, you know, you shouldn’t experiment or build things quick and kind of get things out and fail fast, like that mindset needs to be there as well. But, I think even in those scenarios, you want to have sort of an abbreviated version of that, where, you know, what you’re building has enough alignment, enough agreement, you know, and that can be done in the course of a day or two potentially. But, there is a clear kind of handoff there where it’s like, okay, this thing’s ready to actually be, be built and ready to be coded.

So that’s like in the weeds a little bit with like the product development process. I guess the other thing I’d mentioned are ‘principles’. I think having principles for decision-making is really important. You know, Amazon is very famous for this and it’s very baked into their culture. But, cultural values are important. I helped create the cultural values for Lessen. And, I think those are really great frameworks to have conversations with people on your team and, you know, as you’re, as you’re considering priorities. And then, I think the other set of principles that’s useful is a set of product principles that help you make decisions and help you make trade-offs because often you’ll be faced with something that has some ambiguity and there’s a lot of different ways you could decide to do something. But, if you’ve got a clear set of principles that help you make trade-offs between potentially opposing forces or different considerations, those can be used as a framework a lot of times to help accelerate decision-making and really push decision-making down.

Kovid Batra: So, you talked about making people in place who are taking the decisions; that’s what I understood from what you said right now.

Chris Bee: Mm-Hmm.

Kovid Batra: How do you prefer that happening? Like, should it be a collaborative effort or should it be an individual person assigned who is gonna be the decision maker taking all the calls there? Probably they’re the Product Managers. How does it work out well and what according to you, you have seen working out well for the teams?

Chris Bee: I actually think that’s a pretty important piece and what I found to be successful is really defining who the ultimate decision-maker is for a given area. I think breaking that down by area is important. You can’t go feature-by-feature or project-by-project, but if you look at a given section of the product, a given group of features, I think it is important, and often as a Product Manager that ultimately owns the decision there.

Another framework I’ve used or have described in the past is sort of this concept of a 49:51. And if you’ve got a, say, an engineering leader and a product leader who own a given area, for certain types of decisions, it’s going to be 51% engineering, 49% product; for other types of decision, vice versa. And, you know, broadly, it’s usually the more technical-oriented platform decisions live with engineering, but you want product involved and vice versa. The more product-oriented customer-faced decisions, ultimately somebody needs to be the decision maker. And that’s usually on the product side. But engineering leadership should be right there. 49 is, you know, not zero. It’s, you know, equal partner, but if it comes down to like, there’s a disagreement, you know, there’s gotta be a clear owner, I think. And that just helps teams stay unblocked and, and move fast and continue to iterate because without that, you can just end up a kind of, you know, analysis paralysis and decision fatigue and a lot of wasted time.

Kovid Batra: One more important thing; I have been thinking about this lately. So, this is an ideal thought process where we say when the engineers are getting down to thinking about product as a Product Manager, then that’s when the best products come out, right? But honestly, I mean, I have definitely talked to a lot of engineering leaders and I have been listening to this a lot. What do you think, what kind of trades are there in those leaders or in those team members who actually exhibit this kind of a feeling where they’re really connected with the product, they’re actually involved in the product development process from the point where requirements are getting defined and then they’re feeling accountable for whatever they are delivering? They’re not just stopping after delivering a feature, they’re looking at what product metrics are moving after they have delivered something. So, just, just let me know. Yeah.

Chris Bee: Yeah. I mean I think it really comes down to the culture that you build in your team and as an engineering leader or as a product leader for that matter.

Again, it goes back to empowerment, I think, you know, making sure that your teams have the, the safety, psychological safety, if you will, to be able to discuss, whatever it is that they think is important for the product, for prioritization that should be worked on. But, also understand the broader business context of what the goals are for the company, what the goals are for the team. And you know, I think there, there is a need for management in some of these cases to kind of be the filter and to be sort of the decision maker in some cases when things need to get escalated. But, you really want folks and engineers specifically to understand enough of the business context to where they can kind of almost make the decisions themselves if they, you know, are able to.

So, my experience has been if teams are moving kind of in their optimal cadence and moving well, the pace of iteration is really fast when teams, you know, are able to make decisions and kind of run on their own. And I think if you can build that kind of culture, and I saw it really at a couple of places that I worked, but specifically at Uber. When I was at Uber, there was really, you know, a lot of empowerment inside the teams and teams were moving super fast, and there’s a lot of freedom to run and build features and create new experiences. And sometimes they worked and sometimes they didn’t. And I think you have to build in that experimentation culture and that ability to test the ideas in kind of the lowest cost way to get it out to customers to get feedback and be able to, you know, make an informed decision with some data.

And then, you know, I think sometimes there is a little bit of subjectivity that comes into play, which isn’t necessarily bad. I think, you know, at some point in the process, you know, it does come down to a decision and there is a little bit of, you know, you could call it bias, but just, you know, kind of subjectivity in somebody’s experience or what they believe to be the most important, you know, direction to go in that comes in. And that’s, that’s okay. You know, not everything can be completely data-driven and completely metrics-driven. You want that as much as possible and you want the anecdotes to match the data is really the key.

Kovid Batra: Absolutely. It’s probably, it has to originate from the kind of culture the leaders, the management pulls in. But, I also feel that when we talk about accountability and giving them autonomy, defining their success as we do for a product team, if we do it similarly for the engineering team would really help. So, I mean, from that, I would like to like, understand from you, how you define the success of an engineering team and how you have seen the best of the teams thriving with what kind of goals and what kind of success metrics, I would say, in the industry.

Chris Bee: Yeah. And I think, you know, again, it goes back to goals, and are we focused on outcomes over output, right? And if we’re moving the core metrics for the organization, for the team, like those are going to be the ultimate measure of success.

And then I think there’s, you know, specific things for the engineering team, you know, the DORA metrics. I think the SPACE framework has, you know, added a more of a qualitative aspect to some of that, which I think is really important. And, you know, a lot of those things, deployment frequency, cycle time, time to restore, failure rate, like those all do matter, I think are worth measuring. I think there’s context that needs to be added to that as well. So, that it’s not just a pure A to B. And you know, if it’s up, it’s good. I think it needs to be considered with everything else that’s happening in the team. And you know, maybe some of the nuances of your deployment cycle or release cycle or what have you.

But at the end of the day, I think, you know, are you meeting your commitments to stakeholders and customers, right? Is what you should ultimately be evaluated on. And if you’ve got good goals in place, you should be able to align the work the team’s doing with the goals that the company has, and the team has, and you should be able to pretty clearly understand if things are moving in the right direction.

I think some other indicators that, you know, or maybe not talked about as much in a business context are the team health. I think, you know, is the team well-being high? Do teams feel safe? Do they feel like they can communicate with one another and speak their mind and have an opinion about, you know, what’s happening in the company or the organization? I think, you know, happy teams are productive teams, right? And you can measure this through things like retention and attrition and, you know, internal NPS. There are ways to kind of measure this a little more quantitatively, but there’s a little bit of just a qualitative kind of feeling as a leader, you should have an understanding of how your team’s performing and how they’re feeling in general. You know, I think that, you know, building a culture where people feel like they can do the best work in their career and they’re growing and they’re having fun along the way, I think is ultimately what’s most important. We spend so much of our time at work and, you know, we should enjoy it. And I think that’s an element too that’s sometimes overlooked in some organizations. So..

Kovid Batra: I’ll just ask one last question that is related to defining the goalsfor the engineering teams. Can you just give us a few examples of those good goals which really seem to have worked for engineering teams?

Chris Bee: Yeah. I mean, I like to organize goals in two, buckets, company-level and team-level. And I think if you start veering into having department-level goals or group-level goals, I think it can get really messy really quick and you can end up with a lot of fatigue around, you know, which metric to pay attention to and who’s responsible for what. So, even as organizations scale, I mean, even, you know, multi-hundred person organizations, I think, you know, you want company-level goals and team, like, you know, atomic, you know, two-pizza team, you know, 10-person team goals.

So, at the company level, you know, there are going to be the business drivers. They’re often going to be related to revenue and growth and retention and churn and, you know, onboarding of, you know, maybe one side of the marketplace or the other, depends on the business, obviously.

Kovid Batra: Right.

Chris Bee: So, those, those are in place. But then, at the team level, the more atomic level, it’s like, okay, I think breaking those down into two buckets is really how I think about it. One is project and one is business.

And, in an ideal world, you have mostly business goals and then the projects are sort of fitting underneath those to drive that metric. And you can get away with that in a lot of instances, but oftentimes, there is a big release, a big new set of functionality, some, you know, very clear customer-driven, you know, new set of features we need to add, and that becomes a project goal. And that’s okay. And having those set up in such a way that you’re trying to get something done in a given quarter or given time period, I think are important, but, you know, I think the business side, if you can break down one of the larger goals to something that your team can directly drive, I think is really important. So, you have to understand what drives, say, a revenue goal or a churn goal or a retention goal they may have at the company level; you have to kind of break that down to its granular parts. And if you’re working on the communications platform, you’re going to have a different goal than somebody who’s, you know, working on an infrastructure platform, than somebody who’s working on, you know, the front end client portal or what have you. Like, it depends a little bit on the team, I think, but being able to have that line of sight between what you’re doing at the team level and what’s happening at the company level, I think is super important because that ties everybody’s work directly up to what is important to the company.

Kovid Batra: Perfect. I think, yeah, I think that’s a good way to define goals for any team and particularly for engineering team also, which most of the time is enabling some product or business metric. So, breaking down into a project and then to associating that with the business goal that is going to get enabled with that is a perfect way to look at it.

Cool! I think Chris, this was a really interesting conversation and I think this is one of my longest podcasts that I’ve had. I would definitely love to have you back for another episode, talk on more topics with you. But for today, I’m really, really thankful, and so would our audience be. Anything that you would like to say as a parting advice to our audience?

Chris Bee: I don’t know, nothing top of mind that we haven’t chatted about, other than to just say to not forget to have some fun at work. I think, you know, we, I mentioned earlier, but we spent a lot of time with our colleagues and with our coworkers, and I think when spirits are high and people are in a good mood and everybody sort of feel like they’re working towards the same mission, it’s just a lot more fun and you get the best work from people and it’s much more enjoyable. And that’s sometimes overlooked, you know, in business context. So don’t forget to have fun.

Kovid Batra: Totally agree, man. Thank you so much. Thank you so much for this advice and for all the insights that you have shared today. Thank you, Chris.

Chris Bee: Absolutely. Thanks for having me, Kovid.

The DORA Lab #01 – Lena Reinhard | Tech Mentor, ex-VP CircleCI

We are excited to introduce our newest addition: ‘The DORA Lab’ an exclusive podcast by Beyond the Code, dedicated to all things DORA and beyond. Throughout this amazing series, we’ll uncover the hurdles, inspirations, and practical applications associated with engineering metrics, essential for fostering high-performing engineering teams.

In our debut episode, host Kovid Batra welcomes Lena Reinhard, tech mentor and advisor with a wealth of experience from renowned organizations such as Circle CI, Travis CI, and BuzzFeed.

The episode kicks off with a glimpse into Lena’s life outside of work. Transitioning to the main section, they delve deeper into what drives teams to prioritize and implement DORA metrics and focus on effectively communicating engineering metrics with non-engineering teams to ensure alignment with business goals. Lena also sheds light on the implementation challenges engineering leaders face with metrics.

Lastly, Lena shares parting advice for engineering communities, emphasizing the ‘why’ and the context behind metric usage to drive meaningful team progress.


  • (0:08): Lena’s background
  • (2:26): Lena’s hobbies
  • (4:51): Essence of DevOps
  • (8:57): Why are DORA metrics vital for teams?
  • (14:05): How can engineering metrics be effectively communicated and utilized by non-engineering teams?
  • (18:20): Can metrics beyond DORA engage both engineering and business teams?
  • (21:54): How to assess and prioritize team satisfaction for engineering success?
  • (27:13): What challenges do engineering leaders encounter when implementing metrics?
  • (38:15): Parting advice for the engineering community

Links and Mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with an exclusive episode of Beyond the Code by typo. With us today, we have a tech leader who has more than a decade of experience in the tech industry. She has been leading engineering teams at CircleCI, Travis CI. She herself has been a SaaS startup Co-founder. But, her passion for tech industry doesn’t end here. She’s currently serving as a tech leadership coach for many organizations with her expertise in building great teams across the globe.

Welcome to the show, Lena. Honored to have you here.

Lena Reinhard: Thank you so much, Kovid. It’s exciting to be here.

Kovid Batra: Great. You know what, Lena, in the last eight months of building Beyond the Code as a community, starting with these podcasts, I’ve gotten an opportunity to talk with many engineering leaders like you here. And honestly, when I talked to them about engineering metrics and different other topics, particularly what I discovered that engineering metrics was something that they were not comfortable talking about. So, we used to touch on topics like DORA and all, so they were not very comfortable around that.

However, like when I, when I read your LinkedIn post and your articles about engineering metrics, I was like completely moved by the depth you had and like the hands-on experience you had with implementing these engineering metrics. So, honestly, today’s podcast’s topic, which is impact of engineering metrics on engineering success, I couldn’t think of a better guest than you. So, thank you so much once again, to be here. And I’m sure people are going to love this and get to learn a lot of things that they need to implement these engineering metrics in their organizations.

Lena Reinhard: Thank you. And I mean, I honestly will say that, you know, similar to what you’ve described, the articles I end up writing are rooted in the questions I hear from people, and also, honestly, a lot of questions that I’ve grappled with when I got into tech in 2010 and, already had a previous career in finance and before that, and it’s not like I got into the space and had it all figured out from the get go. And so, I’m glad it, you know, it was practical and helpful and I hope we can get a lot of that today as well.

Kovid Batra: Sure, I’m sure about that. Cool. So, like, once we get started it will be all about the engineering metrics. But before I jump into that, uh. I, I would want the audience to know you a little bit more. So, if you’re comfortable sharing something about yourself as a person, what you do, what you love, I would be more than happy to hear that.

Lena Reinhard: So, I’m just by the room around me, I think for the people who are watching this, you can probably tell a bunch of things about me. I love books. You can see, like behind me the, in the shelf, I have a lot of leadership books, but the row at the bottom is actually cookbooks and baking books. I’m especially fond of making pastry and breads. I have, you can’t see, I have a plant or a couple of plants actually standing right in front of me behind the camera. I have too many plants, but it’s become a really fun hobby. I’ve always loved gardening and now that I live in the city that’s the limit of garden that I have, but I really enjoy it.

And I also do a lot of sort of creative things. I paint, I weave, I knit, and do a lot of other sort of textile works. And I think that’s about it. I also love just being outside and in nature. Fortunately, I live very close to park which is really helpful to escape city life a bit. Yeah, those are some of the things that I do. And a lot of that time I also just spend, you know, thinking about that the work that I do because I really enjoy it, and because I really am passionate about, you know, helping people navigate the complexity that comes with like engineering leadership roles. And so, running my own business now I also still try to take breaks, so hope that art and all of those things help me with that. But, it’s still something that’s on my mind a lot.

Kovid Batra: Absolutely impressive. I’m sorry, but I was just going through your LinkedIn profile and I saw that you transitioned from a finance role, then you were a community member, and then, like community builder. So, there is a lot of transition and I’m sure the versatility of the choices that you have here, I can understand.

Lena Reinhard: Yeah, well, I always say I’m just a very, you know, curious person by nature, and I’ve said yes to a lot of things in my life, often without having it all figured out. So that’s, you know, that makes for an interesting CV, but also for a lot of fun. But at the same time, I always also maintain a list of hobbies that I want to take on if I, once I have the time, so I’m also never have enough time for all the things that I’m curious about. It’s a bit of a struggle, but it’s a good one to have.

Kovid Batra: No, that’s cool. I think, uh, this is amazing and great to know you, Lena.

Lena Reinhard: Thank you.

Kovid Batra: All right. Let’s get started. I think before we jump into the engineering metrics directly, my first question it all starts with dev operations, right? DevOps that we say. So, before we jump into how we measure DevOps, let’s talk about what is DevOps in brief. What do you think what is DevOps in brief. And then, what engineering metrics, DORA metrics look like, a bit on that. Yeah.

Lena Reinhard: The “in brief” part is interesting. So, I will say the way I like to, so I’ve been doing a lot of work with, for example, corporations that are trying to integrate DevOps culture or, you know, become more Agile, not just in an Agile with a capital A sense, but more in just in terms of their ability to handle change. And to me, that’s ultimately what it’s about. I mean, the DevOps movement and Agile in particular, I see as huge pillars of this, especially in tech, they originated out of the idea of coming out of the separation between software development and IT infrastructure towards basically integrating those things. That’s where the kind of development and operations DevOps part is coming from. But to me, what’s most important there is ultimately, it’s about businesses’ ability to not just handle change in the sense of being reactive, responsive to changes that are going on in the business world, or just changes that are needed in the software development process at a much more granular level, but the idea that businesses need to ultimately be able to innovate, to drive change, to create change, and not just, again at a strategic level, but just in every team in the organization, in everyone who’s working with them. And that’s where having practices where teams can ultimately… I’ll talk a lot about teams, by the way, because I found that, especially in software engineering, teams are ultimately the core unit where work gets done. I don’t believe in putting too much emphasis in the sense of stress responsibilities on the individual just because software development is in a lot of parts, a highly collaborative process. It’s where the best results are coming from. That also still means you need highly skilled individuals, but not the idea of sort of hero culture and all that.

So, I’ll talk a lot about teams probably today. And so the ability for a team to have ideas, put those ideas into motion, get that work prioritized and ultimately get things shipped. Like, a lot of that is inherently tied to DevOps culture and the idea that exchange ideas, innovation aren’t just generated by, you know, your executive team, but anyone can ultimately bring in the subject matter expertise they have and then make things happen.

Sounds quite basic, especially if you work in a company that does a lot of those practices, it may be, you know, your day-to-day already. And that’s great. But, for a lot of companies, that’s still a process that they’re going through. And even for teams that are working more at the forefront of DevOps agility, those things, there’s still often impediments. You know, like you’re depending on other teams as a classic, or you have security concerns that you need to work through. And so that, but ultimately, yes. So, in my favorite description of it, ultimately DevOps is about making change easier and making change as frictionless as possible for anyone involved in the company.

Kovid Batra: Absolutely. I think the underlying fundamental, probably even if a lot of teams and organizations know that this needs to be done, implementing it is also a very big challenge. So, I’m sure, I mean, I have been part of a few companies in my career and I know how it looks like when the manager is talking about all those values and principles that we need to, like stick to. But, when it comes to work, we are doing a thing, like the innovation is missing, the context of the customer is missing, and then how to collaborate well, make things frictionless amongst the team is something that we really, really need to deep dive and understand and actually believe while doing the work. So, it totally makes sense.

Lena Reinhard: That’s the fun part, right?

Kovid Batra: Yeah. Yeah. Yeah. Right. Absolutely. All right. I think this is a very important and a very good start to our discussion. But, how much important do you think that when these processes are in place, teams are following it, or let’s say trying to follow it how important do you think these DORA metrics play an important role there, what should be the motivation for any team to have these metrics in place, first of all?

Lena Reinhard: So, I think DORA metrics to me are, I, first of all, I think they’re really helpful, but I also think they’re a bit of a problem and I’ll explain why.

So, my approach is always that ultimately teams need to have visibility into basically the work that they’re doing. Like, you need to know how are your services performing? How are you doing as a team? How are your practices working? Like, that’s really important. Like, one of the cornerstones of DevOps culture is the ability to, like learn from mistakes. That’s, it’s really important. And so, in order to be able to learn, you need to know how you’re doing. And I love how you just described earlier the idea between basically the breakdown between the abstract ideals in DevOps culture, for example, versus the day-to-day reality, because a lot of the things that you and I may end up saying today will probably sound very basic and very simple, and we all know that, like, It’s not, like making most things actually happen can be really hard.

And that’s kind of the joy of it, but also sometimes the frustration and so yeah. And so basically, that’s why I also like to start often with like, what are we even trying to do there? DORA metrics are one tool to help you have that visibility to know how your team is doing and to get better over time. I emphasize that quite a lot because we have a bit of a tendency in tech. I mean, I do it too, that we end up making the tool the goal, right? It, it doesn’t become any more about, um, for example, you know, “Hey, we want visibility. Therefore, DORA metrics can be a great tool to help with that.” They’re also not the only tool.

But in especially I found in the discourse about metrics over the last 10 years, it’s very easy to make the tool, the thing where, you know, the conversation then is, “Oh, we need DORA metrics. We really need DORA metrics.” And we tend to forget a little bit why and that’s, so that’s one bit that I find really important. Like DORA metrics aren’t just the solution in and of themselves. They are a tool to help you get the visibility your team needs and to understand how you can get better and whatnot. And that part I find really important. And that also means DORA metrics may not be the right tool for your team.

Kovid Batra: Yeah.

Lena Reinhard: One thing that I have seen a lot is that in the discourse about engineering productivity and developer productivity, we’ve often forgotten that there are other departments around engineering. And now, DORA metrics specifically, I think they can be really helpful for developers and engineers to understand, you know, what are the impediments in the software development process? Where are we inefficient? Where are we not effective or as effective as we could be? Efficiency more towards the deployment frequency, getting changes out quickly. Effectiveness is the more about like, are we achieving our goals? Are we actually hitting, for example, the quality, um, which is baked into DORA that we need?

That’s important. The problem is that a lot of people outside of engineering don’t understand DORA metrics. Aand honestly, they kind of shouldn’t have to because ultimately DORA metrics or, you know, take the SPACE framework or a lot of DevEx discussions that have been going on lately. There are a lot of different ways to look at developer productivity out there.

What I’m trying to say there is essentially that there is an important discussion and I like to call that metrics for teams, like metrics that are to help a team understand how are we doing? They have the subject matter expertise to understand, you know, the impact of deployment frequency, for example. And at the same time, you also need to have conversations with people outside of engineering and convey to them how your productivity is. And if you’re able to translate DORA metrics really well, say for your finance person or for the people who are making the budgets for your engineering department, DORA metrics can still be helpful. But, if you’re working with people who aren’t super-technical, you may have to translate DORA metrics for them in order to represent engineering productivity because those, those are two different, two different problems to solve. One problem is helping a team get better. The other problem is essentially conveying to others how productive your team is. And again, like DORA metrics can be really helpful with that. But keep in mind basically what you’re actually trying to do and what goal you’re trying to pursue there.

Kovid Batra: Makes sense. Lena, can you give some examples? You just touched upon this point, like, if someone has the expertise, subject matter expertise to understand what is deployment frequency, only then it would make sense for somebody to understand its essence and probably abide by things that metric is telling and improve in that direction.

So, can you give such examples maybe for the cycle time, the lead time for change or change failure rate, which are basically the DORA metrics here. Can you give us some examples there?

Lena Reinhard: Sorry, I don’t think I quite…What kind of examples are you looking for? Because you mentioned a couple of really good metrics already around DORA.

Kovid Batra: Yeah, so I’m looking for an example where people would want to implement, let’s say, deployment frequency as a metric to understand teams are doing good or not. And then, translating that into a communication basically for a team, which is outside of engineering, maybe. So, just an example of a metric where teams are understanding how it is being done, why it is being done.

Lena Reinhard: Yeah. Yeah. Thank you. Um so I’ll actually, I’ll stick with deployment frequency. Like one, not just hypothesis, like there’s research behind the DORA metrics, that’s an incredibly good research, is that ultimately, if you have smaller changes, you’re going to increase the ability of the team to handle change. And so, one motivation to look at deployment frequency and implement that as part of DORA can just be, you want with your team to get better at, like making faster changes, you want to, you know, for example, go from just shipping one big merge request, pull request per month to smaller changes to make them more digestible to help your teams, maybe, you know, collaborate a bit more. There can often also be an element of knowledge sharing. So, this can be some motivations for you looking at deployment frequency. And ideally, of course, you have deployment frequency over it, increase over time. And looking at the trying to visualize the graphs in my head.

And, now that you have that as a team, you can learn from the observations you’re making there. You can make process improvements internally. It’s really helpful to just, you know, look at that metric once a week during your planning meeting or during your retros, talk about what are we doing? How is the metric moving? What are we going to do about that? And I found that this bit is always really critical to make, make space for the team to not just look at a metric, but also figure out what action they want to take because otherwise it’s, at some point, it just gets demotivating and frustrating. Like, if you’re seeing a metric that’s trending in the wrong direction every week and no one has the time to do anything about that, well that’s just gonna suck.

So, to the 2nd part of your question in terms of how do you then communicate this? I mean, honestly, if you’re an engineering manager, and you’re reporting up to a CTO, your CTO will likely understand these metrics, why they’re important. So, they may also be able to have some of those conversations with outside stakeholders. But, in terms of conveying the impact of this, honestly, your outside stakeholders probably care about are we achieving our goals in engineering? What are we doing to get better at achieving our goals? And, are we not wasting money in the process? Those are usually the typical questions that business stakeholders care about cause I mean, ultimately, if you’re an engineering leader, that’s also kind of your job to care about. And so, that’s the conversation you can have. You can say, hey, you know, “We are achieving our goals ideally, and we are measuring how efficient we’re being in this process by looking at something called deployment frequency. Deployment frequency means XYZ. It ultimately is a signal to us that we’re able to handle change faster. And, you can also see as a result, our ability to hit our goals has become better or our ability to identify risks.” Those things. It’s not a super big translation effort necessarily. Just basically don’t rely on just saying DORA, um, but build a little bit of context around it.

Kovid Batra: Right. I think it’s more about to whom we are talking to. And accordingly, we’ll have to translate those metrics into that context. And one more thing that I feel is that outside of engineering, anyone whom you talk to, whether it is product or let’s say even sometimes you’re talking to the sales teams also. So, you have to give them a clarity on what exactly is going on in terms of achieving goals. So, do you think, is there a way around where we can have metrics beyond DORA that even the engineering team relates to and,works on it? So, for example, something like deliverability of the team, can it be mapped to some metrics which business and engineering teams both understand? Like, something like maybe customer satisfaction?

Lena Reinhard: Yeah. I mean, I think, I mean, I’ve run a lot of product engineering departments, over the years and ideally, of course, you have no goals that are ultimately about customer satisfaction or specific, you know, access to new features, capabilities in your product, and you’re able to map your engineering work to that. That’s great. If you’re able to say, “Hey, we’re going to contribute to company revenue goals.” Also great. And sometimes you just have to leave a bit of a longer thread there. So, for example, to say, you know, you mentioned to get deliverability, like in the sense of like cycle time or lead time. Ultimately, a big part, honestly, of using metrics effectively is figuring out what is the picture you want to paint and what is the narrative you want to convey. So, for example, say one of your company’s goals is highly relevant to a lot of people at the moment is, like become more efficient. Well, what does efficiency mean for your team? Where are things inefficient right now? Like, for example, you know, you had the deployment frequency example earlier. We’re currently, like your assessment of your team also ideally have a conversation with your team. So, I can look at, like sit together with them, say, “Okay, we have a corporate goal to become more efficient. Where are things not as efficient as they could be in our case? For example, we’re only able to really deploy once a month. There are reasons for that. I’m sure you’re doing that because there are some impediments. What are those impediments? What would clearing those impediments do for the business?” And similarly, if the company get on that efficiency goal, maybe there are things in your process that are really difficult. For example, a case, a lot of teams are dealing with knowledge silos. You have only, you know, one or two people who have core knowledge on the team. Distributing that knowledge is going to over time make things a bit more efficient.

And so, look at the big company goals that you’re getting and then understand what do those actually mean for our team. And honestly, that’s already a really impactful connection to have, because of course, you know, not, not everyone in, say your finance department is going to understand, like deployment frequency, but people understand knowledge cycles. And people also understand if you’re, if you’re basically saying, “Hey, we have this specific thing in engineering, for example, where if our lead, if our cycle time is shorter, or even if our lead time is shorter, we’re able to respond to customer feedback faster.” Just, you know, spin the narrative a little bit further and people are going to get that. So basically, draw the connections for people between, like the high-level things that your company cares about and what they mean for your team.

Kovid Batra: Totally makes sense. I think this is one important aspect of how you communicate these metrics and translate them into something that looks like success, not only for the outside engineering team, but also for the engineering teams.

But, talking about engineering success, I think there is not just one aspect that we can say, okay, this is something that how engineering teams would succeed, looking at the metric of, let’s say, having customer satisfaction or customer retention or relating that to epic cycle time kind of things where you are delivering fast to or responding fast to the feedback they’re getting. I think there are other important aspects to an engineering success. Team satisfaction holds very, very big importance there, I believe. What’s your thought on that? And, how would you as an engineering leader measure it or not measure it? And, how you’re going to do it basically?

Lena Reinhard: I sigh a little bit because I think it’s, this one is such a really important and at the moment, especially such a difficult conversation to have. I want to just briefly zoom out in terms of where we came from in the discourse of developer satisfaction, team satisfaction. Just one cornerstone from my personal beliefs and beliefs as an engineering leader, like team satisfaction is important. There’s very good research that shows that developers having a good connection to mission and vision, the good feedback culture on the team, like the, all the high-performing teams research, that’s been done by Edmondson and others. That is, it’s incredibly important. I also believe in just, like we’re working with humans. And treating each other as well as possible is an important part of that. At the same time, again, team satisfaction is a tool. We’re not just caring about team satisfaction because we want people to do well. And I see that more in this, in the business context now. But there is a point because it helps us get things done because it helps us build great teams. It helps us build a sustainable company, all of those things. And so, like with any other metrics, I found that it really helps the conversations you’re having with other leaders in your company, even within engineering, when we’re talking about why are we measuring those things and why are they really important?

And, you know, all morals and personal values and leadership values and all of that I have a side, which I ultimately to me are the reason we are doing this work. But it also means, just to say it very bluntly, if you go to your finance person and just say, “Hey, we care about team satisfaction.” They’re probably going to say, “Well, team satisfaction, like, your team satisfaction is very, very expensive compared to the team satisfaction in, for example, you know, our sales teams where people often get paid just largely commission-based, based on the impact that they’re having for the company or compared to the customer success teams that you may have.”

And over the last couple of years, we’ve as an industry, when money was still cheap before the layoff rounds that we’re going through now, a lot of team satisfaction is also about ultimately retaining talent, you know, engineering talent was hard to find and was hard to retain. A lot of companies are putting way less emphasis on that right now. I personally think team satisfaction is still really important. All that research on high-performing teams and what not still holds, but at the moment for a lot of companies, the bottom line really matters. How much money you’re spending really, really matters.

And so, that means as an engineering leader, should you care about team satisfaction, how your developers are doing? I personally think a hundred percent you should. And you should look at how are you ultimately, you know, helping people grow in their careers, are you helping them, actually have the impact that they can have on the business? And the latter is the conversation you need to have. So, a lot of components of team satisfaction are ultimately about, you know, alignment, for example, or about having business impact. But a lot of the metrics around team satisfaction are you know, more about feedback culture, for example. So again, look at team satisfaction, look at developer engagement, developer happiness and productivity and connect those things to business metrics, connect them to translate them into examples that the people outside of engineering will understand and will care about. So, you know, look at the team satisfaction components, depending on what you’re measuring there. For example, that is that engineers are aligned with the mission of your company or that there are no knowledge silos or that there’s high business impact of the work that your teams are doing. So, you know, these components of team satisfaction are really important. Connect them to things that are meaningful to your business, because especially at the moment, it’s just going to help you have more productive conversations. Because right now, that’s what a lot of businesses care about. And that still means, again, developer satisfaction is really important. Just figure out how you can talk about it in a way that’s going to resonate with the people around you.

Kovid Batra: I think the biggest problem here is that a lot of engineering leaders might be knowing about this, might be reading about this on day-to-day basis. But, the challenge is when it comes to implementation, they are stuck, right? And, I think we are circling back to the point 1 where we were talking about that, knowing things and then believing and implementing things at work is something that is very, very difficult.

So, in your vast experience so far with different engineering teams, I’m sure you would have seen a lot of such challenges that engineering leaders or teams in general at every level encounter while implementing these metrics. Can you just share your experience? Maybe one or two examples where you could highlight how people ended up implementing these metrics and what challenges they faced during that course, how much time did it take? So that we can set some real expectations for the audience who is listening and really wanting to implement these things.

Lena Reinhard: Yeah, I love that question. So, my first recommendation would be and I’m going to try and formulate recommendations based on things that I know people often struggle with do this with your team.

So, what ends up happening often is that there’s a business demand for, you know, better visibility, more metrics, and whatnot. And a lot of engineers are scared because they’ve made bad experiences and understandably so. And so, that’s where my whole angle of metrics for teams is coming in. So, sit down with your team, say, you know, “I would love for us to better understand how we’re doing to improve together in this and make it a group effort.” Like, I’m pretty sure your developers will have ideas for things that are not going well because it’s going to bug them in their daily work. And so, the more you involve them in this already, the better. So, that’s a really good cornerstone.

The second part, that’s more the metrics and it’s about teams that you may need for business reporting and whatnot, be transparent about those. Say, you know, “Hey, my boss is asking me to talk to them on a weekly basis about the impediments in our delivery or our goal progress.” You can share those reports with your teammates as well while you’re, you know, pushing more information to your boss and giving them the visibility that they need.

Similarly, if you’re getting questions from stakeholders from the business side or from customer success, help your teammates by just sharing those things to the degree that you can, because honestly, many of us have struggled over the last years because I mean, I come from the business background initially, but a lot of engineers never got business training and, you know, became engineering managers and weren’t given the, even just the vocabulary for having conversations about efficiency and effectiveness and whatnot.

And so, like, you may still have to learn some of that. And that’s okay. I have a couple of guides on my site as well. If you want to get more into that. But at the same time, you can use that as a great opportunity to help your engineers understand a bit more of a business background, things to think about, and a lot of, you know, basically framing and vocabulary, the translation function that we talked about. so that’s basically the second piece, you know, keep your engineers in the loop on this, be transparent with reporting and metrics and with the cases you’re making.

I think another part that I found is really helpful is collaborate really closely with your product partners. Like, if you have, you know, if your team has a product manager, if they don’t, if you run a platform team, for example, you may have more of that function yourself, where you need to write business cases for the investments that you’re making. But, like having run a product engineering organizations, I just see a lot of that honestly, the collaboration between product and engineering can be really tough. And that’s oftentimes really, really making things very difficult for everyone involved, and I know that there’s often, you know, like, incentives that aren’t, that aren’t aligned well and whatnot. If you can partner well with your product team and Product Manager, that’s going to go a really long way. Figure out how you can set goals that are aligned because the whole, you know, engineering wants to do this, but product wants to do something else. I understand where it’s coming from and it’s causing so much frustration and so much friction on so many teams and ultimately, impeding your ability to create business impact and so on. If you’re having troubles in those relationships, work with your boss, work with your product partner to figure out, you know, ultimately, you’re all there to do good work for the business. How can you collectively work together to make that happen?

And then lastly, on the, the metrics topic, what I would also say is if you’re just getting started, and you’re not measuring a lot, or there are a couple metrics in place and you’re not sure what to do with them, I always recommend, you know, go to basics, figure out where are we struggling as a team, work with your teammates, work with your boss as well. You know, they may have things that they want from your team, or you have a corporate strategy, you know, I mentioned earlier there are strategic goals potentially in place around becoming more efficient or becoming more agile as an organization. Look at how can we do those things as a team. And then, if you don’t have metrics in place yet, how can we measure those things? We all love a good dashboard. Resist the temptation to measure, you know, 20 things, from the get go, um, because worst case, it’s just going to be overwhelming, and again, like you’re not going to have the capacity to actually address all of those things. So, like instead, you know, start small to use two to three metrics that really capture areas that are meaningful to your team, that are meaningful to your business. And then, iterate from there. Like, you may not need all metrics that you start with at every point in time. At some point, something else is going to become more important. You can focus on that. The really important part really is that you look at those metrics regularly, you talk to your team, you talk to your boss and you figure out how you can make room. And that’s also to the collaboration with product, you make room for actually addressing the issues that you’re observing in these metrics that you’re looking at.

And that honestly, I know a lot of it may sound really basic. I also know that honestly, most of those things are things that any team struggles with, at least at some point in time. And at the same time, it also means you’re in good company and, you know, it can be figured out. Like, go back to those basics and don’t get too lost in, you know, like, oh, you really need to measure DORA or SPACE or DevEx or something else. Figure out what your company and your team needs and what’s meaningful to them. And if you need a starting point, DORA is a good starting point. I also don’t want to just trash on those metrics.

Kovid Batra: No, I think that makes a lot of sense. And I, I mean, I totally understand that this is very basic or something being mentioned every now, here and then, but one very important point that you have mentioned that I feel is that the metrics are not something that are same for everyone. Every team has their own needs and having a collaboration with all the stakeholders is I think the must, because what I have also felt in my journey of learning about these metrics and getting them implemented is the resistance. One is of course the innate resistance of not understanding and where to implement it, but then the resistance from the teams, the cross-functional teams.

So, it’s a very, very good point, actually, Lena, that you just mentioned that talking to your bosses, talking to the cross-functional teams, talking to the developers and making them understand what exactly is needed and why it is needed will bring that alignment in place. And of course, I mean, it would take some time. And what we are doing right now here is talking about it and setting some real expectations because if somebody who is new to this and they think that, “Okay, I would do it in one month.” But, the realistic thing is that it would take three months, right? It would take some time for everyone to come in the alignment and then get it implemented.

So, while we are talking about this, someone who is hearing it would understand that, okay, it will take three months of time. These are the things that I should do. The other thing I should not do and then implement these basics to get the results there. And, I’m sure I have seen those case studies. I’ve seen those scenarios where the teams have really improved their efficiency, productivity, satisfaction, and became successful over a period of time using these metrics.

I do agree that this is basic, but this basic is something that needs a little bit of depth and context for the teams who are trying to implement it.

Lena Reinhard: Yeah, exactly. And I always say, I mean, we’ve all read the books and the blog posts and whatnot, and there are so many good guides out there. And at the same time, I mean, honestly, the work that I do is in translating those abstract, like simple in the abstract things to like, I always say, you know, “What do you do on Monday morning at 9am when you open your laptop?” And you’re like, “Oh, I don’t even know where to start.” Like, that translation or that application is the tricky part. And that’s why even though it sounds so rudimentary, but understanding why you’re doing this, I loved the way you just captured this as well. Like, why are we doing this? What is the point of this? Don’t lose that thread because otherwise, again at some point, all these tools just become self-serving. At some point, you’re just, you know, you’re similar with story points. At some point, you’re just, you know, going through story points as a team, because you’ve always done it. And you just keep on doing it. And then, developers get frustrated and things get annoying.

Same thing with metrics. Don’t lose the connection as to why you’re doing those things. because one, it’s going to help with, you know, team satisfaction, employee engagement, um, but it’s also going to make sure that you’re still on the right path. Because if you keep sight of why are we measuring a certain thing? Why are we talking about this in our retrospectives? You can also then have the conversation, “Well actually, DORA metrics aren’t serving us anymore right now, because we’re actually doing quite okay. And, we need to shift to measuring more in the area of, ‘make something up here’, in the area of, you know, like more Agile metrics, or we need to measure a bit more, focus a bit more on the effectiveness side of things because we really need to, add more metrics around quality that we’re shipping.” Or whatever it is.

But, it’s going to help you, yeah not just continue measuring DORA till infinity because you’ve started it at some point and now you’re just doing it. It’s like, yeah, don’t forget that “why?” It’s probably my biggest thing that I’d recommend.

Kovid Batra: No, I think that’s, that’s really great. And with this, I think, in the interest of time, we will stop here because otherwise we’ll just keep on talking. We have a lot to share and discuss. Maybe we can have another episode on this, but for today, we will take a pause here.

And before departing, I would say if there is, one piece of advice that you would like to share with our engineering community, the leaders who are listening to us, the engineering managers who are listening to us, please go ahead.

Lena Reinhard: I would say, you know, stick with the “why” and context is really key. Like understanding why are we doing things? Why are they important? Like, having that context yourself and then helping your engineers understand it as well. Like, and you may have to talk about this context many times. And that’s because it, one, it can change, but also because, engineers will have to then, you know, wrap their head around what it means for them, for their job. And that “why” and that context is really critical and it’s going to help you, like choose metrics thoughtfully, use them well, use them well with your teams and not just as tool check, surveillance, which they’re often kind of abused as. And ultimately, that’s how you’ll also get the metrics to help you drive the positive change that your teams need.

And when you start small and stick with the “why” you’re going to get there, even if it feels like really big task when you’re just getting started, but you’ll be able to figure it out.

Kovid Batra: Right. And I think if people who are listening to this are getting stuck anywhere, Lena is there. You can reach out to her.

Lena Reinhard: Please do. Yes.

Kovid Batra: Cool. All right, Lena. It was a great, great talk. Thank you so much for your time and sharing your experiences with us. Lovely talking to you.

Lena Reinhard: My pleasure. Thank you so much, Kovid.

Kovid Batra: See you!

Lena Reinhard: Bye!

‘Implementing data-driven approach for building efficient dev teams’ with Luca Rossi, Founder at Refactoring

In the recent episode of ‘Beyond the Code’, Host Kshitij Mohan, founder of Typo engages in an insightful discussion with Luca Rossi, the driving force behind a vast engineering community comprising over 50,000 members. The core of their discussion revolves around implementing a data-driven approach to building efficient dev teams.

The podcast kicks off with a fireside chat with Luca which involves lighthearted questions. Luca then delves deeply into the intricacies of the data-driven approach, emphasizing key metrics for scaling efficient dev teams. He also offers valuable insights on establishing the right processes for code reviews.

Wrapping up, Luca elaborates on a thought-provoking concept – ‘Shift focus from 10X engineers to 10X teams’


  • (0:10): Luca’s background
  • (1:02): Fireside chat with Luca
  • (6:15): Key metrics to build high-performing dev teams
  • (8:02): Implementing a data-driven approach and Balancing developers’ autonomy
  • (9:04): Scaling a team with the right dev culture
  • (11:54): Right process for code reviews
  • (14:12): Delving deeper into ‘Shift focus from 10 X engineers to 10 X teams’

Links and mentions

Episode Transcript

Kshitij Mohan: Hello everyone. I’m Mohan your host back with another exciting episode of Beyond the Code by Typo. Today we just can’t hold our excitement because of our guest. He is one of the biggest names today in the engineering leadership ecosystem around the world. He had been a founder, a CTO, and today runs an engineering community of leaders with more than 50,000 plus members.

Here’s to the man himself. Hello, Luca Rossi. How are you?

Luca Rossi: I’m great. Thank you so much for the kind intro, and thank you. Excited to be here.

Kshitij Mohan: Thank you so much, Luca. You have earned it all, so thank you so much for giving your time to us. I would say

Luca Rossi: Thank you. Thank you for having me again.

Kshitij Mohan: Perfect. So we have heard, seen talk, you write a lot about building data-driven engineering teams, and I think this is what we would love to know more about.

But before we jump into your expertise in wisdom, we have a special section for you. Since you’ve been on the show, we had to do something different. So we have a fireside chat for you. It’s a quick series of questions that me, the viewers would all love to have you answer and know the real Luca. So, are you ready, Luca, to get started?

Luca Rossi: I am, yes.

Kshitij Mohan: Perfect.

So let’s get started. Question one, Luca, since you are from Rome, Italy, other than fine wine and football, what else do you love most about Italy?

Luca Rossi: First of all, I confirm that I love wine and football. Like delicious. I love. So many things about Italy, and you know, when you’re from a country,  there are some things that you do not fully appreciate until maybe you get abroad or somewhere else. You take them for granted and then you see it’s not everywhere the same. So as for me, I really love how in Italy we focus a lot on good relationships with family and friends and well-being. I mean, well-being is pretty much defined by the relationship with those around you, with your loved ones.

It’s a great thing that I’ve not, I think, appreciated enough,  until I was older in age.

Kshitij Mohan: Oh, that’s true to your heart, Luca. Definitely. Perfect. Question two, which role do you love more and why? Luca being the CTO or Luca today running this community?

Luca Rossi: Yeah. Wow. That’s a very tough question.

I would say, I love both for different reasons. I mean, because there are definitely things that I miss from my time as a CTO. I mean, I miss the vibes and the energy of working with an actual engineering right product team, working together on some challenge, seeing how maybe junior and younger engineers grow into fantastic professionals or managers.

But I also love the way I can spend my time these days by doing research and writing and,  having great chats with people like you guys, and being able to run and to organize my time the way I prefer.  So it’s a tough call. I mean, right now I’m happy with the lifestyle of the lone writer, and I would not go back, but in the future.

Kshitij Mohan: Definately. Question three. When was the last time Luca, you played a video game, and which one was it?

Luca Rossi: I’ve been playing a lot of video games for my, for my whole life and lately, the two things that I’ve been playing the most are chess, with some friends on chess.com and,  iRacing, which is sim racing, simulation driving.

I have a simulation set up in my place.

Kshitij Mohan: Oh, seriously.

So you have a game parlor, right at your home?

Luca Rossi: Yes, I have. Yes, I have everything I complete online. I mean, the last few weeks, less than I would’ve liked because of a lot of stuff going on. But yes, that’s a big passion.

Kshitij Mohan: Oh, perfect. You turned out to be a gamer, we never knew. So, yeah. Perfect. Question four Luca. What’s the funniest mistake you think you made as an engineering leader or a manager?

Luca Rossi: I’ve made so many that were not that funny at the time, but now make for funny stories. So I guess that’s the right way of seeing at them.

I think one very funny mistake speaking about it right now, not at that time, I used to run a travel startup where people could book and compare different modes of transport, like flights, trains, etc. At the beginning we just were Meta search engine so people could not actually buy the tickets. And we wanted to prototype this feature first to figure out if people liked it. And so we said, okay, let’s just put a buy button connected to Stripe and then we will go manually buying the tickets on the websites of the providers.  And it was great product wise,  it took zero time, but then it exploded in complexity.

We had to take shifts so the whole team, night team during the night booking these things manually. Yes. It’s, I mean, it was insane and we could handle it better, but it was also fun. So yeah.

Kshitij Mohan: Perfect. And one last question for you. Why do you think people love your newsletter?

Luca Rossi: I think there are many reasons. I think the major reason is that I try to keep it practical and dense. So articles are short because I tried to think in my own problems when I was a young CTO because being a CTO has been my very first job out of university, and I didn’t know how to do like anything. And I struggled, finding good content around how to run an engineering team, how to hire, how to organize a team. And so I tried to speak from experience and, and try to tell what I would’ve liked to read when I was younger.  And so try , to write about real stories, practical tips, not just fluffy theory, which there is a lot about management.And so maybe people like this a lot. And also drawings. Of course.

Kshitij Mohan: No. Perfect. I think real problems create real value propositions, so definitely.  Perfect. Luca, thank you. This was real fun. Thanks for being such a sport. Thank you.

Luca Rossi:  Thank you. Thank you for the questions that were great.

Kshitij Mohan: Perfect. So now moving to the real stuff, right?

What Luca Rossi writes and talks and has an expertise about. So I think the first thing that always comes is while building and scaling a dev team, how do the leaders, the managers, how do they go about leveraging these data points, these metrics that they have, but they still don’t have, right?

How they can efficiently put these into metrics to build a high-performing team. Would love to know your thoughts on that.

Luca Rossi: Yeah, of course. It’s a broad topic and we could speak hours about this?  What I’ve seen talking with leaders is that there is so many information out there, there are so many KPIs they could track that people get easily overwhelmed and they don’t know,  how to begin with, you know?

And if they’ve just started, they want to start creating some metrics program or tracking something. What I tell everybody is just start having conversations with your team. It’s like collecting metrics manually, talk with the other engineers or their senior leaders and get their feedback about what they think is working, what they think is not working and then work backwards from there.

Trying to set some very basic one or two KPIs about things that your team think, it’s critical.  So that you can start tracking it for real and figuring out initiatives to get better.  Creating maybe a small process with periodic retrospectives to discuss the trend, how it’s going, but, Always start with conversations because engineers can even be a little bit scared by the idea of getting measured or getting their productivity tracked.

So trying to really make them understand that you’re on the same ship and you’re trying to,  improve things together. It’s very important, so start small and start with conversations I would say.

Kshitij Mohan: No, definitely, and I think very important point that you touched, right? So,  whenever there is a talk about implementing this data-driven approach in an engineering team, right?

There generally comes a perspective from the developers. Hey, are we being micromanaged or is someone gonna look at me every day? How do you balance that stuff out?

Luca Rossi: Yeah. That’s a great question. I think that the right approach is approaching this topic from a point of view of curiosity rather than judgment.

Let’s say. So you look at the data, you look at the issues, and try to figure out what’s happening there. Try to build awareness first around the situation, the numbers, rather than jump into I have to optimize this, I have to reach this target, I have to get twice as good or twice as fast at doing this. So using really the numbers, especially at the beginning as conversation starters about how things work in the team rather than judgemental stuff that makes people uneasy. Yeah!

Kshitij Mohan: No, it makes sense. Makes sense. Perfect. And I think just really connected to this aspect of, building the transparency, building the safety, which internal translates to building the right culture, right?

Scaling a team isn’t possible or isn’t sustainable when there is no right dev culture around it. So any specific experiences, thoughts, or processes that takes into building the right dev culture..

Luca Rossi: Yeah. That’s another great question and great topic because I think culture is what enables good performance, good productivity, right?

If you do not start, you know, with the right approach or the right principles it’s either useless that you track even track numbers or metrics. You have such organizations. I think there are many elements that enable good to great culture.  I can think of a couple that are really very important to me.

One is cooperation and collaboration in general between the various areas and departments. Because I see many teams wherein the engineering is considered like a piece of a pipeline, so things only move in one direction like you start to product requirements. Then there is design, then you have the implementation, then you release and it’s done. While in the real world, it doesn’t work like that. So,  it pays off to involve engineering in conversation from literally day one. I mean, I say engineering, but the same stands for designers, PMs. People in customer support. So, you’re likely gonna build better features by moving fast and iterating with all the stakeholders involved from day one because they can inform better decisions than just moving, you know in just one day.

Kshitij Mohan: Just telling them what to do. Its just being a part of the entire decision-making process.

Luca Rossi: Absolutely. So that’s very important thing to get right, in my opinion. And another thing that is instead more about engineering itself is really focus on releasing, being able to release in production fast and often. Because I, I have to say, if we have to name just one thing to optimize that almost cures all the problems is to being able to release often in production very fast, like in a Minutes.  Because I mean, software doesn’t work like other engineering. It’s not like you’re building a bridge or a building.  It’s something where if you do a mistake, you can recover fast.

So in most situations  it pays off better to have a snappy release process. That also means a snappy recovery process if you do some small mistake than just putting more, guide rates, and cautious parts of the process that expand the release time to how was something that really reduced the productivity of everybody.

Kshitij Mohan: Right. No, I think this totally makes sense Luca! And as you touched about moving fast is what all dev teams aim to, aspire to actually, how can we drive things fast?  So, one important aspect then in this entire shipping process is code reviews. There are definitely certain teams who are moving away from this review process trying to implement a different approach to it, but most of us still follow it, right? So how do you think, what could be the right processes around acing these code review?

Luca Rossi: I think it’s one of the most controversial parts of the engineering process. I agree they’re crucial to the well-being of the team, to the quality of the code. But yeah, it’s also infuriating to me that sometimes we found ourself sweating off the details of our release pipeline to remove 10 minutes out of the deployment process.

And then we just do nothing with the code sitting idle for 18 hours before getting a review,   it’s just nonsensical to me. So I get that we should work asynchronously,  but it’s not like we can wait 24 hours to review some code that has been done in like 30 minutes.  So I think there are various ways of approaching code reviews to try to make them a little bit snappier and more optimized.

One is for sure at the cultural level treated as a P1 activity or P0 activity that is when the review lands and you’re assigned as reviewer. You just have to do it.  You have to do it as the very next item in your in your list. And you can enforce this with notifications.

You can have ChatOps integrations for this, whatever. Then you should try to have small,  code reviews.  Pushing very small batches of code to simplify the job of the reviewer. And, and there’s long tail of more things that you can do. You can adopt more pair programming that actually allows you to avoid code reviews because code is automatically reviewed by your pair.

There are many things you can do, but I think one of the metrics in the KPIs that most teams can start with and it’s beneficial to look into is the  PR cycle time. It is often the case that you can optimize it a lot and it brings benefits across the board.

Kshitij Mohan: Perfect. These are real actionable tips Luca, that I think definitely teams could follow restricting sizes. Taking this up upon priority, limiting your review process.  This really helps. I think moving on to one last thing, Luca, that we have seen you talk a lot about evolve your thought process around this. And I think this is me and we, all of us are excited to know more about, is that you say, Hey, shift focus from 10 X engineers to 10 X teams.  This is a very interesting thought to hear, but we’d love to know more about what exactly that means for everyone in the ecosystem.

Luca Rossi: Yeah. I think we are engineers, so we build systems and processes with software and I think we do the same with teams. And I’m really a believer that 90% of the performance or underperformance is systemic rather than individual. I mean, is the output of a system in place. And then, of course, individuals have an impact on that. But if you don’t begin with good systems, you’re not gonna get a good outcome just because of talented individuals.

And I think sometimes as an industry, we don’t focus enough on this. We do not realize this as much especially,  recently there is this kind of pushback with all the return to office hardcore culture in many big companies. There is this tendency to reward heroics, you know?

And, but the risk to me is that you know, when you reward hardcore and heroic performance, you risk rewarding, for example. The guy who puts out the fire rather than the guy who prevented the fire from spreading in the first place.  And the reality is that most of the,  greatest engineering work that I can think of in my experience is like boring, transparent work that isn’t easily seen.

Because that’s what good engineering is about, good engineering gets out of the way.  So, I think we should focus more on building great systems and great teams. Because that, at the end of the day, enable great engineers to arise. Yeah.

Kshitij Mohan: Perfect. Lovely, lovely thought. Luca, thank you so much.

This was really fun. This was really interesting. We highly appreciate you giving us your time. Luca, thank you so much for being on the show.

Luca Rossi: Thank you again for having me for the great questions and happy to come back any time like.

Kshitij Mohan: Perfect. We’ll definitely catch you up again. Thank you, Luca.

Good day. Bye-bye.

‘Inside the Mind of a Fractional CTO’ with Marc Adler, Fractional CTO for Startups

In the recent episode of ‘Beyond the Code’, host Kovid Batra welcomes Marc Adler, Fractional CTO & Chief Architect for startups. He has previously contributed his expertise to various organizations such as XP Investimentos, ADP, MetLife, Citigroup, and many more. Their conversation revolves around the theme 'Inside the Mind of a Fractional CTO.'

The episode kicks off with Marc talking about his hobbies, followed by a fun fireside chat. Moving to the main section, Marc addresses the unique challenges encountered by fractional CTOs and outlines distinctions between fractional and full-time CTO roles. He talks in great detail about how fractional CTOs lead initiatives and teams in startups. Marc also delves into the intricacies of collaborating with development shops to set up highly efficient teams with a positive work culture.

Lastly, Marc offers valuable advice for non-technical founders to always have a senior technical person by their side.


  • (0:07): Marc’s background
  • (0:52): Fireside chat
  • (7:37): What unique challenges does a fractional CTO face compared to a full-time CTO? 
  • (11:11): Is a fractional CTO role only suitable for startups? 
  • (13:06): How does the fractional CTO lead initiatives and teams in startups?
  • (16:59): How to address the documentation challenge with startup founders? 
  • (19:36): Shaping the engineering culture in early-stage startups
  • (21:22): Observing counter-thoughts or anti-patterns challenging conventional engineering practices
  • (24:52): How to ensure team efficiency and set success criteria for developers?
  • (28:30): Views on significant shift to GitHub Copilot from ChatGPT while writing code
  • (29:41): Parting advice for non-technical founders

Links and mentions

Episode transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us, we have a special and an interesting guest. He has super experience and has super nice thoughts to share with you today. He has 20+ years of engineering and leadership experience as a CTO and a Chief Architect. He has worked with companies like ADP, MetLife, Citigroup, British Petroleum, and whatnot. He has also been working with a lot of startups these days as a fractional CTO. Welcome to the show, Marc. Great to have you here.

Marc Adler: It’s a pleasure to be here. Thank you for inviting me. And, I’ve seen some of your other podcasts with some other guests. And, so I hope that this will be as interesting as the other ones.

Kovid Batra: I’m sure about it. By the way, pleasure is ours. Let’s get started.

Marc, so, in our podcast, if you have already seen those, we have this format of talking to our guests through a fireside chat, wherein we ask you a few questions to know a little bit more of you outside of work, right? So, I hope, you’re ready for that. Let’s get started from there?

Marc Adler: Okay. So, outside of work? Is there an outside of work? I hope there is. So I have, I, I am, uh, somebody who you say is a doer of all, master of none. So, I actually have a musical background. Way back when I went to college, I actually had a double major in Computer Science and classical percussion performance. So, I played in many orchestras and wind ensembles, and my speciality was an instrument called the marimba, which is like a very large wooden keyboard instrument, and played timpani, and all that stuff. And right now, I’m teaching myself how to play classical guitar, so that is my one passion right now, it’s learning how to play classical guitar and trying to play some of the pieces that I used to play on marimba on the guitar now.

And, I’ve also been a private pilot. So, I used to fly all over the place in the New York area. And so listen to strange avant-garde music. And, yeah, I think that, yeah.

Kovid Batra: Yeah. That’s very interesting, actually. All right. I think I still have a few questions for you. I think we would have some interesting answers there. Let’s get started with my questions, okay?

All right. So, this is a hypothetical question, of course. Let’s say, if I give you a time machine, where in your life you would want to go back or go forward, maybe, I don’t know, if you have a time machine, where would you want to go?

Marc Adler: Well, of course, everybody wants to go forward. Everybody wants to be a thousand years from now to see what interesting advances have actually happened in Computer Science and AI and, and just engineering in general. I mean, I’d love to see what the iPhone of the future could do in a thousand years. I mean, there probably won’t even be iPhones. But, going back to the past, boy I think I would have maybe going back to New York to, like the 1964 World’s Fair or the 1939 World’s Fair where there was a lot of excitement and new inventions being shown. I remember, there was this Futurama exhibit, this is where the cartoon Futurama comes from, if you know that. They had an exhibit where they were showing what life would be like in the future. And so, there was, like such an excitement around there. So, yeah, I’d love to kind of go back and, and revisit some like great historical moments that happened in New York City.

Kovid Batra: That’s nice. That’s an interesting thought, by the way. All right, my next question. So, if we are talking about going to the past, do you remember your first functional code that you wrote? Like, your experience?

Marc Adler: Mm-hmm.

Kovid Batra: Describe something about it.

Marc Adler: I do. So, I mean, way back, I got my master’s, so my education is I got my Bachelors in Computer Science and Music from State University of New York at Albany. And then, I got my master’s degree from the University of Arizona, which is a really great school for software. And then, I went to New York University’s Courant Institute of Math for one year in a failed attempt to go for my PhD and did the whole story around that. But, I think the first really good code that I wrote was a music editor in a language called Y, which was a very C-like language that the professors, some professors at the University of Arizona created. So, I did a whole graphical music editor at a time when really graphical music editors didn’t exist. So, that was fun. But, my very first commercial product was I wrote one of the very first word processors for the UNIX operating system. And, I actually showed that at the very first UNIX Expo in New York City in 1984.

So, when you said I have 20 years, yeah, I have 20 years of experience as a CTO and Chief Architect, but I actually have been in the industry for a little over 30 years.

Kovid Batra: That’s nice, man. 1984, you’re writing on code there, and doing the commercial code, I think that’s really, really amazing, man.

Marc Adler: It is. And, you know what the interesting thing about those times were is that we had to optimize every little piece of memory. I mean, there was not much memory in these machines compared to today. So, I used to print out printouts of my code on an old Epson dot matrix printer and take them into work on the New York City subway and look at every line of code and try to get, try to optimize even a little end clause. One statement, if I can get that millisecond or nanosecond of improvement, it really made a big difference.

Kovid Batra: Yeah, I understand. You have seen a big transition, I’m sure about it. Cool! I think that was a very good question to ask.

Marc Adler: And, the funny thing is that you don’t see many people doing that anymore. You know, languages and environments are just so high-level, people will just code and not pay attention to how efficient the code is. And, the only place where I’ve really seen that level, you know, people paying attention to efficiency is in the high-frequency training world, which, of course, I have a lot of experience in as, you know, both in terms of CTO and Chief Architect for various financial institutions, where you have developers who are looking at aligning structures on certain kinds of boundaries and they pay attention to every single nanosecond that their code takes up. And so, that’s a discipline which is lost on most developers now.

Kovid Batra: Cool! I think that was great knowing you, your passion for music, and where you want to travel in time. You’re writing code since 1984 and I think maybe before that. So that’s, that’s amazing, Marc.

Cool! Let’s move on to something our audience is awaiting. Moving to our main section where we get to know about your experiences in your career, how many challenges you have seen, how did you overcome those. And so, let’s get started on to that. Are you ready?

Marc Adler: Yeah. Yeah. Yeah. Go ahead.

Kovid Batra: Yeah. All right. All right. So, you mentioned your role as a fractional CTO, right? Like, recently from past five to six years, as we know, you have been running this organization, part of this organization where you are working as a fractional CTO.

How is this role of a fractional CTO more challenging or less challenging, maybe I don’t, I don’t know, I would love to hear from you, as compared to a full-time CTO who is working with a company? So, just tell us about the challenges that you see and how do you overcome those, and how is it different.

Marc Adler: Okay. So, there are less challenges and more challenges with the roles. And, I’ll kind of mention some of the less challenging aspects.

When you’re involved in a large company, like Citigroup, or I just came off of a CTO role at XP Investimentos, which is a very large, I think it’s the largest brokerage in Brazil. And, when you are dealing with large companies, unfortunately, you have to deal with lots and lots of politics. It’s not easy to get things done. I always say that you know, it’s a struggle to turn the battleship five degrees because there’s just so much that you have to go through with paperwork, with politics, with people who are pushing back against you and want their own agendas. So, that is not the part that I miss with being a CTO or Chief Architect in a large organization. You don’t get that when you are dealing with startups. And, in my fractional CTO practice, I like to deal with startups. The newer the startup, the better. My sweet spot is dealing with a founder that has no technical background or very little technical background where I get to make all of the technical decisions, right? So, you get very little pushback, there’s no politics. And so, that’s the advantage of being a fractional CTO. The other great thing about being a fractional CTO is that you get exposed to so many different domains out there, even domains that you’ve just never experienced before.

So, since I’ve been a fractional CTO, doing my CTO-as-a-Service, that’s the name of my little consultancy, I’ve had clients in education technology, in real estate technology, in almost every field right now, one of my customers is a big university in the United States that is coming out with something very, very new and unique as far as material sciences go. And, I don’t know much about the domain of material sciences, but as a fractional CTO, you get to learn some of that stuff. That’s what’s really, really fascinating is the fact that you can just go to all these different domains instead of being just, staying with just financial technology or training systems all of the time.

So, that’s why every day when I wake up and I deal with my clients, it’s like a breath of fresh air because I always feel that I’m learning something new and I could always have forward progress every day. Whereas, in a large company, you have to deal with politics. But, the good thing about being with a large company is that you have an unlimited amount of resources and development and developers. So, unlike dealing with some of these startups, you don’t have to worry about costs as much as you do when you’re dealing with the startups.

Kovid Batra: So, are you trying to say that the fractional CTO role is probably more suitable in a scenario where you are dealing with a startup, or the large-scale companies or even medium-scale companies should hire fractional CTOs for certain jobs?

Marc Adler: From what my experience is, large companies are not set up to deal with fractional CTOs. I mean, if they have a gap, if their CTO leaves, they’ll usually either fill it internally, or they’ll go outside to the market. They’ll want a full-time person because with a large company, there’s a lot of processes to deal with, there’s more intellectual property to deal with; and as a consultant, as a part-time fractional consultant, you’re not going to get the buy-in from the organization that much. It’s much easier to be a fractional CTO for startups because depending on your pricing model, you could be very, very affordable to a startup. So, for instance, if you consider what a full-time CTO earns in the United States, most startups cannot afford that. They can not afford to have a full-time.

Kovid Batra: Absolutely, yeah.

Marc Adler: For my clients, they’re getting a person with 30+ years of experience, with leadership experience for a small fraction of the price that they would have to pay for a full-time CTO. And, if you’re an experienced technical leader, then you can usually have a higher bandwidth, meaning that you can make more correct decisions upfront, you know, rather than kind of you know, maybe having a few false starts.

So, I think that for my fractional clients, they like to have that level of experience at something that they consider it to be an extremely affordable price.

Kovid Batra: Makes sense. Tell us more about what kind of initiatives, responsibilities you take up as a fractional CTO with these startups and how does it work out with the teams also, like how do they take you as a leader in the team; because even if it’s a startup, I’m assuming there are 5, 10, 15, 20 folks who are working with you in the team. So, tell us about some of specific experiences that you have had and the initiatives that you have worked with.

Marc Adler: Right. So, with almost every company, with every startup founder that I deal with, the thing that I like to see and that they help them with is getting all the product specs together, right, to know exactly what you’re building and to have documentation about what the product is supposed to do, all the use cases, all the error cases, all the edge cases, because I think one of the common mistakes that a lot of startup founders do is they just will take some ideas, they’ll throw them over the wall to some remote development company, and they’ll just say, “Build this.” Most developers, they don’t have a good idea of what to build.

So, what I’d like to make sure is that my startup founders have all their product requirements and use cases there. And sometimes, it could be Figma wireframes, or it could actually be in text, but I want to make sure that the developers actually know what they are building. So, that’s the first step.

And then, once you get all the product requirements, then you have to create the technical architecture, which is something that I do for my clients as part of my job, right? So, you can’t create an architecture if you don’t know what the product is supposed to do. You can’t build an architecture if you don’t know the scaling and resiliency requirements.

So, one of the common things that I see is that non-technical founders will throw their requirements over the wall to a dev shop and get back a system that is totally complex, right? So, something that uses Kubernetes, for instance, for a very simple web app, right? And, you have to guard against what I call resume-oriented development; that is a dev shop who is using technologies that might not be totally appropriate for a system, but they just want to learn those technologies, right? So, I help my founders with that.

So, with the product requirements, you’ll do the technical architecture. Then, what I’ll do is I’ll hire the development team. So, I’ll interview a number of dev shops. And, when we have a short list of candidates of as far as dev shops go, I will get resumes from the dev shops and I will interview every single developer, right? I will make sure that I have the best possible development team for my clients. And then, I’ll work with the founder to come up with the project plan, right, the backlogs. And, I will then run the development team. I’ll do that. I’ll set up the cloud, I’ll do the cloud administration, I’ll face off with the CTOs and CEOs of third-party vendors that we have to deal with, and I’ll basically design the whole system, and I’ll give them over to the developers. And, as far as how is it to work with the developers? Well, I’m the one who hired them, right? So, I’m the one throat to choke as they say, right? I am the technical authority. So, I like to have a development company that will have some good opinions and might push back on some of my designs and for good reasons. But generally, I think that because I am a very technical person, I can still code a lot that the developers usually have some respect for me because I know what I’m doing.

Kovid Batra: Yeah, I get it. Cool. I think the setup is pretty suitable for a startup also. But, one thing that didn’t come to me right as per your opinion was that you have to have all your documentation in place. I mean, that’s the hardest thing to get when you are working with a startup. So, how do you deal with that friction? I’m sure with almost all the founders, you would have some friction there or at least some to and fros there where you would be pushing to get the right documentation and getting it done. So, how does that scenario come up?

Marc Adler: Well, even founders do not like to write documentation, right? Nobody likes to sit there in Google Docs and write lots of documentations. And fortunately, because I’ve been around for a lot of years, I actually have a lot of templates that I give to them. I say, you know, sometimes I’ll give them existing specifications, and I’ll say, “Okay, here is the format it should be in. Here’s some sample use cases. Just tailor this to your needs.” Right? So, almost every system has to have user registrations. Users have to be able to sign up, change their password, have certain permissions, et cetera. A lot of the startups have to have some sort of payments integration with things like Stripe or Plaid or Venmo or PayPal, whatever. So, they can use my pre-existing documentation to kind of tailor things. A lot of startups have to have some kind of alerting or notification system. What I’m mainly interested in is workflow, right? What should the developers be doing? How does somebody navigate through the whole product? So, sometimes the developer, the owners just do not write the documentation, but they’ll have very, very comprehensive wireframes and the workflow on something like Sketch or Figma. And then from that, I could actually take that and write the technical specifications. So, when I write the technical specifications, I’ll say, “Okay, this is the way this service should operate. Here’s the API. Here’s some suggested data models or class diagrams for this service. We’ll do a little bit of eventstorming, right? So, here’s the events that should get generated from this. Here’s the other services that these events should be communicating with.” So, given some kind of either complete workflow or documentation, I’ll be able to then go and create the technical architecture and the technical documentation and specs that I can give to the developers. The more you give to the developers, the less you leave up to chance, right? You don’t have to be worried that a dev shop is gonna come back with something totally inappropriate.

Kovid Batra: Makes sense. Let’s talk about something that is very important, and I think critical also in a way at the initial foundation-level of a startup itself which is around the culture, like engineering culture that is there. Do you involve yourself to that extent where you try to build the right culture for a startup at that early stage?

Marc Adler: All right. Well, for the startups, since I usually use remote development shops, I will always talk to the owners and the managers of those development shops to make sure that they are the ones who are promoting the correct culture, right? It’s not like when I’m CTO at a large company that has my own developers, where I do try to promote a very good engineering culture with continuous education and lunch & learns, and sending people to conferences, things like that, and getting guest speakers to come in. When I’m with a startup and I’m using a remote development team, I will make sure that the development shops are promoting a good development environment, you know, the same kind of principles, continuous learning, things like that. And so far, a lot of the dev shops that I use will do that. They have really great cultures. Some of the ones that I’ve used in the ex-Soviet Union countries, they send me videos of parties that they have and outings that they have, and they are bringing in guest speakers. And so, I’m quite confident that they’re showing love to their developers.

Kovid Batra: Yeah, that is taken care of that way. Perfect.

Marc, I am really amazed with the kind of experience you have had, working with MNCs and then working with startups. So, this is quite a diverse experience. But, do you see in last 30 years or 20 years of your experience, some patterns which make you feel that these are one of the biggest challenges of engineering teams and these should be changing how the world perceives, or I should say, the engineering world perceives few things to be done in a certain way, but those are not in the right direction? Some counter thoughts, some anti-patterns that you see could be the real patterns, actually.

Marc Adler: Yeah. So, I’ve seen moves to complexity and back, right? So, I see that there are developers who hang on the words of certain tech industry acolytes. So people who like, for instance, the whole move to microservices; and I’m a fan of microservices if done right. But, I just saw when microservices were introduced, everybody made a mad rush into microservices without realizing what the complexities are. And now, there’s this whole movement to unwind those and go back to the monoliths, right? Same thing with Kubernetes, which seemed to be the flavor of the month for a long time, but people got into a lot of problems with actually administrating Kubernetes. So, I think that one of the things that I’ve seen is just new technologies being introduced and people just rushing to them. And, as I mentioned to you before, resume-oriented development, right? So, you know, it’s funny, my wife, she was a developer from long back, she worked for some of the big New York financial institutions. She used to work in a system called CICS, which basically ran the entire world. I don’t think it’s really used anymore; maybe it’s legacy now. But, she made an interesting comment. She said, “Marc, everything that you’ve been doing for the past 20 years, CICS did back in the 1980s. And everybody’s just trying to reinvent that stuff.” And so, one of the things, one of the anti-patterns that I’ve seen, again, is just is taking something that should be simple and rushing to introduce more and more complexity. And, for the startup founders, that’s a real concern because whatever a startup founder gets back as a product from a development company should be maintainable. It shouldn’t be written in some esoteric language that it’s very hard to find development resources for. It shouldn’t be using infrastructure up on AWS that is extremely expensive.

Applying my past experience to my startups, I think one of the things I want to make sure is that stuff is built as simply as possible to do the job, right? That people should not be following the word of one tech acolyte or another and rushing into a technology that might not be appropriate for a startup.

Kovid Batra: That makes sense. I think that’s very interesting to hear. And, it’s common, like a new technology comes in and people think that this is the best way to go forward, not much of analysis is done on how the business vision looks like or what the business needs and you just go out implementing what’s trending right there. So, it makes a lot of sense what you say.

Great! I think that was an interesting topic to touch on. Now, one last thing, and then we will wrap up. When you’re working with these teams, we touched on the cultural aspect, but then, how do you as a fractional CTO, make sure that these teams are being efficient, like they’re producing what they really need to, and what are those success criteria that you put forward to the team, to the developers that, okay, this is something that you need to look forward to?

Marc Adler: Okay. So, I do things the old-fashioned way. And that is, I will have Jira boards, I will have sprints, I’ll have a Project Manager tracking velocity, things like that. And, I just get a general sense. Because I’m working with smaller teams, I kind of have in my head where the developers are at. Sometimes I will put myself on pull requests and I’ll look at the code, and I’ll get a general sense of where developers are at, if there’s developers that are giving me any trouble, if there’s developers who are billing eight hours, but it only looks like they’ve worked for one hour, right? So, I’m very good at detecting that kind of stuff, which my startup founders do appreciate. But, I would just say it’s the old-fashioned way of actually maintaining close touch with the developers and the PMs, knowing where things are, looking at code, seeing where we’re tracking against timelines. And that way, I’ll know if a team is efficient or not.

Kovid Batra: Can you just tell us those small tips and tricks that you really apply? When you say that somebody’s working eight hours, showing eight hours, but actually working one hour. So, how does that work out?

Marc Adler: I know that lines of code is usually not a great measurement, but you could see if somebody did a check-in and they changed two lines of code in an ‘if’ statement and they billed eight hours, you know that. Yeah, maybe there was some debugging time involved to find something, but, yeah, you could usually tell. It’s just a built-in sense that I’ve developed working with hundreds and hundreds of developers and being, as I said, being a coder myself, you just know when something doesn’t take that long, but it’s being, it’s being billed. And, you know, one of the interesting things that I do is, with my founders, when I’ll help them go over the monthly bills from the remote development shops and I’ll say, “Hmm, this isn’t right. Let’s get the owner or VP of the development shop on a call. And have them, you know, say, hey, why did this take eight hours when it’s a, you know, it looks like it’s a one-hour change?” So, and then, more often than not, my founders will get a little bit of a credit from the development company, which a startup always appreciates.

Kovid Batra: I’m sure all your clients are loving you for all the money saving and the right technical strategy being implemented from early on.

Marc Adler: Yeah. Well, the interesting thing is with ChatGPT and all these large language models, it’s going to be really easy to write substantial blocks of code in no time.

Kovid Batra: Yeah.

Marc Adler: And so, it’s going to be interesting to see where developers start using ChatGPT or a large language model to write entire classes or entire apps. And then, seeing them bill a lot of time for that to ChatGPT. Basically the whole thing.

Kovid Batra: But, I’m sure like after GitHub Copilot, things have changed already. Like, a lot of people are using it. Every person to whom I’m talking to, like earlier they were using ChatGPT, and now they have completely shifted to GitHub Copilot while writing code. So, do you see that adoption happening? And like, do you prefer that happening?

Marc Adler: Yeah. Well, this kind of goes back to my prior comment about developers not paying attention to efficiency anymore and not knowing if their code is taking up more nanoseconds than it should. I think you’re going to get the next generation of that with ChatGPT, that these large language models, Copilot or whatever are going to be generating large blocks of code, but no one’s going to understand the logic behind it and the architecture. And, you’re not going to know if ChatGPT or the Copilot generated blocks of code, which are not efficient, right? Because you know, it’s the nature of it, right? You have to really take a close look at that code that’s being generated.

Kovid Batra: Makes sense. All right, Marc, that brings us to the end of this show. Lovely having this conversation with you.

Before leaving, any parting advice for the technical founders, the non-technical founders? Your success mantra, maybe?

Marc Adler: Well, I would just say that a non-technical founder should always have a senior technical person by their side. Never just trust throwing stuff over the wall to a development shop.

Kovid Batra: All right, Marc, it was really nice talking to you.

Marc Adler: Thank you.

'Building Autonomous Dev Teams’ with Alexandre Goedert, Head of Technology at Thoughtworks

In the latest episode of ‘Beyond the Code’, Host Kovid Batra engages in a thought-provoking discussion with Alexandre Goedert, Head of Technology at Thoughtworks and a former contributor to SecondFloor and GVT. The heart of their conversation revolves around ‘Building Autonomous Dev Teams’.

The podcast starts with a fireside chat with Alexandre, providing us with a glimpse into his personal journey. As the conversation progresses, he takes a deeper dive into his team collaboration practices and defines what constitutes 'Good software' for engineering teams. Further, he also highlights the pivotal role of large-scale CI/CD, fostering the autonomous mindset and crucial aspect of ensuring a positive developer experience within teams.

Alexandre concludes by offering parting advice to the audience, emphasizing the importance of connecting to business value and fostering a collaborative team environment.

Time stamps

  • (0:07): Alexandre’s background
  • (0:30): Fireside chat
  • (6:41): What are the current team practices that drive the operations? 
  • (10:50): How to overcome challenges in achieving goals amidst ground realities?
  • (11:58): Diving into the philosophy “People just need good software and that's enough to run something”
  • (14:55): Why is CI/CD important on a large scale, and how should it be executed effectively at that level?
  • (18:40): How to encourage the autonomy mindset among the engineering teams? 
  • (22:07): How to define success for engineering teams? 
  • (27:34): How to ensure a positive developer experience within the teams? 
  • (31:40): Parting advice for the audience

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. And today with us, we have an interesting, amazing guest with us who is a curious, passionate technology soul. He has 20+ years of engineering and leadership experience. He’s currently serving as Head of Technology at ThoughtWorks.

Welcome to the show, Alex. Great to have you here.

Alexandre Goedert: Hi. Great to be here. Thank you for the invitation, Kovid.

Kovid Batra: Pleasure. Pleasure. So, Alex, we’ll start with a quick fireside chat where we would love to know more about you outside of work, all right? And here, you have to be, like totally honest and tell us whatever you feel, okay?

Alexandre Goedert: Sure! Let’s do it.

Kovid Batra: All right. All right. So I’ll, I’ll start with a very simple question. How do you start or kickstart your power-packed day? And how do you love to end it?

Alexandre Goedert: Yeah, sure. I’m pretty much a morning person. So I really need to wake up early and try to do some kind of routine. Otherwise, my day is not very productive, right? So, I try to wake up around six, sometimes it’s a bit tricky to not hit the snooze button, but I think I succeed most of the time. And, one thing I like to do at least during weekdays, I do at least 10 minutes of meditation and I try to exercise from 15 minutes to one hour, but depends a lot on how busy my schedule is, right? I try to alternate between yoga, running, and functional exercises. That’s pretty much it. So, I try to do it at least on weekdays.

Kovid Batra: And, let’s say it’s a, like full power-packed day for you and you’re coming back. How do you unwind? How do you love to end the day then?

Alexandre Goedert: Yeah. For me, usually at the end of the day, I’m more tired and I have a son, so I try to keep time with my family. I try to block my agenda. I think in most of the cases, I can do that. And, I think one of the things I enjoy doing nowadays is as I’m living in the Netherlands and I’m studying Dutch, I try to watch news in the local language. I think that’s a way to also do some like a lightweight study at the evening. Yeah.

Kovid Batra: Perfect. Perfect. All right. Let’s move on to something more deep probably, and you can take a minute to think about it and tell us. Those three things that define Alex, like you have three words that define you.

Alexandre Goedert: Yeah, that’s a good question. I think probably the first one I took this StrengthsFinder test some years ago and the first strength that I have is called achiever. And, I would connect that to like I’m a passionate person to try and deliver new things when I’m working. So, I think that’s probably one of the objectives I can think about. I consider myself also a curious person. I think I started on this career because I was just curious to understand how a programming language works. And, what we could do with them back in the day.

So, yeah, problem solving and curiosity, I think it’s also part of who I am. And the last one is, like, I really like to collaborate with other folks to, to achieve solutions together. So that’s, I think me in a nutshell.

Kovid Batra: Perfect. The last one that you’ve said, like you, you love to collaborate with people. I think this is a very good quality to have, right? And, if it comes innately and if you really believe in it, that’s super amazing because that way, you are able to create even more impact than you could do individually, right?

I just want to understand what do you think actually inspires you to be more collaborative? What drives that thing in you that makes you so collaborative with people?

Alexandre Goedert: Yeah. I think it’s since I started developing software. So nowadays, I cannot be in touch with code as I used to be, but I remember when I was starting to code, it was amazing to me that the things that you could do when you started working in your team structure, in your relationships and communication lines.

So for me, the journey was like from a developer, I became a tech lead and I had to balance these activities of writing code, being with clients in meetings, talking about architecture, talking about.. And also, doing some coaching and mentoring of team members. So, I think that’s, for me, a big motivation is okay, how can we develop software in a better way? And, I think part of it, it’s through communication and relationship within your team.

Kovid Batra: Makes sense. All right, moving on to something related to book reading, I’m sure you must be doing that. Just tell us about the latest book that you’re reading and share some learnings from that.

Alexandre Goedert: Sure. The book I’m reading at the moment is called, ‘Find Your Red Thread’ by Tamsen Webster. And, this book actually I gained in a conference that I presented last year. It was sitting in my shelf for quite some time and I picked up recently. So the author is, she used to work as a TEDx idea strategist. So, she was essentially responsible for selecting multiple TED talk ideas, right? And there was a lot of competencies. So, she came up with this structured way to select the best talks. And, I think why it’s relevant to me nowadays is that I’m spending a lot of time trying to build proposals for new clients, and sometimes when I join a client engagement, I have to set up the foundation of this new client account. And, I think it has a lot to do on how you communicate your story in a way that is compelling to the other person. And so, it’s a very interesting book from this angle. So yeah, I’m finding it very interesting.

Kovid Batra: Nice. I think that’s, that’s really interesting. Never thought somebody would be planning what talks to have on TEDx. So, I think that really requires a deep thinking and connecting with the audience. Yeah.

Amazing. All right. I think that was knowing you and it was pretty amazing. I would love to move to the next section, which is talking about your experiences, your success, failures, how you work with your teams. So, are you ready for the main section? Let’s get started?

Alexandre Goedert: Sure. Let’s start.

Kovid Batra: Perfect. My first question is how do you currently work with your teams? Just talk about some of the practices that you follow, and what do you think you are trying to achieve in terms of operating in the most ideal way. So, just talk about something, how you operate right now and how you would want to operate ideally with those teams.

Alexandre Goedert: Yeah. Yeah, it’s a good question. I mean as I mentioned, I like to collaborate with other people. And, also in the StrengthsFinder, I have this “relator” attribute. So I enjoy doing that, but it’s not always easy, right?

So, as a work I’m doing now, the role is called Head of Technology, but in practice, as I work in a new market within ThoughtWorks, I have to do a lot of work with demand that is related to technical sales, but it’s also related to how we implement in the region, the technical, or the technology strategy from ThoughtWorks Global. So, for me, the interesting part is that how we articulate that strategy into action with different people. So, the way I prefer to do it is like, we have a group that we call Tech Council. And, we have representatives of different specialties. And, we try to come up with agreements on what is more important. So, a lot of times what I try to do is like, drive this group to actually prioritize together. I think you need to give up some structure because otherwise it’s just, it takes a lot of time. But, I don’t try to solve everything by myself as well. So, I try to give some structure and let also the thinking flow a little bit. And of course, you need to sometimes take decisions on, okay, we should go to this side, or we should pivot. But, that’s pretty much how I like to work with my teams and of course, we have people with different seniority, so, sometimes you have to support a little bit one person or the other.

Kovid Batra: I have a question here.

Alexandre Goedert: Yeah, sure.

Kovid Batra: So, this team, first of all, I didn’t catch the name of the team. You call it the?

Alexandre Goedert: We call it the Tech Council, Technology Council.

Kovid Batra: Okay, Technology Council. What’s the purpose of having this team in place? Like, for you as a Head of Technology, translating, let’s say, the business strategy into a technical strategy and then execution is something that you want to do, but how does this team actually help you in doing that? I just wanted to understand because I’m just listening to this term for the first time. So..

Alexandre Goedert: Yeah, sure. I think for me, the main benefit is to have people that can challenge my own ideas and perceptions, right? I have a lot of experience in this market. But, I’m not a technical specialist in some areas nowadays. I think technology has changed a lot, and nowadays, it’s very hard if you’re a generalist to actually know some specific things about, let’s say, IoT, data and AI, machine learning, you know? So, I use this group as my source of information and critical thinking about different tech trends. Yeah. So, I cannot do all by myself.

Kovid Batra: Amazing. I think this is a very good thought, and this really helps in making much better decisions that you could be taking individually. So, it makes sense. Perfect.

Alexandre Goedert: Yeah.

Kovid Batra: All right. Yeah, please, please go on. Yeah.

Alexandre Goedert: No, exactly. So, I try to use this thing as much as possible. It’s a lot to do with, like creating the structure for a conversation, having the conversation, taking decisions during the sessions, and then helping to draw a conclusion at the end and next steps, right? So, for us, it’s really important to know what we are investing in terms of technology strategy and how we can meet this sweet spot because we need to sell things that the client wants, that our thoughtworkers want to work with, right? And things that we can actually have the capacity to deliver.

So, I think the work is actually finding the sweet spot and taking decisions every now and then to adjust.

Kovid Batra: Makes sense. Perfect. So while you’re working with your teams and making these decisions and then operating, do you feel that there is something that you could do better? Do you feel anything missing right now which you’re not able to do, or maybe you’re trying to do right now, but some realities, some ground realities stop you from doing that and you’re finding your ways out?

Alexandre Goedert: Yeah, yeah. I think always, right? But in my case specifically, as I work for usually new markets within ThoughtWorks, it’s always a very constant stretch between working with demand and pre-sales pursuits and looking inside ThoughtWorks from an engineering point of view. This is normal because new markets in ThoughtWorks, they’re kind of an internal startup. So, it’s part of the work, but doesn’t mean it’s easy. Right? So, I think a lot of effort is also to try to balance these things. And, it means having to drop a lot of plates sometimes. But, yeah, I think that’s something that’s, it’s always a struggle.

Kovid Batra: Yeah, absolutely. But, I think the balance is the key. Like, you always try to strive for that. Makes sense. Perfect. Perfect.

All right. I remember our last conversation, like when we were talking about having this podcast together, you told me, “Kovid, people just need good software and that’s enough to run something.” And, I was intrigued by this thought, but I could not relate to a situation where this philosophy exactly fits.

So, I just wanted to, like go back to that thought and understand more from you. Like, from what context it is coming, in which situation this philosophy applies, or it is generally applicable in every scale of company, be it like the scale of ThoughtWorks or be it a startup of 20, 30, 50 folks?

Alexandre Goedert: Yeah, sure. I think the point is, like, what good software means, right? And, if you talk to different people, they have different definitions. And usually, it’s the case that technical people, they know better. And, this reasoning doesn’t come out of the team. So, we have this classic misconception of people want to start with a new team and deliver fast into production without investing in good engineering practices and having a solid foundation, right? So, because what you want to achieve at the end, you want to have a software that is easy to evolve. So, to consider nowadays, business is changing faster than ever. So, I think after the pandemic and with all this recession.

Kovid Batra: Definitely.

Alexandre Goedert: Yeah. Together with the fact that technology basis is very accelerated. So, we can only make a good usage of the client’s money, if you build software that is adaptable. So, we need to be very conscious about what good looks like in this scenario, right?

Kovid Batra: Yeah.

Alexandre Goedert: So, for example, we cannot afford accumulating tech debt since the beginning and we need to expose that. So, what’s the shortcuts we’re taking? What is the consequence of taking some bad decisions in code? So, the problem is that you need to invest some more time initially to make able to make easy changes later in the software. And, some people take the shortcut to deliver fast initially and after some time, it just stalls, right? So, I think it’s a lot about that. So, to define that from the start and make the team with proper autonomy to fight for it, to explain what good looks like to the external stakeholders.

Kovid Batra: Yeah. I think now, I think I relate a little bit. In one of my podcasts with Serdar Mustafa, I think he mentioned, “It should not be a Minimum Viable Product, it should be a Minimum Lovable Product.” So, when you have that mindset of building a Minimum Lovable Product, you would definitely consider building the software also to a certain standard that doesn’t.. I mean, of course it has to cater to a customer’s requirement and the person should love it at the very first stage, but also, it should not be a tech burden for the coming months or the coming years when you’re operating on that. So yeah, it makes sense.

The next thing that I would love to know from you is that this topic is quite hot in the DevOps from quite some time now, but still, how important do you think for a company like ThoughtWorks or at that scale, a continuous integration and delivery, deployment is important? And, how do you think it should be done at that scale?

Alexandre Goedert: Yeah, I mean, it’s something that we like pretty much inside ThoughtWorks, right, since we started to work with the agile movement when we used cruise control that was on the first CI servers back in the day. So I think the discipline of keeping your build in a healthy state and your artifacts always ready to be shipped, I think it brings many benefits. So, if you do it right, there is no concept of works in my machine problem. So, you get consistency across environments. There is also no obscure script that you need to execute and then only some senior folks know how to do it, right? So, you deploy, your deploy is automated and it can also be audited.

There’s also a good way to recover from failure. So, or even if you use techniques like Canary Release. So, I think in a way, you can give the autonomy for the team to deliver instant value and even multiple, multiple times per day, right? So, for us, it’s really one of our core practices. And I think one very interesting way that we try to apply it is, like when we start a new team, the first iteration, we call ‘iteration zero’ and it’s really what would a ‘hello world’ for this team context would mean in production. And, we start by building the path to production from a CI perspective, right? So after that, your first story, it’s automatically deployed in production. So, I think it’s a mindset that is very important if you want to be really adaptable as a software team.

Kovid Batra: But, I think what we have usually seen is, I mean, it’s right that you have to build that frame of mind in the teams to actually move on to this process and this kind of ideology. But, there are a lot of challenges like they’re innately, people are not in for it. Why do you think is, is that there, like with developers, with teams? It exists, I’ve seen that. What do you think is the reason? How should one work on that?

Alexandre Goedert: It’s interesting, right? Because what I’ve seen also in, if you talk about DevOps as a culture or a mindset, in many companies you see nowadays that platform engineering is all the rage and the way some people implement is by having these layered teams, in the sense that you have all the expertise about DevOps inside one team. And then, you have the consumers that only know how to consume that, but they don’t have the knowledge of built themselves. So, if any clients that we work with, we try to say, okay, you know, “Platform team, you should build services that should be composable and owned by the external team.”

So, for example, if we’re building a development pipeline, I can maybe build some libraries that I can connect to build stages in my CI, but I never should build the pipeline myself for the other team. The team should own that, and they should know how to build that from scratch. I just build accelerators, right? And try to build some conventions around what’s good. So, for me, that’s something that we see in many clients. And, they see, okay, I have a platform engineering team, but I still need help with DevOps. And usually, that’s the case. So, usually, you don’t have a multidisciplinary team where actually people own the full deployment process, right?

Kovid Batra: Yeah. Perfect. All right. I think moving on to something which you just talked about, like you should allow the teams to do it themselves. You should work as an accelerator there. So, this is more around giving them autonomy. So, how do you think we can bring this autonomy mindset or how do you think we can improve this autonomy in the teams and inspire them to probably deliver more? Because when people are autonomous, I’m sure they move faster. They feel more accountable. There is more value delivered in that scenario.

Alexandre Goedert: Yup.

Kovid Batra: So, how do you do that? Or how do you recommend to do that with different teams?

Alexandre Goedert: Yeah. Yeah, sure. I think CI/CD is actually a mean to an end, right? So, when we talk about autonomy, I think what something that is very important in delivery teams is to connect the software delivery process with the business to start. And, it seems obvious, right? But in many places, you have this multiple layers of teams, people, and processes that are sitting between the software is deployed and the actual value that you have from a business perspective, right?

So, I still remember when I once back in the day, I had to develop a fancy 3D visualizer for market data used for financial instruments.

Kovid Batra: Okay.

Alexandre Goedert: And, we had a BA that tried to capture the requirement from the user. And then, it was our proxy to the business. Past it was, we took one month to develop some beautiful 3D charts. At the end, the client said, “Okay, it looks beautiful, but actually, it’s useless for us from a business perspective.” Right? So, I think that’s the first thing. So, you need to.. Many people have POs nowadays, but I mean, is the PO really a representative of the business? Do you really have autonomy of pivoting your backlog if you’re required to, right? So, I think that’s the first step.

And, I think people should start having observability for business metrics as well. So, what are the KPIs that are lagging or leading that indicate that what you’re developing is making an impact, right? So, if I talk about e-commerce, for example, you might think about a conversion rate for a sales pipeline. So, what is the conversion rate after I do every release of my product? What’s the impact of the conversion rate in the total revenue of the company? There’s a correlation or not? And, the developers should try to explain that. So, I think that’s the starting point. And then, if you have that combined with automation and a good software process.

Kovid Batra: Yeah. Got it.

Alexandre Goedert: You can achieve real, real autonomy. Yeah.

Kovid Batra: I think this is a very, very interesting point. This goes long way actually. If people have clarity on the impact that they’re gonna create, their brain starts working in a very different manner than if you just tell them, “Okay, do this piece.” Like, accountability kicks in, your curiosity starts popping up, right? You tend to think of ideas that could actually get things done, and you become more agile also because you know that you want to achieve this. If something is defined and it’s not working out, you are seeing it in real time, you are quickly adapting to something else, which could really work out according to you. So, I think that’s a very interesting point where autonomy can be built by bringing that visibility of the business metrics.

From the point of business metrics, I think, for sales teams, for support teams, there are always some KPIs defined, people are looking at it. If you go to the juniormost salesperson to the Head of Sales, everyone knows that, okay, they need to work on the revenue or they need to close this client, which would bring so many dollars, right? With engineering teams, I feel, there is a little bit of a gap. I’m not sure how you think about it. So, I would love to know your opinion on how you define success for an engineering team and how you measure it, how you find inefficiencies there and then try to improve on those right?

So, I hope I made my question clear there.

Alexandre Goedert: Yeah. Yeah. Is it clear? Yeah, it’s clear pretty much. So, I think that the problem is that developing software is expensive, right? So, it is even more so if you need to break your system every now and then to add new features and that unfortunately happens very often, right? But, that’s no wonder that many different corporate departments, they just want to know how IT is performing as a whole, right? So, there’s a lot of pressure over CTOs and these kinds of roles. So, sometimes it’s quite a difficult conversation for non-technical people when engineers, they have to constantly excuse themselves for a perceived bad performance, right? So, it’s the perception that IT is always lagging behind. So, I think the problem is that we need to explain these technical reasons in a way that people can actually relate to them.

So, before actually measuring, I prefer to start optimizing the flow and capturing the metric, what a normal metric looks like. So, we always have this problem of business coming up with estimates and people have to say, “Okay, I think it’s nice.” But, no, no one knows at the end, right? So, what we prefer to do, at least at ThoughtWorks with our clients is, let’s start the first iteration. We optimize the flow to a minimum level, and we try to see what our base is, what’s our throughput after a couple of iterations. And then, let’s start to measure those things, right? So, how many cards we have for iteration. Usually, one thing that we also try to cover is DORA’s four key metrics. So, okay, what’s our lead time from idea in the backlog until deployment? What is our time after the commitment to the deployment? What’s the change failure percentage? So these, these things we, we try to measure together with the throughput, and then we try to interpret what is happening after each iteration, right? So, sometimes you have a lot of outliers. So, maybe you have one card that it was too big and was poorly captured. And, this thing is dragging your lead time as an average, right?

So, I think what you need to create is this habit of normalizing what are the metrics for different teams, acknowledge that each team is different, and then try to use that as first signals, but then interpreting what reality looks like after each iteration, right?

Kovid Batra: Yeah.

Alexandre Goedert: So, I think it’s very dangerous sometimes when people try to come up with metrics from outside because in other departments, I mean, if you talk about sales, it’s pretty easy to have a target, like, okay, what amount of leads we have and how much leads are converting, and what’s the revenue that we have projected, right?

Kovid Batra: Yeah.

Alexandre Goedert: In software, it’s a bit harder than that. So, we need to create ways to communicate, a sense of performance, but that’s not all. We need to always interpret them and explain to the outside non-technical audience in an easier way.

Kovid Batra: I think just to add onto this, I feel we measure velocity, the quality, throughput, and then we have these DORA metrics to enable us to measure that. What I feel is that this is very critical. So, it’s like engineering is a function which is always enabling the whole business. Like, depending on the nature of the business, the percentage would vary. But, at the end of the day, if I look at a product team and an engineering team, I mean, they should not be looked at separately. I feel they should be one unit, because at the end of the day, what product is going to deliver cannot be accomplished without having that feature or a release in place, right? So, for an engineering team and for a product team, the metrics they need to actually look at to create that impact should be same, like it could be something as simple as user satisfaction, right? Like, after every release, how the satisfaction of the user is growing, let’s say, if it is aligned with that particular metric. And, let’s say, if that is not working out and you’re not seeing the impact there, then when you deep dive and try to understand what could be the reason behind it, is it the bad user research or is it the bad quality of the software that we are producing here? And then, comes the point where you say, “Okay, quality is bad.” Then you jump into those metrics and then look at it.

Alexandre Goedert: So, I think a combination of these business and technical metrics, as you mentioned, yeah. Yeah.

Kovid Batra: Yeah. I think that makes sense. It was really an interesting point there. And, lastly to conclude on a point here. I mean, I just wanted to understand it from you. When you look at the throughput of the teams or how they’re doing velocity-wise and everything, I’m sure there are certain cultural practices that you are ensuring to have a good developer experience also, where you take care of the developers, where you take care of their well-being. So, just wanted to understand, how you ensure in your teams that a good developer experience is there, and…

Alexandre Goedert: Yeah, yeah. Yeah, I think that is a very good point. I was a bit not skeptical, but I, I didn’t believe, for example, in pair programming as something to use constantly before I joined ThoughtsWorks. And, I was amazed to see that we actually use it quite a lot and so this is 1 of the things, right? So usually inside a team, I mean, staffing for technical teams is very complex, at least inside our company, right? So, you need to find this right combination of people that it’s a benefit if they can work together or not. And then, there are also people, so maybe they don’t get along with each other. There are many variables. So, what I like about pair programming is that it enables you to usually level up the team according to technical expertise, according to the one person that knows best about a particular tech stack, for example. You should do a proper rotation in pairs. It could be after one week, after one iteration, after a couple of days, depends on the team. But in my experience, it helps a lot to create this sense of support. And you know that you are not alone, that you can count with other people, right?

We also like to have these sessions we call ‘Dev Huddles’, usually on a weekly basis. And, I think it’s important for new teams. So, if you need to take an architectural decision, you’re not quite sure, you can have this huddle to actually talk with the team and maybe you capture a decision as an architectural decision record at the end. It also helps to create that sense of, okay, it’s a collective ownership of the code base, right? You should read the code base, you shouldn’t know which person wrote each part. It, it should be a collective like standard. So, I think these practices help a lot to achieve that.

Kovid Batra: A lot, yeah. I think that is a very good example actually. And regarding pair programming, I have been hearing both sides, but, if I have to, like personally, go for this opinion, it really works, I feel so.

Alexandre Goedert: No, and to be honest, I mean, I don’t think it’s something to do all the time. For example, there are certain tasks that are quite mechanical. Maybe some of them you can automate with AI nowadays, but still, if you don’t need to think a lot critically to write the code, maybe you should just do it yourself.

Kovid Batra: Yeah, yeah.

Alexandre Goedert: At the end of the day, as Martin Fowler used to say, right? “Our limits in velocity is not dictated by the speed on which we can type in the keyboard, it’s by the speed of thought.” So usually, if we have two people, they work faster.

Kovid Batra: Yeah. Makes sense. Perfect.

I think to sum up this point, I feel looking at a lot of aspects of an engineering team is very important. So, just to like, put out loud these DORA metrics are important. Developer experience, the processes that are built around having a good developer experience are very important. So, probably product and engineering can have similar goals, but when it comes to the KPIs or on daily or weekly or sprint level, you have to look at how people are doing or efficiency-wise people are doing, maybe product has different metrics and engineering teams can have different metrics.

So ultimately, it is important probably to have that measurement in place, so that things remain on track. But yeah, I think it was really, really interesting to know those aspects from you, hearing those hands-on advice that you have just shared. So, thanks a lot for this, Alex. I really loved talking to you.

Alexandre Goedert: Thank you for the opportunity.

Kovid Batra: Great! All right. So with this, I think we’ll end our episode. Any parting advice for our audience?

Alexandre Goedert: Yeah. I mean, I think one of the things is like, try to get more ownership about what you deliver from a business perspective. Don’t think it’s normal to accept tech debt, try to correlate that with business and money value right? So, as technical people, we need to be able to explain what we do, even though we have to translate it. So yeah, my main advice is like optimize your flow first. Try to connect to business value and try to create a team environment that is good for everyone.

Kovid Batra: Perfect. Thank you so much.

Alexandre Goedert: Thank you.

Kovid Batra: All right. See you. Bye-bye.

Alexandre Goedert: See you. Bye-bye.

'Leadership, Management, and Engineering Metrics’ with William Mendes, SRE Manager at Feedzai

In the recent episode of Beyond the Code, Host Kovid Batra engages in an insightful conversation with William Mendes, SRE Manager at Feedzai and mentor at IFTL. He had previously contributed his expertise to well-reputed organizations including Accelera Technologies, FARFETCH, and FCamara. The central theme of the discussion revolves around Leadership, Management, and Engineering Metrics.

The podcast begins with a fun fireside chat with William, allowing the audience to see his candid side. Later in the main section, he explores the challenges faced as an SRE manager. He discusses the balance between metrics, including DORA metrics and Cycle time, and the need for direct communication. William also emphasizes psychological safety and shares strategies to prioritize and support developer experience and well-being.

Lastly, William offers valuable advice on seeking feedback from the team for personal and collective evolution.


  • (0:06): William’s background
  • (0:40): Fireside chat
  • (7:59): William’s role and day-to-day responsibilities as an SRE Manager at Feedzai
  • (9:27): Challenges in William’s day-to-day role and responsibilities
  • (12:52): What key metrics guide the leadership approach in the current scenario?
  • (15:57): How to navigate the challenge of relying on metrics vs. the need for direct communication? 
  • (18:22): William’s experience with implementing metrics for teams at different organizations
  • (21:31): How to prioritize and support developer experience & well-being? 
  • (24:29): William’s take on room for improvement in his current approach
  • (26:30): Parting advice for the audience

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with me, I have a really amazing guest. He’s a calm, composed person, yet a very passionate leader. He believes that leadership is for people, not for projects or tests. He’s currently an engineering manager at Feedzai. He has 10+ years of experience in engineering and management. He’s also a mentor at IFTL. Welcome to the show, William. Happy to have you here.

William Mendes: Thank you so much, Kovid. It’s a pleasure, man.

Kovid Batra: Pleasure is ours. All right, William. So, I have given a quick intro about you, but our audience would love to know you more. And for that, we have a quick fireside chat where we will ask you a few questions, and that would help us know you better. Are you ready for it?

William Mendes: Okay, of course. Let’s go.

Kovid Batra: All right. My first question. So, you have to be very honest, okay? Like, you have to tell what’s there, okay? So, what are you really passionate about? And it not necessarily has to be work, it can be outside of work also. So, tell us about your passion.

William Mendes: Okay. I am really passionate about evolution and performance, and I have a love for engines and improvements. So, right now this is translated into my biggest passion being motorcycle traveling and almost everything related to cars and motorcycles. And, and that’s it.

Kovid Batra: Nice! I think we have a bike rider on the show now.

William Mendes: Yes, you do!

Kovid Batra: All right. I, I mean, that’s really interesting. Tell us something about your first motorcycle trip. When did it happen and how was the experience for you and what made you, like really stick to it going forward?

William Mendes: Okay. My first big motorcycle trip was a trip to Picos de Europa in Spain.

Kovid Batra: Okay.

William Mendes: And, it was a completely immersive, exhilarating, and fulfilling experience. It’s something that you can’t describe, that you cannot feel unless you ride a motorcycle, that is being part of the environment, feeling everything, feeling the cold, feeling the weather, feeling the wind, and listening to everything. And, on top of it, having power, having control, and being on top of the situation. It’s amazing. It’s an amazing feeling.

Kovid Batra: That’s nice. So, how old were you when your first trip, motorcycle trip happened?

William Mendes: I was, uh, I started riding motorcycles when I was 13 years old. And, my first big trip was in Europe was 26.

Kovid Batra: 26, okay.

William Mendes: So, it took me a while to take the courage to do a big trip like this, riding for a long day.

Kovid Batra: So, you ride solo or is it like a gang, you go together? What is it like?

William Mendes: I had both experiences. Right now, I have been traveling with my wife a lot. So, those pictures in here, have me and her traveling around. We went to a lot of places and I think that being in a smaller group with people you can count on is the perfect environment and the perfect set for a motorcycle trip.

Kovid Batra: Nice, nice! Amazing, man.

All right. Next thing that I would love to know about you is how you get inspired, from where do you learn? So, yeah. What are you reading these days? Just tell us about your last read and some interesting lessons from there.

William Mendes: Okay. Right now I just closed the ‘Radical Candor’ by Kim Scott.

Kovid Batra: Okay.

William Mendes: And, it’s a very impressive book on leadership and how to be candid and clear with the people who work with you.

Kovid Batra: Okay.

William Mendes: And, still show them that you care and that you are working together on the same purpose and the goal. And, this is amazing, a very nice book.

On top of it, I try to have a very disciplined routine. I am usually reading two books at the same time, one in the morning related to leadership and one technical book in the afternoon. And, consuming a lot of podcasts, consuming a lot of content to stay on top of the topics that we’ll have to do.

Kovid Batra: That’s nice. I think you’re probably into that zone where you’re trying to understand what a true leader looks like. And, maybe that is something which you are pursuing in your career also. Is this the reason why you are reading these?

William Mendes: Yes, exactly. For me, it’s very important. So, when I started my career in leadership, it was not as fulfilling as I thought it would be. Actually, my first experience was frustrating. I was not prepared for that. I did not know how to be a good lead and how to deal with the people that I had below me or that I have with me on that journey.

So, I got back. I read an article from Charity Measures. Which is called the ‘Engineering Manager Pendulum’. And, I did the pendulum. I got back to an IC role. I started working on myself and trying to improve, to understand what went wrong and how to improve to be a better lead. And, by doing so, I developed a very interesting routine of topics to learn that would allow me to be a good engineer first, and then, a good lead for that engineer that I was making of myself. And with that, I had to fulfill that role.

Kovid Batra: This situation would have been very different, right? Like, moving to a leadership or a management position, and then going back to an IC, and then again, aspiring back to be one. I think, probably there is something that you realized in that phase, right?

William Mendes: Yes. First, for me, that is the feeling of being an engineer that is always with me. I am always curious. I’m always trying to be on the top of the technology that I am working with. Even though I am not fulfilling tasks anymore alone, the vast majority of the problems that I am solving, I am solving with my team and that they are involved with more technically with that. But, being on top of this guaranteed that I understand their pain, I understand their challenges, and how to help them move forward with this. And, by doing so, I can guarantee that everything that I have to be a good lead, to be a good leader, to understand the necessity, how to talk with them, how to understand their motivations, and to engage with them will be on the right place when I need it.

Kovid Batra: That’s amazing, William. I think this journey of learning and learning specifically when you have to change yourself from the core, because in the beginning, when you realize that you are not a good leader, I’m sure that would have been very disheartening also at that point, but..

William Mendes: Yes.

Kovid Batra: It’s good, like people like you are definitely the ones who have a real growth mindset and want to do something. They don’t feel the gap where they can’t do anything. So, I think this is really nice. Appreciate it. It was really nice knowing you through this fireside chat.

Now, I think we would love to move to the main section where we would like to talk about what you are currently doing, knowing about your experiences, your success and failures. So, I hope you’re ready for the main section.

William Mendes: Okay, let’s go for it.

Kovid Batra: Perfect. Perfect. So, let’s start with a very simple question, like, tell us about your current role, your responsibilities as an SRE manager at Feedzai. How does it look like?

William Mendes: Okay. So, the SRE team at Feedzai is the responsible team for the entire infrastructure and the health of our products. So, if a new customer signs a contract with us, my team will be responsible to set the proper environment for that customer to be working with us, to have all applications that they hire, and to have everything working as soon as we can. And, as soon as we have that customer working with us, my team will be responsible to redirect and guarantee that customer is having the best services that he has hired from our company throughout our infrastructure and platform. So, we have different projects, we have different capabilities and a lot of amazing people working with us around the clock. We have an amazing team completely distributed. We have people in Australia. We have people in China. We have people in Europe. And, we are talking about having a complete functional team solving everything that is needed to have a happy customer with our company.

Kovid Batra: What are the usual challenges that you see in your day-to-day role and responsibilities? Like, the top most ones, just tell us about that.

William Mendes: Okay. This type of team has a very specific need, which is you have to understand and work with context. You have to understand everything that the customer needs and everything that was sold to a customer, how to integrate that with the operation that you have running, and how to guarantee and communicate with the customer and with the other areas in the company to guarantee that satisfaction and that delivery.

Kovid Batra: Can you give us an example? Like, I think audience would be able to relate more, like any, any specific example that could explain any of that situation. Yeah.

William Mendes: Of course, of course. So, imagine that a customer signs with us, and for the vast majority of applications that we have, this customer requires us to use, specifically for them, a different type of database.

Kovid Batra: Okay.

William Mendes: And, even though we do not support the database on our infrastructure so far, neither our products have connectivity to it, neither something to support it, this customer would represent a very important customer to the company in the future. And, we have to work with that.

So, my team will be responsible to investigate and to help the product team adopt this new database, for example. And, it could be a database or a message queue or something like it that will integrate with our infrastructure and products to implement, to define a plan to understand how to keep it reliable, and to make it work with that customer in the future. So, we have to integrate the entire company working towards that environment, to understand their necessity and to help them understand until when we’re going to be able to provide that, how we’re going to do it, and why something would be or not be possible.

Kovid Batra: Right. Now, I get the point when you were saying that when you have to do something, the team has to have full context, any new piece of tech coming into place, any stack coming into place, whether it fits, doesn’t fit, what would be the feasibility; all those things can be answered well only if you have the complete context. So, I think now I relate to the point which you were saying. So, that’s cool. I think that makes the job challenging, but I feel it’s interesting at the same time, right?

William Mendes: Yes, very interesting, mainly because we have multiple sources of income for our work. So, we have inputs coming directly from our customers. We have inputs coming from the teams that develop our products, the company that requires something to be implemented for their perspective. And, we also have inputs coming from inside the team, something that we have to improve, something that was not working as expected. Therefore, it’s just moving pieces that we’ll have to integrate and make the work per se.

Kovid Batra: Makes sense. Makes sense. Totally. All right. I think this was a very good example to understand what your role, responsibility looks like and how challenging it could be at times. I think one thing you just mentioned in the fireside chat also, and like last time when we were talking about having this podcast, I had that sense that you really want to grow into that position of leadership also. So, being a manager for the site reliability engineering, at this point, what kind of metrics do you look at in the team, and how looking at those metrics defines the leadership that you would want to take up with the current scenario? I hope my question is clear, right?

William Mendes: Yes, it is. This is a very interesting question because, you know, being a good leader means that you have to take actions on top of something that you can measure. You cannot take actions based only on your opinion. And, this is a very interesting pitfall for the vast majority of leaders. Me, myself, when I started this work as a lead, I thought that I had the clear goal and idea and everything could be taken under my special opinion. But, without collecting metrics, you cannot lead properly, you cannot guide your team properly. So, thinking about the metrics that you can have, I will go back to the context principle when you have to understand which metrics fulfill the context of your team.

So, for example, for my team, we work both on projects and service requests, which means that for projects, I have to understand the cycle time, I have to understand when a task enters the board, when a task enters, when a project is defined, refined and enters on our work, and how long it takes to be completed and to have that tool, that feature provided for our customers. I also have to understand the number of changes, the deployments, the PRs that we are doing to maintain a customer happy, as I have to understand the failure rate and the mean time to resolution for everything that we are running. And, a lot of the things that we have comes from the perspective of understanding also the MTTF, the mean time to failure. So, if we saw that something that was not a solution, it was a mitigation, how long would it take to be failing again, so we can fix it properly, and to understand that, during the day to understand that, during the working hours, and during incidents. So, when an engineer from my team is called 2 a.m. after having a time off with his wife or his companion on a Friday, he doesn’t have to rely on his opinion or on his specific oral knowledge. We’ll have to set procedures and give them metrics to take those needed actions. So, is it better to mitigate a problem or to solve it properly at 2 a.m. on a Friday? This has to be calculated by the metrics that we have already collected.

Kovid Batra: Makes sense. I have talked to a lot of EMs and engineering leaders through this podcast and outside of this also. But, what I have felt is that most of the time they have this challenge where they say that the metrics don’t tell us the reality. Ultimately, we’ll have to go back and talk to people. So, how your experience has been in that sense, like, is it just the metric or you have something more to tell?

William Mendes: I only think that when we’re working with those types of metrics who have the truth on this, have three sides. You have the metric side, you have the team side, and you have a personal side to each person that is related to that, to the composition of that metric.

So, being a people manager, you have to give and to have your one-on-ones to understand the team, to understand the situation. And, there’s something that I really like to use that is the happiness metric, which provides me the health of my team. So, I understand which problems are appearing. I can use this metric to anticipate problems, to understand if the cycle time that I am measuring is actually true, or if we are moving tasks on the board just because we have to move them, you know,? And, if people are happy, are feeling fulfilled by the project that we are investing, and if the failures that we think we are solving between the team and the product or between the team itself are actually being solved or are just being mitigated and hidden under the carpets, you know?

Kovid Batra: Makes sense, makes sense. So, this was one thing, like where the leaders and the managers had their own resistance towards not completely relying on metrics. And, very well said, like it has three sides. It has the metric itself, it has the team’s perspective, and then, your personal perspective on things. So, a combination of this would give you a realistic picture. But, again, when these metrics are being implemented, it’s not just the manager or the leader who is taking a call and adopting to this situation; it’s the team also that has to like buy in and then, they have to, like be a part of that whole procedure and process, right?

William Mendes: That’s right.

Kovid Batra: I’m sure you would have implemented it at your company or previous companies you’ve worked for. So, how was your experience there? Tell us about that experience. And, how easy or difficult it was with the teams when you brought that in?

William Mendes: Okay. Man, it’s always hard to implement a metric that the team doesn’t believe should be there. So, if your team, for example, works with different input sources, you have to want to help them understand how that metric will help them move forward. So, why would they help you measure the cycle time or the MTTR or the failure rate, if this is not helping them achieve anything else? Are those metrics related to their improvement on the company? Do you have something to help tell the story on why that metric is being implemented? I really like that book from Simon Sinek, ‘The Golden Circle’, when you start thinking about the reason why you’re doing stuff before doing it.

Kovid Batra: Yeah.

William Mendes: So, if I try to implement something on my team, the first thing that I have to understand, imagine that I join a new team. And, first I have to understand how this team is doing, what are the dynamics that we have and where this team is failing. As soon as we have that, I try to have a retrospective or a session to build trust and to have the teams telling me which metric we should implement first, where are our first pains and how that metric will help us achieve something better in the future.

Kovid Batra: Definitely. I’ll just like to add on here. What I have seen is people take it, like the team members take it in a negative way also. Like, they think that we are monitoring and measuring when we are doing that. That perspective, you can’t just change suddenly. It has to be a cultural aspect of the team, probably where people feel that they are psychologically, they’re safe, basically. Psychological safety is an aspect where people are open to such things. They know that even if a metric or DORA metrics are being implemented, we are not being put out and in front, and everything is evaluated based on that. So, that kind of psychological safety has to be brought in through the leadership from the company culture. And, I think that in combination to what you said, like giving a purpose and giving that psychological safety together to the team might really bring in an easy implementation, at least in terms of adoption from the team perspective, I can say, that it would work out well. So, yeah.

William Mendes: That’s exactly it.

Kovid Batra: Yeah. Yeah.

William Mendes: And, it goes also with the purpose of the team. If the team doesn’t understand its purpose, how they are being better, or how they are helping the company, there are no metrics that will help them.

Kovid Batra: Right. Right. Makes sense. Perfect. All right. I think this was really interesting. One more thing you just touched upon is about the happiness metrics, and there is a new wave of developer experience, developer well-being also we can see coming in. So, how exactly do you take care of the developers, how you take care of their well-being in the team? Can you just deep dive into it and just give us a few examples, so that a few people can understand from here that, okay, these are some things that we need to implement?

William Mendes: Of course. So, it’s very interesting to start by measuring and understand the impact that you have on the team or on the person that you have working with you on the team by the amount of work that that person is doing. So, the happiness of a guy or a girl working in the team, it’s completely related to the amount of work that this person is requesting. So, for example, you may not know that you have a silo on your team, unless you start seeing that all merge requests related to a specific topic doesn’t go forward without the intervention of this specific person. And, this is not healthy, neither okay for the company, neither for that person.

Kovid Batra: Right.

William Mendes: By talking with that, we can understand and explore if this is a common and same problem. And, by measuring it, you can start measuring other stuff related to that. So, the amount of merge requests that are being stopped and taking longer to be reviewed, the amount of service requests that you have going to a single person, the amount of work that a specific person is needed, and how happy is that person with those specific topics.

Kovid Batra: This is a very good example. I think, how the flow of a developer work looks like, whether it is easy or not, I think that’s where it relates to. So, perfect. Cool.

Any other example you would like to share?

William Mendes: Of course. There’s one which is the relation that I think is very hard to have on those areas where you have multiple inputs; that is the link between services, so you can understand the difference between the productivity and the impact that the person, that the people on your team have on different areas. So, sometimes we are asking for people to work with cycle time and number of changes when they are actually providing prevention of issues from happening by giving us documents and by giving us guides and by having meetings with other people. So, understanding the metrics and how they link to each specific person and each specific needs of the team would be the perfect way to go in there.

Kovid Batra: Yeah. Yeah. Totally makes sense. Cool. Cool, William. I think this was really, really interesting. Most of the things that you have said look very promising and I would say, for a lot of teams, ideal to do. But, as you are doing it right now, do you still see some scope of improvement? Like, maybe more visibility on what’s going on in the team in terms of the inefficiencies or bottlenecks that you would want to have or something like where you would want to identify those areas where you can improve by adding more metrics, maybe, or maybe some processes or tools. Just if there is any progressive thought there?

William Mendes: This, having all those different, different metrics is very hard for us because we do not have, or it’s difficult to have it on a single tool. It’s difficult to use for the vast majority of us. We are using a specific tool to manage our daily work. So, we have boards on the tool. We have tasks going on that tool. And, actually, we cannot relate everything from different projects on that specific tool, neither use it to measure how the team is behaving without having third parties.

So, what I would say is going for a tool that could help me understand the health of my team and the work that has been done by this team would be the starting point to change the lives of the people that are working with me.

Kovid Batra: Makes sense. Makes sense. Cool. I think there are multiple tools like that in the market and these solutions are also improving and one should go out and look for those, but it’s a very good thought, like bringing everything into one place and bringing that holistic visibility would be really, really helpful.

Cool. I think this was a very interesting conversation. I would love to deep dive more on a lot of aspects, but in the interest of time, I think I’ll have to just stop here and I would ask you to give us some parting advice for the audience, like any success mantra that you would like to share from your life, from your work.

William Mendes: Yes. Always seek for feedback. The hardest ones that you will hear will be the ones that will make you go further and evolve the most. So, don’t be afraid to talk with your team. Don’t be afraid to talk with your colleagues. Don’t be afraid to talk with your bosses or the boss of your bosses. And, to understand how and what they think about you and how they think you should improve to keep working with them.

Kovid Batra: That’s a very good advice, I must say. Perfect, William. I think it was really nice meeting you, talking to you. Would love to have you again on one of our shows again.

William Mendes: It’s a pleasure. Come for me if you need anything.

Kovid Batra: Sure. All right, William. Have a nice day ahead. See you.

William Mendes: You too. Bye-bye.

Kovid Batra: Bye.

'From To-dos to Kanbans to Scrums’ with Harijs Deksnis, Director of Engineering at Giraffe360

In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Harijs Deksnis, Director of Engineering at Giraffe360, with a rich background in organizations such as Passionate People, Philips, and more. He engages in a compelling discussion focused on the theme of moving ‘From To-dos to Kanbans to Scrums'.

The podcast starts with a fireside chat with Harijs, providing us with a glimpse into his personal journey. As the conversation progresses, he takes a deeper dive into navigating the scale-up journey and effectively dealing with high-performers during the scaling process. Further, he sheds light on the importance of 1-on-1 meetings and psychological strategies to manage team members. Harijs also imparts valuable wisdom on managing technical debt during the 0 to 1 and 1 to 10 stages.

Wrapping up, Harijs explains ways to identify burnout and emphasizes key priorities in establishing team goals.


  • (0:06): Harijs’s background
  • (0:48): Fireside chat
  • (6:46): How to navigate a scale-up journey, overseeing the shift from a small room to a 60-member dev team?
  • (9:40): How to deal with high-performers during the scaling process?
  • (13:36): How to manage technical debt during the 0 to 1 and 1 to 10 stages? 
  • (18:16): How to measure engineering success while prioritizing developer well-being?
  • (20:25): How to identify developer burnout?
  • (24:55): How to quickly gauge the team's progress day-to-day or weekly without proper frameworks?
  • (27:17): What things should be prioritized while setting team goals?

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a really passionate and a growth-oriented engineering leader as a guest. He has 10+ years of experience in engineering leadership and management. He’s currently serving as a Director of Engineering at Giraffe360, and you can find him next at the DEVWorld Conference on 29th of February in Amsterdam, talking about the team design.

Pleasure to have you here, Harijs. Welcome to the show.

Harijs Deksnis: Hi, Kovid! Awesome. Yeah. Thank you for having me. Pleasure to be here.

Kovid Batra: Great! So, Harijs, before we start and deep dive into your experiences, challenges that you have seen while scaling startups, I think there is something that I want to know more about you. The audience wants to know more about you.

We have this quick fireside chat where we’ll be asking you some personal questions outside of work so that we know you better. Are you ready for that?

Harijs Deksnis: Yeah, of course.

Kovid Batra: All right, let’s get started. My first question. How do you unwind your day? What are your hobbies, passion outside of tech?

Harijs Deksnis: Yeah, I try to unwind by watching or listening something of my interest, sometimes reading. I do like chess a lot. Sometimes I watch some videos, do certain type of literature, but it can change and, there was a period was very eager into learning different languages, so I used to just listen to audio books in different languages. But yeah, that’s, it goes like in phases, some, some months you have more passion in one direction, and then it changes.

Kovid Batra: So, what are you reading these days? Like, is there anything going on?

Harijs Deksnis: Well, at the moment I currently have a phase I’m actually pretty interested in Vedic literature. So, I’ve been looking into Vedas more. Actually just recently read through Rig Veda. So, that’s sort of my current interest.

Kovid Batra: That’s nice. Being an Indian, I haven’t read that yet. And, I think that’s amazing to know that you are reading it. Any specific things that you came across while reading the Vedas?

Harijs Deksnis: Well, it’s, it’s, it’s a collection, a huge collection of different hymns and it’s very poetic language. You don’t really read it as a prose, but there’s something behind the words that you just feel it, that it’s quite inspiring. So the very process of reading itself is a very uplifting experience.

Kovid Batra: That’s nice. Amazing. That’s a very, very different choice, actually.

Harijs Deksnis: Well, it serves well as unwinding after a long day of work and meetings and a lot of information handling. So, you read it not for the sake of, you know, comprehending information and perceiving every word, but you just read it for the feeling, for the switch of context and, uh, before bed, it’s, yeah, it’s very blissful.

Kovid Batra: I see. Well, that’s, that’s interesting.

Moving on to our next question. Well, we all are techies, so I just can’t skip this question. I just want to know, like, how was your first encounter with technology, with computers?

Harijs Deksnis: Yeah. Well, if we talk about desktop computer, I think my father brought one home in around ’96 from his office, so, I believe, of course, it was Windows 95, and yeah, we just spent the evening playing with Paint and Microsoft Word Clipart and Minesweeper. Uh, so that was the very first computer.

Kovid Batra: So, is that the time when you really fell in love with computers? Or it was just a thing you had at that time?

Harijs Deksnis: That was an insufficient experience to fall in love with. I was always passionate about technology, you know, playing the NES video game console, that sort of things. But I really, I gravitated towards computers when we got the first computer at home. It  was like a year or two later, and then I just loved going through all the settings in the control panel and just figuring everything out. I’ll start making my first website by saving a word document as HTML files. And, you know, there were links to other pages. So, it’s super static, made in word, but yeah, that was my first attempt to make a website.

And then I thought, “Oh yeah, this is something I really enjoy doing.” Creating these experiences and links, you know, hyperlinks, jumping to one content to another.

Kovid Batra: Nice, nice. All right. That’s amazing. Moving on to the next thing. I think this is very important for all the audience to know, and I am being very curious here. I asked this to almost all the guests, what’s their success for mantra in life.

Harijs Deksnis: Yeah. Yeah. I resonate with the saying “I didn’t come this far to only come this far.” I really like that one. It’s acknowledging that there’s always a next mountain to be conquered after you’ve done something. And yeah, to never give up, stay persistent, and never settle.

Kovid Batra: Yeah, I think that that is coming from that growth mindset that you have, like, the challenges that you see. You find climbing mountains and it’s like seeing what’s on top of that. So, it’s always good to be, like exploring things and knowing things and then finding challenges to overcome them. So yeah, perfect. Perfect.

But still, there is one thing that I would want to know, what do you think that makes you go in this direction? What is that realization that pushes you to be a growth mindset person? Because it definitely takes a toll, right? It’s not like very straightforward that you say that, okay, every time I just want to do something. It has to be some inspiration from within to do this.

Harijs Deksnis: Guess curiosity plays a big role. And just yeah, letting go of the past, yeah, shackles of the past, so to say, even though, even though, yeah, it’s maybe past achievements, but you want to sort of step beyond that. You don’t want to stay on that level forever.

Kovid Batra: Nice. I think that’s a very interesting point. I think curiosity always helps you move in that direction. What I have felt is something which is related to, I should not say survival, but a peaceful survival is what pushes, at least me, even I believe, and I feel that I have that growth mindset that this peaceful survival, if you want to have in this world, you have to be growing all the time. And, it’s not just, like career in all the aspects of life. So, yeah, just sharing my thought here.

Harijs Deksnis: That’s the way of nature, right? Sometimes you have something to run, stay just where you are. It’s like the Red Queen and Alice in Wonderland. Isn’t it, right? You have to run as fast as you can, just stay where you are. That’s the evolution, pushes us all forward.

Kovid Batra: Perfect. All right. That’s some interesting talk. Well, moving to the main section now where we would love to know how you have progressed through your engineering career, what challenges you have seen. So, starting with the first thing, like, tell us something about your experience where you have seen that scale-up journey, you have seen the transition from a room to a 60-member dev team, moving from to-do lists to Kanbans, to scrums, right? And, this whole thing, what role you played as a tech team member, as a tech leader here?

Harijs Deksnis: Yeah, well, if we’re talking about experience with Giraffe360, initially I came on board, building upon my front-end developer experience in the past year. So, I joined to start basically a new front end project, a new dashboard. And, started working closely with the team. But, it became quite quickly apparent that you would need a bit of better way of organizing. So, we started scrum in one team, a bit of more structure around planning things. Also started, you know, demos. And then we quickly, got quite productive compared to the rest of the company and the team and, you know, backend became sort of a bottleneck. Then I joined that team and started the process there. Then it went to another team, which was more handling the platform side of things. So, it went a bit of like, yeah, like avalanche ball. So, just get getting momentum and pulling other teams with interest in the same process. And meanwhile, there was the Series A financing round had finished, so there were funds to really grow the team. We also embraced the outsource model with team augmentation. So, just bolstering our capacity with some outsource members in New York, which basically they basically worked as in-house employees, just joining the teams and yeah, that really forced us to grow further, create more structured organization.

That of course, was challenging, put a strain on communication. Some all-time members were struggling, of course, with the change because they get, you know, they were used to certain type of environment, culture. As often in smaller or earlier stage startups, you see ‘hero culture’ forming like a lot of things happen because of some few, but very capable key individuals who do a lot, who can do a lot. But also, as you grow further, as you need to organize better, communicate more scalably and sort of try to get rid of bottlenecks or, you know, ‘bus factors’, that people can just safely leave on vacation and things don’t stop, and delegation can happen. Yeah, those people tend to struggle because, they get used to a certain way of working that also, of course, combines with a bit of feeling of their status or achievement or importance. So yeah, that is an issue that can be challenging.

Kovid Batra: That you have faced during this journey, yeah. So, let’s say, these kind of people who are there in the team, at times these people, you know, inspire other people to, like come up, step up. But at the same time, as you said that it is a double-edged sword, these people then become an issue in the team also. So, how do you create that balance? How do you handle such people who are actually very good for the team in terms of the efficiency, or if I have to use this word ‘productivity’, but, how do you handle these people? As you said, like you face them as an issue also over a period of time and the teams are scaling. So, how do you handle that?

Harijs Deksnis: Yeah. Well, I think as you grow, it’s really vital if you haven’t been doing before, start doing regular 1-on-1s. That’s one of the best ways, best windows to actually see the state of your team apart from, yeah, you know, surface metrics, that sort of thing. And, yeah, try to guide them through this transition, explaining what, you know, the phases we’re going in, what kind of role is, and what kind of benefits there are from being able to let go, being able to delegate and being able to instead of being in the center of things, with being the one who documents things well, sets things up for automation, oversees the process that happens well, and yeah, that they can leave on safely on vacation and, and, you know, just turn, turn their phone off for two weeks or whatever.

Kovid Batra: Yeah. Cool. So, I think most of the people who are in that category, would definitely come on a 1-on-1, listen to you. I feel that maybe 10% or max 20% of those people would actually have that feeling of changing themselves after those discussions. So, these 10-20% people probably who would change after these discussions or 1-on-1s, what do you think really clicked with them that you explain, or the other leaders in the team explain that hit them hard to change their behavior from being that bossy nature to being more cooperative, more understanding and leading with the team, not just leading the team the way they are thinking. So, do you think there is any specific thing that actually click with those people?

Harijs Deksnis: Hmm. That’s a very good question. I think that ties into psychology, and the other can, can be very diverse, depending on the nature of the person. But, the underlying factors are that the company, of course, is evolving and changing and growing, and unless a catastrophe happens, it won’t, you know, go back to earlier stages. And, this is just a new sort of new status quo, and everyone just needs to come to terms with it in a as healthy manner as possible. Acknowledge that, yeah, if some expectations are not being met or somebody is still attached to older ways of working or still have that sense of urgency that used to be there in earlier days that, you know the pivots, pivoting happened more often that every client request was super urgent and important because yeah, there were only a few clients.

But yeah, realization used to come, those days are gone. So, and we are, we need to, operate a bit more at  thinking more about long-term, about just having things operate sustainably and without too much upheavals and chaos, or stress that we need to think about developer burnout. That’s also, of course, a big thing.

Kovid Batra: So basically, what you’re saying is it’s a collective effect of a lot of factors that could help them change their nature, right? It’s not probably just one thing that pushes them to.. Yeah, I get it.

Harijs Deksnis: It’s not a conversation that convinces them, like you know, solid argumentation because arguments don’t always work, you know, especially in psychology. A lot of things just based are on our feelings and arguments cannot always penetrate that.

Kovid Batra: Definitely. Makes sense. Makes sense. I think let’s, let’s move on to the next thing that I would love to hear.

So, when you’re scaling, right? Initial stages, as you said, you have less clients, you have to, like move really, really, really fast, right? You really end up building, some fixes, and ultimately, two years down the line, when probably you have that Series A and you are becoming stable, you realize you have created a lot of technical debt, right? It happens. It happens to everyone, probably. How consciously were you taking those decisions in those first two years or one year of the journey? And then, how in the retrospect, you thought it could have been done even better. Just tell us about that experience of handling the technical debt when you are in the 0 to 1, and the 1 to 10 stage.

Harijs Deksnis: Yeah. Yeah. That’s, that’s an inevitable consequence. Yeah, technical debt persists throughout our industry, especially when you move fast and in early stages every client request is almost like a, you know, a push for pivot because you’re still finding that product-market fit and every client feedback is vital for you. So, you often, you know find yourself changing slightly or a bit more direction quite, quite often just to cater to that client needs to, you know, so they stay on board and often they are a good signal for other clients, what would make them to join your, you know, client base. So, that Inevitably leads to creating a tech debt.

In my philosophy, I think ideal way to handle tech debt is to, you know, acknowledge that it exists, and to factor it, factor solving it in future feature development. So, don’t just say, “Okay, we’re going to, you know, take two next sprints, just handling tech debt.” That usually doesn’t sit well with business and product because you know, they always want to see some sort of incremental progress. However, you can sort of balance those both needs by saying, okay, yeah, we’re going to work on this feature, but as we work on this feature, we’re also gonna solve the technical debt that this feature touches, so we can, be in a better state. Yeah, this feature will take more time. Maybe we’ll take, yeah, three sprints instead of one, but doing so, we will both deliver that feature for you, and we’ll have sorted out some X amount of technical debt. That I think is the best way.

However, in practice, of course, yeah, it doesn’t always go that nice. And sometimes, yeah, we have had that, we operate with set cadence. So, this quarterly cycle of our feature development and then a release event announcing it to the clients and the public, and, you know, then the sales and marketing can build upon that. And, you know, there’s another cycle of three months. So, we also had that some team was very pushing forward just to get some features out. So, you know, we could have some relief on the other parts of the company where, you know, where that feature helped a lot of, you know, automation, and reduced a lot of manual processes internally.

So, we just, you know, pushed on to get it out of the door. And, the next quarter we said, “Okay. Yeah, this team now has done a lot. They really rushed. Okay, this quarter, they will be more quiet on the new feature development. They will solve the technical debt part, so that in the future they can go faster again.” That has also ended up happening. And, I think it’s fine at the end of the day.

Kovid Batra: Makes sense. Definitely.

Harijs Deksnis: The first version of what I explained, I think it’s more wholesome, more healthier, better if it’s possible to pull off.

Kovid Batra: All right. So, I think it’s more about being conscious to not just completely, you should not just completely ignore that aspect because anyway, you’re going to carry some technical debt. You can’t just solve it and build perfect software at day one, but you can definitely be conscious about it, be considerate of the overall business scenario, situation, and then take a call that “Okay. This is the percentage of technical debt that we are going to cater to.” Of course, you cannot, like quantify it completely, but still there can be some level of focus given to catering to technical debt while building the features also, right?

Harijs Deksnis: Yeah.

Kovid Batra: Makes sense. Perfect. I think with all this going on, I think what becomes most important is that there should be alignment in the team. Like, without the team alignment, having that hyper growth in the 0 to 1 phase, or 1 to 10 phase is very difficult. So, when you lead teams, you have to have the same success criteria for them, or maybe some specific success criteria for them to align with the business goal so that the business is achieving what it wants to.

But, when it comes to engineering teams, I would like to know it from you. How do you define engineering success? How do you measure it? And, while all this is going on, I feel that a very important part which you just mentioned that we should take care of the developer burnout with the factor of taking care of the developer well-being also comes in. So defining success for engineering team, measuring it and looking after the developer experience, developer well-being, how do you do that in a startup in this stage where you need hyper growth?

Harijs Deksnis: Yeah. We actually are still finding our way with the, when it comes to, like metrics and that sort of thing, because it of course, it takes also a bit of time to collect them and to, you know, to make sure they’re consistent across time so that they can actually be based upon to, to make some decisions. So, we still operate often more of a sense or common sense when it comes down to that. But, yeah, I think I’m also converging on the opinion as I think the most of the industry, the DORA metrics at the team level are quite reliable signals of how well the team is doing. So, you know, the four metrics in there, to deal with them with stability, and deal with velocity. So velocity, I believe, is the ‘lead time for changes’, and the ‘deployment frequency’. That is how fast you’re going. So, the faster you’re going probably is better, it means you can, you can react faster.

And, another two, what was this? ‘Change failure rate’ and ‘recovery time’ is stability. So, how stable you are, how often you are introducing a change that needs to be rolled back. Or if you do that, how long it takes for you to recover. And, if those are low, it means you’re quite, quite stable. And if you’re going fast, if those all four metrics are good, it means you’re going as fast as you can and you’re still doing it in a stable and reliable manner. I mean, then you’re doing great.

Kovid Batra: Yeah.

Harijs Deksnis: And when it comes to yeah, developers, well, of course, a big red flag is if you, if you happen to have too high employee turnover, or you see burnouts happening too often. That is a big, big thing.

Kovid Batra: How do you identify a burnout? Like, if somebody is in that zone, how do you do that?

Harijs Deksnis: Yeah, I think 1-on-1s, both with your team lead and then sort of the team leads with their team members. I think that is very, very important to catch these signals early. I know when it happens first time in career, when you encounter a burnout, it’s actually a lot of people don’t notice that it sneaks up. Also when I, in the past I had my first one, yeah, it just snuck up on me and then it was too late.

Kovid Batra: Sorry to interrupt you here, but, I would love the audience who might be feeling the same, should know that it’s okay to feel that way. And, it’s okay to come up and talk to your managers or leaders to actually resolve this problem. Because I think in that situation, I personally have been in that zone. So, I would love to know, like, what does it feel like and what did you do about it when you went into that burnout zone?

Harijs Deksnis: Yeah. It’s a difficult state because once you’re in it, you cannot reason out of it. And it’s not like a weekend recovery to get out of it. It usually takes months. So it, it’s a serious state. I still see it as a long-term accumulation of stress that was not properly dealt with.

I think a long time ago, I, I saw some psychology lecture. Well, I’m gonna use, well, a glass, if you hold a glass like this, it’s, it’s pretty lightweight. You can hold it like this. But, if you hold it like this for, I don’t know, two minutes, it gets a bit heavy. Hold it for five minutes, it’s quite heavy. So, I don’t know, maybe you can make it to 10 minutes or even 25 if you’re resistant, but at some point you’ll, even though it’s super light, it’s going to hurt a lot in your arm. It’s going to be a lot of pain. And yeah, you won’t be able to do much with that arm for a long time. Well, not long, but you know, significant time enough. And, that just shows that even a small amount of load, if carried for too long time without letting go, you know, for, you know, having rest moments in between can result in a huge strain, and, basically loss of capacity for a while. So yeah, that’s the analogy there. And first time, yeah, it just sneaks up on you because, I just have been doing a lot and not letting go, often thinking about problems, you know, in evenings and weekends, maybe there’s some sort of personal trouble as well at home, family relationship, that adds to the load. And yeah, one day you realize, wow, you don’t have energy to be creative, to want something, to think something you just want to, yeah, you just want to, I don’t know, you don’t want anything. And that’s a very sad situation.

Kovid Batra: Right, exactly. I mean, there have been scenarios. I think, this is from my personal experience, where personally, everything was fine. I’m happy home, having a good time with my wife, my parents, but when it comes to particularly work, it seemed like the way it is there always, right? So, I mean, as you said, like it could be something going on personally, and then at work-wise, and then you’re overloaded. I mean, I have felt that I was happy at home, but not feeling the same when it came to work. And, of course, reasons are different for everyone. But, burnout could be just related to your work where you are not getting what you need from that environment. So yeah, I think good we touched on this point. I think the audience would be becoming more aware of this situation, scenario and probably have more courage to deal with these kinds of situations.

All right, coming back, uh, like to the engineering metrics and the success of an engineering team. So, you mentioned about the DORA metrics, right? Right now in your team, you said you don’t go by the metrics or you don’t go by these things. You just go by your gut feeling and the overall..

Harijs Deksnis: We pay attention to those, but yeah, we don’t have actually, like system set up, that, you know, that measures and tracks across time. We sort of look at it back and look up data when we need it and sort of have a good sense where we are, but we have some way to go there to have it more, you know, reliable and consistent.

Kovid Batra: That’s absolutely fine. Yeah, I think it’s not, like very common yet that everyone is using those metrics or tools around those to actually understand what’s going on in the teams, but they do have this sense of what’s going on in the team.

So, my interest is to know, like if you don’t have these proper frameworks in place, let’s say, what exactly on day-to-day basis or weekly or monthly basis you look at to ensure, “Okay, things are going fine.” Like, I would just want you to, like reflect on that one month of maybe two sprints or one sprint, however you follow it. How does it look like? How do you ensure that things are going fine?

Harijs Deksnis: Yeah, well, there are a couple of signals. I think it tells, everyone, even laymen, that things are doing well. So, your team is energetic, right? They feel they’re winning. They like the challenge they’re solving and they’re solving it in a reliable time. We are building features or product, that our clients like and they use, and of course there’s feedback. And, if there is negative feedback, we react to it fast and we don’t introduce too many bugs. That, you know, that keep us bug fixing for, you know, a disproportionate amount of time. And, there’s a lack of frequent incidents. Of course, you know, incidents can happen, that’s normal. But yeah, if you, if they end up happening weekly, depending on the system, of course, then something is wrong.

Kovid Batra: Yeah. Makes sense. I think, even if you’re not following certain framework, I think the signals that you’re looking at ultimately point towards the important things that you should be looking at. I think that really helps you going. Probably when the teams are really big, you would have to have a proper process, a framework in place when you have objectivity on what’s going on each metric. But right now, probably with a 50-60 team size also, you’re able to manage seeing what’s going on. If the bugs are increasing, is the team motivated or not? And then this is really amazing point that the first point you said, “Is the team energetic and motivated or not?” I think that covers the 80% of what is actually expected to be there, as a developer experience, as a team experience that everyone should be motivated and energetic. Taking feedback, doing less number of bugs, doing more, delivering fast, I think always happens on top of it if the core is aligned and motivated.

So yeah, I think that’s perfect, Harijs. It’s really nice, knowing that you are taking care of your team, not just work-wise, but in general, how they are feeling. So that’s, that’s really nice.

So, I think, this was my last question that I just wanted to ask in the interest of time. I’ll just ask one more question. I mean, you told about how these metrics work out for you and how do you handle that. One thing that I want to understand from you is when you set goals for your team, particularly, right? How do you exactly do that? Is it just some engineering achievements that you have to have at the end of the month or at the end of the sprint, or are you linking it to some product or business metrics also?

Harijs Deksnis: We are mostly guided by product features or quarterly goals the business and product wants to see. And then it comes in a form of a new feature, new functionality being delivered to the customers. We track it at the quarterly level. At the sprint level, we do have a lot of freedom for the team leads to decide on the pace or the priorities. They sometimes can and do decide they have to tackle a bit of technical debt, so they can move faster to the goal in the next sprint.

Yeah. The quarter and product feature delivery is just sort of our milestone cadence.

Kovid Batra: It makes sense. I think just keeping things tied to the engineering achievements would not be appropriate because at the end of the day, product and engineering works together to deliver the features, to deliver the product. So ultimately, the goal is to make the customer happy and deliver as much as possible for the customer. So, aligning that, the engineering team with that is really, really important.

Perfect. All right, Harijs. I think it was a really nice conversation. It was a pleasure having you. Thanks a lot.

Harijs Deksnis: Likewise. Yeah. Thank you for having me. It was a great conversation. Have a great day.

Kovid Batra: You too, Harijs.


'Impact vs. Velocity’ with Stephan Schmidt, CTO Coach at Amazing CTO

In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Stephan Schmidt, CTO Coach at Amazing CTO. His vast experience includes valuable contributions to renowned companies such as brands4friends by eBay Inc., ImmobilienScout24, and 7Mind GmbH. The discussion centers on ‘Impact vs. Velocity’.

The podcast begins with a fun fireside chat with Stephan, allowing the audience to see his candid side. Later in the main section, He explores the challenges CTOs face in large-scale companies. He also provides insights into steering the team towards impact over velocity as well as navigating the challenges of balancing fast-paced growth with handling technical debt during hypergrowth cycles.

Stephan concludes by discussing what separates a leader from a manager, along with measuring success for engineering teams.


  • (0:06): Stephan’s background 
  • (0:53): Fireside chat  
  • (4:19): What are the significant challenges faced by CTOs in large-scale companies? 
  • (6:24): Why CTOs find it challenging to align tech strategy with business strategy? 
  • (9:02): How to guide your developers to prioritize impact over velocity; when they may not be closely connected with the business side?
  • (17:01): How to balance fast growth with managing technical debt during hypergrowth cycles?
  • (22:24): When is the optimal time for a manager to transition to an engineering leadership role? 
  • (28:23): How to define success for your engineering team? 
  • (32:52): How to ensure performance expectations for your team? 

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, back with another episode of Beyond the Code by Typo. Today with us we have an interesting, amazing guest who is super knowledgeable, 30+ years of engineering and leadership experience. He’s an ex-CTO of an eBay company. He’s been the founder of a startup. He’s currently working as a CTO coach with Amazing CTOs. And, the most amazing thing about him is his humbleness. Welcome to the show, Stephan. Great to have you here.

Stephan Schmidt: Hello, Kovid. Thanks for having me.

Kovid Batra: Pleasure. Pleasure. All right, Stephan. So, before we jump into your experiences and knowing what all wonders you did in your career, we would love to know more about you, outside of tech maybe, so that our audience gets familiar with what kind of person you are.

Are you ready for a quick fireside chat with us?

Stephan Schmidt: Yeah, sure.

Kovid Batra: Perfect. Perfect. First question is very simple. Are you a beach person or a mountain person?

Stephan Schmidt: Oh, I enjoy both. I grew up in the mountains, but, some years ago, I moved to the sea, so I like both. But, if I needed to decide, probably the beach.

Kovid Batra: And in one word, tell me, what do you feel when you’re at the beach?

Stephan Schmidt: I’m amazed by the sea. I feel amazed. I feel..

Kovid Batra: Perfect. All right. Next question. It’s been 30 years of experience, but you have to go back, you know, memory lane down to the point where you had your first coding experience. Tell us about it.

Stephan Schmidt: My first coding experience, like for so many was as a kid. I played video games at the end of the 70s and I thought, “Well, I could do that too. I want to do that too. I want to write video games.” So, I went to a department store. There were other kids who did some programming on the computers in the department store. I watched them doing their stuff, learnt from them, imitated them, and that’s how I got into coding. And, since then, I’m a coder and what I love about coding is essentially creating something from nothing. Like, there is a blank screen and then you can do the thing, the computer, whatever you want it to do. It’s like you create something out of nothingness. And, that’s still something that I really, really find amazing.

Kovid Batra: So, for all the parents out there, video games are not that bad.

Stephan Schmidt: No!

Kovid Batra: All right. All right. Moving on to the next question. I think this is very close to me also. What would you choose? Like, what do you prefer, being a founder or being a CTO at a company of eBay? What journey was more fulfilling? I feel both of them are very good, but what’s your piece of cake?

Stephan Schmidt: I think the nice thing about eBay, and I was also working at a large company in Germany, which is called, ImmobilienScout24, which is a real estate website, the largest real estate website, I think in Europe. And, what’s nice about working in a large company is that you feel some impact. It’s large, people know the company. So you see people who use your product in everyday life. So, you can go around somewhere and say, “I work for eBay.” And then everyone says, “Yeah, I know eBay. I use them.” Or ImmobilienScout24. “Yeah, I’ve used ImmobilienScout24.” So, everyone knows it. So that’s, I think it’s a nice thing of working in a large company. And also, you have a lot of money around and you can do a lot of things because you have a large budget and all of this stuff.

Being a founder of a startup enables you then, but enables you to better, I think, follow your ideas and your vision. Because in a large company, you might be constrained by the company and by the company strategy. And so there’s limits on what you can do in technology. As a founder in a startup, there is no limit, on what you can… have legal limits, but there is essentially no limit on what you can do. So in doubt, I’d go the founder route. But I learned a lot in large companies and I enjoyed my time there.

Kovid Batra: Perfect. Thanks for answering that. All right. I think that was an amazing quick fireside chat with you. Now, we would love to move to the main section where we get to know all the wonders that you have done in your career. And I would simply start with something that you have been doing right now at amazing CTOs while coaching the CTOs.

What do you think are the biggest challenges CTOs face in companies like eBay, which are obviously at that scale? What do you think, on day-to-day in their responsibilities, in their role. What are those challenges that you see these CTOs facing?

Stephan Schmidt: I think the challenges one of the challenges that a lot of CTOs are facing and, and it gets more difficult the larger the company, I think, it’s aligning strategy with business strategy. I think that a lot of challenges arise in software engineering when the business strategy and the business vision is not aligned with the tech strategy and the tech vision. And, I think it’s paramount for the CTO in a company. And it’s more, more important to bigger the company to align the tech vision and the tech strategy towards the business and be supportive, because otherwise you move in the wrong direction. If you are not aligned, you move in the wrong direction, you make the wrong architecture choices, the wrong technology choices. And then, there is a rude awakening at some time because there is too big of a rift between you and the business. So, I think it’s very important to be aligned on business vision, business strategy, and execute on them. And where do, where CTO struggle is, first, I think is bridging the gap, thinking from the business side, bridging the gap. And, the second thing is they usually don’t think there needs to be a tech vision, a tech strategy. They are too focused inside. They think it emerges by their actions and by their decisions about technology, but it’s not. So, they don’t have a strategy. They don’t have a clear strategy. They don’t have a clear vision for technology. And that creates a lot of rift and problems.

Kovid Batra: But, why do you think, like, I’ll ask a question, follow up question on that. Why do you think the CTOs really struggle with formulating this vision in their heads and then aligning a tech vision or a tech strategy for that? It may be these events arise, these problems arise, but at the core, what exactly doesn’t make them move towards this direction of building a good strategy? Is it the lack of understanding of the business needs? Because probably CTOs come from a tech background and they have more inclination towards coding and being individual contributor a lot of part of their lives. What exactly it is? Why do they miss out on this bus?

Stephan Schmidt: I think there are several things. And the first thing is, is really what you mentioned. I’ve had a lot, so the team, not me, but I, as someone who takes ownership not of the good results, but of the problem. I’ve had a lot of hard tech problems with my teams and but usually this was not something very high on the, on the agenda of the CEO. So, I did not get a lot of thanks for solving hard tech problems, but I always got positive, very positive feedback on my understanding of business and my trying to bridge the gap, trying to understand business, support business and stuff like that. That’s something that the CEO said, “Stephan, that’s, that’s good that you’re not a techie. I can talk to you. You talk in a way I can understand it  and you try to explain things.” And so, I think that’s, that’s very important. And, and CTOs don’t do that enough, I think. But that’s the role, that’s part of the role.

So yes, from that side, I think strategy is lacking. And on the other hand, I think a lot of CTOs think they don’t need a strategy or they don’t know what it would be to have a tech strategy, what it would look like. And they, they just go from decision to decision and say, okay, they have some kind of strategy, like, okay, we want to move to the cloud or want to move to the, to microservices or something. But they, it’s not embedded in a grand scheme, in a grand strategy and a grand vision, which is aligned to business. So they are, they have random kind of random strategy steps they are doing. Like, move to the cloud, move to microservices or move to mobile native apps or something. But these are kind of random strategy steps. And they think that’s enough, but I think it’s not enough. It needs to be a wholesome strategy, which gets you somewhere. And that somewhere is a vision where you want to be.

Kovid Batra: Definitely. I think that’s interesting. Thanks for highlighting that. All right. So, one more thing then last time when we were talking before this podcast, I remember you telling me that it’s not about doing more or it’s not about achieving high velocity, it’s always, always more about delivering more impact, right? So, as a CTO, when you step into that shoe, how do you exactly ensure that the impact is getting created? Because as a CTO, let’s say, you understand what would be the business impact. You at least have direct business counterparts to whom you are talking on day-to-day basis to understand what they need. But, what about the team who is not interacting, and is probably a little bit unaware or a lot unaware of what’s going on, on the business side? How do you make sure these people are more aligned towards delivering impact rather than focusing velocity?

Stephan Schmidt: I think developers, particularly developers want to work on impact instead of velocity. I think they want to do things that have impact, so it’s not about the tech team. I think it’s about two things. First, I think it’s about business, where I need to do a lot of explaining to get them into the impact mind frame, in the mindset and into an impact frame, because they often think we need to deliver more and see what sticks.

Whereas when I look at, I don’t know Tim Cook, but I imagine Tim Cook from Apple wants to have a blockbuster iPhone each year. And, he doesn’t care if the iPhone is one release, one month earlier or something, or two months earlier, that’s not the focus. The focus is to have a blockbuster release, iPhone release, sell hundreds of millions of them. And, business needs to get in that mindset and that’s a lot of effort because usually they are more in the, “We need to do a lot of things. We need to do a lot of things. Do things fast.” And stuff, instead of, “We do things that have impact.” So, that’s the point. And, their interaction with product or with someone who defines features or defines user stories, epics, or whatever you want to structure your software engineering around. I think the important thing there is they need to have impact metrics. You know, they need to, every story needs to have an impact metrics. What impact do you want to have? Like, it might be usage, minimal, might be usage, 50% of users are using this, but it might be more of an outcome, not only an output, but more of an outcome metric. And an impact metric, that’s very important, and to follow up on these. So, I see organizations who do not define impact metrics, they define revenue metrics, which is a very, very bad idea for various reasons. They, they don’t define impact metrics, but if they define them, they don’t follow up on them. So like, you do this. Okay, didn’t work. Next. And, you need to really follow up on metrics. That’s, I think it’s a challenge, like the interaction with the persons who are writing the stories or the epics. With the business side, that’s a story, about the strategy. I feel like developers really want to work on things that have impact, you know? And, they don’t want to create as many features as possible, from my perspective. They want to have work on things that have impact.

Kovid Batra: No, I believe that. I mean, I, I might be coming from a very narrow experience where I might not have encountered that. Thanks for an eye-opener there. Probably developers have that mindset that they want to create an impact. But, at the same time, I have one more doubt. And again, it could be something which is very specific to my experience with developers. I don’t see that tendency where they want to really get in touch with the customer, like getting in touch, not literally. Maybe a salesperson would be doing, or even a product or a user research person would be doing. But, taking that information from these business departments to understand what exactly the user feels like or getting into the shoes of the users, and then thinking of coding and developing, I feel that there is a resistance. Is that right or wrong?

Stephan Schmidt: Yes, I think that there is some resistance there for various reasons. One reason is essentially that developers are very fact-driven usually. And you know, the best fact wins, the truth wins. Let’s discuss this on facts. Whereas other departments are not that fact-based or not that detail-based. They are fact-based, but they are not that detail and analytics-based as developers are. So, some other departments want to talk about feelings and about emotions, about how we can do this and do that. And, and just glance over the details. They don’t want to talk about details. You know, they want to, marketing, sales, some other departments and customers. They talk about the big things perhaps, whereas the developers want to talk about the minor things and the details of things, they are interested in the small details of things, because in the end, they need to make it work, you know, and it breaks in the details. And there are some differences between cultures and between understanding. And, that sometimes makes it difficult for developers. And then this gets friction and that friction takes effort and, and is, you know, and it’s, it’s annoying. And out of that, I think, arises something that developers do not particularly want to discuss things. They say, “Tell me what I need to do.” You know, they’re often unhappy if some, if you tell them what to do, because they think it’s a bad idea or it’s not detailed enough, you know? So, on the one hand, they’re annoyed by if you tell them what to do. On the other hand, they say, “I don’t care. Tell me what to do.” So, there’s some, there’s some, “I want this, but I also want that.” kind of thing.

Kovid Batra: So, why I’m asking this question is because this is this whole loop. Like if I, as you said, like the developers would want to create an impact and they would want to develop something that creates an impact. It cannot happen if they don’t have the right information, if they are not contributing in terms of the discussions with the Product Manager, right?

Stephan Schmidt: Yes. Yes.

Kovid Batra: And, to actually first get involved there would make them innately accountable for what they are building, right? If you, again, if you just go tell them what to build, they would not be happy. They would not feel involved in the process, and ultimately, they would feel getting tied to the business metrics of the product metrics, the usage that you were particularly saying. So, I think it has to start probably from the point where the developers have to be put into a mind frame, as you said, they need to deliver a blockbuster product or a blockbuster feature. And to do that, they need to realize that they have to come out of that little bit of a shell and understand what’s there on the customer side. And then start getting involved in the development process with the product.

Stephan Schmidt: Yeah. Yeah. I sometimes, I sometimes shorten this to ‘developers need to become creators again.’ You know? My heroes in the 80s were people who wrote video games by themselves, or two people wrote a video game, city design, great video games like, Elite or Iridium, Paradroid. There are a lot of good video games written by only two people or one person. And there are also good, great software like Lotus 1-2-3, WordStar, VC card. But there, back then, developers were creators. You know, they created things. And today, a lot of developers are executioners. They execute things. They create things other people have thought of. They build for other people. And, what I want is that developers get back into the creator mindset and feel as creators, because that’s also something that brought me into development. So, this is something I try to tell developers is that they would be happier if they could get into creator mindset. And then sometimes, for example, if you send them off to a design thinking workshop and they get into design thinking and then they get involved in the product management, they are often happy then with being there and making the decisions, even if there is some resistance at first. But, a lot of them, not everyone, it’s not for everyone, but a lot of them are very happy getting back into the creator mindset and being a creator again, instead of just doing other people’s stuff.

Kovid Batra: Perfect. Yes. I think that’s, that’s what probably I was thinking. All right. I think this was interesting.

So, that was on delivering more impact, how you would actually drive. Now, there is one more thing that we feel that it has to come with alignment. When you’re leading with a strategy, then you have to, like create a balance between a fast-paced growth and also handling the technical debt. I mean, this is kind of inevitable and almost every engineering team has to go through this loop where they are under the hypergrowth cycle at some point and they create technical debt at that point. How exactly in your view should that be handled? What as an engineering leader or as an engineering manager, should you consider while taking on that call, whether to build it this way or that?

Stephan Schmidt: I have a, a simple, I don’t say I’m right. You know, I, it’s just my opinion. It’s just my experience. So, that’s my model that I have in my mind. I might be helpful, might not be helpful. But, how I see it is there are several phases and you need to act according to the phase in a startup.

And so, the first thing is for me, from a product perspective, startup product perspective is you build a prototype, you know? So, you go in, and you did a, we build a prototype where you can evaluate the idea, how it would look like in general. And, you can show around the prototype to investors, to employees, to people, to friends. That’s the prototype phase. And, you can do no code development. You can do whatever you like. You can do a click dummy. You can do PowerPoint slides. It’s not important. That’s the first phase. A prototype with a clear goal of getting people interested, evaluating the general idea, how would look like.

Then, you get into MVP and see what would the minimal product would look like that you could bring to market, you know? What’s the entry product? What’s the market entry product? You need to build the MVP. That’s the second phase for me.

Then, you have the third phase. And, the third phase is about finding product-market fit. So, you need to iterate and really work hard to find product-market fit. And, when you have product-market fit, you will feel it. Some of my coaches get into that mode and they feel it. Everything gets easier. People come to you, want to buy from you. So, this is product-market fit.

And, after product-market fit, last phase, last relevant phase, there are some others in the future, but last relevant phase is scaling, you know? So, you have prototype, MVP, PMF, and scaling. And, what I see about technical debt, what I see is, in the beginning, it’s okay to have technical debt. So, I would not care about technical debt in an MVP or until getting PMF, product-market fit. I would really, totally concentrate on these two things. And if I accrued technical debt, that would be fine with me, you know? I try to minimize it by having the right engineering culture in place, not doing stupid things, but overall, total focus, getting PMF, getting MVP, perhaps to get an investor, to get into the market and PMF to find traction. And then, I would think about tech debt and have a clear strategy to get off tech debt and remove it.

A lot of tech debt, essentially, I think is accrued because of two reasons. First reason is tech is not aligned to business. So, business moves here, tech moves here, and the ever widening gap is kind of a technical debt because it’s like, we can’t move there because we’re here and, you know? And, the other thing is that a lot of companies want tech engineers in startups, want to scale too early. And, they put things in it, and they add abstractions and they try to scale before they need to scale. And what happens is they get a lot of technical debt not in the form of bad code, but in the form of bad abstractions, you know?

Kovid Batra: Right. Makes sense.

Stephan Schmidt: And, I would, I would be cautious about, I, whenever they tell me how I need to prepare for scaling, I say, “No, why?” I mean, first, you can’t anticipate the future. So, probably we built the wrong things. So, always don’t do stupid things, like too easy stuff, have several servers and, you know, don’t do, I have some clients who have one server, don’t do that, you know? But, don’t scale too early because also on the other hand, you will find out things, at least I found out things when I was in hypergrowth startups, that things break that you did not think about, you know? The things that are breaking are things you’d not have thought about. So, I think it’s don’t do something stupid, but don’t try to scale too early.

Did that a little bit answer the question about technical debt?

Kovid Batra: Absolutely. I think it puts a lot of perspective in place. We are also going through that journey right now, and I totally understand you are trying to emphasize them. And, I think it’s a very good piece of advice because the need of the hour is to build, find that fit, not to build something perfect today, because for that we’ll have time. We just need to build something which is just good enough and serves the purpose. So..

Stephan Schmidt: It’s very, very difficult to achieve product-market fit, you know? A lot of companies fail there because they think they have it, but they haven’t. So, and I would not think about technical debt until I have traction.

Kovid Batra: Makes sense. Makes sense. Absolutely. Thank you so much for answering this.

With that, I would want to move on to something where I’m sure you would be coaching a lot of people on, where they transition from a manager to an engineering leadership position. I mean, the first transition is of course, from an IC to a manager, but then the journey from a manager to a leader, I would love to hear from you. What should be the reason behind it? When is the right point? The inspiration. Just tell me about what according to you is the right point for somebody to move from a management position to a leadership position.

Stephan Schmidt: I’m not so sure there is such a huge difference. And I also, I felt like I was always kind of a leader because of like in and I don’t want to be “Stephan knows everything and does everything right” and blah, blah. It’s not about that. But as a kid, running around in gangs, doing stupid things, 10-year-old kid, I always thought, like I was often the one telling people what to do, where to do, what to, what stupid things to do next, you know, or what intelligent things to do next. So, right from the beginning, I felt like, natural to me to standing in front and showing directions. And, I think that’s about leadership. And, the most important thing about being a leader is giving directions, you know? Like, “This is where we want to go to.” So you need to have a vision and you need to tell people we want to go there and remind people that you want to go there because a leader is someone who leads. And, you lead people by leading them somewhere. I mean, you can lead them in a circle, but you can’t lead people in a circle. So, you will lead people somewhere. So, a leader is someone who leads people somewhere. And to me, that’s having a vision and leading people towards the vision, which is kind of a goal in the future. And that’s leadership to me. Whereas manager is a lot of, about administrative stuff and taking care of people and being people manager and all of these things. The difference to being a leader is to me is having a vision and leading people, have a clear opinion where to go and lead people there because you believe that’s the right direction to go.

Kovid Batra: Makes sense. Makes sense. Perfect. I think, when we have that feeling, so what I would love to share what I feel that being a leader comes with something which is very core is being able to comprehend yourself, like explain yourself to others in the best way possible by being humble, not by being somebody who’s a hero or being alpha in the team. And most of the times we feel that. I mean, this is a quality that you have, I’m sure. I feel it. I just mentioned in the beginning also, I think this comes very obvious to you, but I think one of the things that I feel the leaders should have is the humbleness, the groundedness, and being one of those people with whom you’re working. It’s just a responsibility that you have taken up to give the direction to the team, but that doesn’t give you the power or the, the superiority in that plan, in that team. Yeah, so that’s something that people should be consciously aware of.

Stephan Schmidt: I think to me, as I said, crucial is leadership says, “This is what we’re going to do. This is where we want to go.” And that’s leadership to me. And it, it does not need to be that you’re standing on the table, shouting people, “Go there!” Or “Faster!” You know, it’s not, that’s not, you can be part of a crowd. And, that’s also something that I always had as a manager and leadership ideal, I was always part of the group. So, I was not standing on the sidelines. I tried not to stand on the sidelines and give directions. I was always trying to be part of the group. Like in this, I don’t know, like in the movie, you know, like being a leader, but being part like ‘The Glorious 7’ or something. Being part of a group, you can be a leader by being part of the group. It’s not something that you are directing the group around, you know? It’s not. That can always be a leadership. If this is your style and if it’s fine, then, but it was not mine. You know, leadership can be part of the group. I think you can be a leader without having a title, you know? There are a lot of great developers who are obviously the team leader, the team lead, but are not the team lead, you know, because they take ownership and, and if it works fine for everyone, then that would be also fine for me, you know? I don’t have to have the title to be a leader.

Kovid Batra: I think that thing would have a little bit of a problem in terms of people having that bias to follow what you’re saying and, and you need it at times. So I, I feel that you should be entitled in some way, like either it should come from the group itself that, “Okay, he is, or she is the best person to be there to take decisions for us.” Or the authority, or not exactly the authority, but the upper management or the existing leadership should define that, “Okay, this is the person whom you should be following now.”

And then, even if you become part of the clan and then work that way, it works pretty well. But yeah, I mean, everyone to its own but your thought is also correct.

Stephan Schmidt: Yeah, no, actually one, one minor thing I think is, is like, I didn’t go into the question why people should follow you, you know? You know, there can be various reasons why people should follow you and it can be because you’re the boss and you say so, but it can also be because people trust you, you know? People usually follow you, I’d say, if the vision you want to lead people towards is self-evident and great, and all the people say, “Yeah, that’s a goal in the future. I want to be there.” And people trust you that you will be the person leading them there, you know? If they don’t trust you, you can have the best vision, but if you don’t, if people don’t trust you to go get them there, you know? So, there can be very, very different reasons why people follow you, can be you, the boss or you, you know, but, or you have the title, whatever. But, it can also be because people trust you and you have to create a great vision where they want to be.

Kovid Batra: Sure. Absolutely. I think, one thing that comes to me is that when you move into that step and you want to be part of the clan and you want to be humble, it becomes difficult in one way is how you, like push people to move faster or let’s say, deliver more impact, measure their efficiency and then tell them, “Okay, this is where you’re working on.” How do you do that? How you have been doing that as a leader, defining success for an engineering team and then measuring it? And while doing all this, taking care of the team, their well-being, how do you exactly do that?

Stephan Schmidt: I think the first thing that a lot of CTOs are not doing, a lot of leaders are not doing is expressing their expectations. People have expectations of the team, of the company, of the individual, but they don’t, do not talk about them. And then, the person, the team, the organization fails because it does not succeed towards the expectations. But, the leader, manager, whoever has not spoken about those expectations. So, a big failure in organizations and in managers I see is that they do not talk about their expectations and then are unhappy because people do not follow their expectations, fulfill their expectations that they have not talked about, which is obviously, you can’t, I can’t, I can’t fulfill your expectation if you don’t talk about them. But, that’s what I see too often. So, the first thing, very, very, very first thing, if we talk about performance is talk about your performance expectations and talk about that performance is important to you and what performance means for you. How does performance look like? What is performant behavior? What is underperforming behavior? And, performance is important. So, what’s your expectations? How do you judge people? How do you judge performance? How do you evaluate things? That’s the first thing. Make it clear that performance is important or very important to you.

And again, little bit of a sideline, side quest, employees, developers hear so many things, so you need to repeat important stuff. If they have heard from you five times that performance is important, they will think, “Okay, it looks like performance is important to Stephan.” You know? But, if you tell them only once, they hear so many things, they need to judge by themselves, what’s important, what’s not. And, if you tell them only once they think, okay, that might not be the, you know? So, it needs to be clear expectation, performance is important. That’s a cornerstone of everything.

And then, add two things. The first thing is, is something like support the people, support the developers, you know? Give them what they want. Like I have this famous story. I got into trouble because everyone in my department got $300 headphones. But, it was too loud, people could not concentrate. So, everyone got a $300 or $350 headphone which got me in a lot of trouble because, like company did not understand why I was buying so many, like for 10,000s of Euros buying headphones. But, if this is what they, what you think they need, then do it. And, so I was very close of letting, I was, a lot of people were angry in top management. But, if you think that’s, that’s the thing that people need to deliver top performance, that’s what I said, you want, company wants top performance, pays a lot of money for these developers, and then I can’t give them a $350 headphone? Does not make sense, you know? So, give them what, what developers need, environment, tools. So, support them in every way you can to be performant. That would be the one way. That would be the one part.

And, the other part is hold them accountable for performance. So, if you expect performance and you have the feeling that someone is not performant enough and is underperformant, tell the person. And again, tell your expectations, describe what you see, what you think is happening and that you’re unhappy with this. And then, sometimes, more often than not, you’re wrong, you know? I was wrong when I said someone to them. So, this is someone, the person said, “Yeah, because this is because this is of this and this and this, and we hadn’t anticipated that. And, that’s why this project is underperforming.” And then I said, “Oh yeah, sure. You’re right. Hadn’t thought of that.”

Kovid Batra: Yeah.

Stephan Schmidt: You know? So, I might be wrong with my perception of underperformance, but nevertheless, I talk about it. And I hope people are accountable for performance, with all the support I can give them, you know?

Kovid Batra: When you say that you set the expectations, I tell them what performance looks like, how exactly do you do that? Just give me an example. Is it some metrics that you’re following? Is it some engineering KPIs that you would like to put up front that, “Okay, this is what we are going to look at when we are evaluating your performance.”? Is this what you’re talking about? How do you bring objectivity to this process? That’s the broader question I just wanted to understand.

Stephan Schmidt: So, the first thing is I always try to steer everyone to an impact framework instead of a velocity framework, because otherwise, performance is just more features and faster features which is not my understanding of performance. So performance is do things in a reasonably fast way. That’s engineering performance, with the right trade-offs between gold plating things, overthinking things on one hand, and creating engineering hacks on the other. So, hacks in a bad way, not in the, in a traditionally good way, but in a bad way.

Meaning so you need to make the right decisions. And if, for example, again, if, if someone takes two weeks for a development effort, and then I say, “Well, that’s too long.” I feel that’s too long, and then I let, let explain why it took two weeks. And then, I might be wrong because it really makes sense.

Kovid Batra: Yeah.

Stephan Schmidt: So I push for performance. So if, whenever I see or team lead sees performance in a way, speed in a way that does not look right, I go into it. But more, normally it’s more about making the right decision when to stop. So, how much engineering to put in and why not gold plating, having good quality code, low bug count, high testing, coverage. For me, performance is more about exercising good decision-making, good decisions as an engineer adhering to good engineering practices. And then, working on stuff that has impact instead of being the fastest, you know? It’s not..

Kovid Batra: Makes sense.

Stephan Schmidt: I said again, if I see someone who takes two weeks for something and I think it should take two days and it takes two weeks, I ask why it takes two weeks. It’s not.. It doesn’t make sense to me. And then, sometimes I’m right. The person is just not fast enough and needs to speed up and needs to get other skills or more training or sometimes a little bit being pushed a little, but sometimes I’m also wrong. There’s quite good reasons that it takes two weeks. And then if, if product comes to me, VP of Product and says, “That’s taking too long.” And I’m convinced that two weeks was totally fine. Then I say, “Oh yeah, totally fine. That’s how we fast, how fast we are.” You know? So, yeah.

Kovid Batra: Got it. All right. I think, thanks a lot for all the knowledge that you’ve shared, the insights that you shared with us. It was an amazing, amazing talk. Would love to do it one more time on different topics. Thank you so much.

It was really a pleasure having you, Stephan. Thank you so much.

Stephan Schmidt: My pleasure, Kovid. So, see you next time.

Kovid Batra: Thank you.


'Empowering Women in Tech’ with Limor Bergman, Tech Leadership Coach and Mentor

In the recent episode of ‘Beyond the Code’, Host Kovid Batra welcomes Limor Bergman, tech leadership coach and mentor with a rich background in organizations such as DigitalOcean, Quantum, Sun Microsystems, and more. She also hosts her podcast series ‘From a Woman to a Leader’. Their conversation revolves around ‘Empowering Women in Tech’.

The podcast begins with a fun fireside chat with Limor, allowing the audience to see her candid side. Later in the main section, She delves into the distinct journey of women in the tech industry, and strategies for overcoming them. Limor provides insights into managing fast-changing technology challenges in engineering teams and making optimal choices in tech career. She also shed light on how to define the success of your engineering teams.

Lastly, Limor shares parting advice for the audience, encouraging them to take risks and embrace failures.


  • (0:06): Limor’s background
  • (0:58): Fireside chat  
  • (8:45): How is the tech industry journey different for women and how to address these differences?
  • (17:01): Piece of advice for aspiring women leaders
  • (21:12): How to manage fast-changing technology challenges in engineering teams?
  • (25:46): How can women make optimal choices while navigating their path in the tech industry?
  • (27:48): How to define the success of your engineering team?
  • (31:10): Limor’s parting advice for the audience

Links and Mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I am back with another episode and a new guest who is passionate and a powerful engineering leader. She has an experience of 20+ years, currently serving as an executive coach and a mentor. She’s all about supporting women in tech. She runs her own podcast, ‘From Woman to a Leader’. She’s coming up with season 2 of the podcast, which is ‘Women of Color’, where you can find her talking about different diverse cultures and women growing as a leader there. Welcome to the show, Limor. Great to have you here.

Limor Bergman: Hi, Kovid. Thank you so much for having me. It’s a pleasure being here today.

Kovid Batra: Perfect.

So, all right. I’ll quickly tell you about the format of the show, Limor. We start with a quick fireside chat, and then we jump into the experiences that you have had as an engineering leader. So this fireside chat is to know more about you outside of work a little bit, some interesting things about you.

So, are you ready for some quick questions?

Limor Bergman: Yeah, absolutely.

Kovid Batra: Perfect. So, let’s get started. I have been like reading a lot about the tech blogs, the tech bloggers who have been producing a lot of content and you being one of those. I just really wanted to understand what inspires people like you who are writers to come up with writing. I have this thing, which I really need to know and understand because I someday want to write a book, whatever I’m learning from here. So yeah, that’s the first question for you.

Limor Bergman: Absolutely. And, I want to write a book as well, to be honest with you. It’s on my plan as well. So actually, you know, when I grew up, I thought that I couldn’t write. It started with a teacher that actually told me that I’m not a good writer. I mean, I was very good in STEM, you know, math, physics, chemistry, but I got kind of a traumatic experience from writing. It was traumatic because I got negative feedback. And also, you know, although I took a tutor and that was like the only tutor I took in high school just for writing. And my teacher was always criticizing me and that left, you know, an impact for years to come. That. Yeah, I may not be able to write, but what happened, the interesting thing that happened then, I wanted to express myself. I wanted to share my thoughts. I wanted to share with others, you know, all the insights I had and I actually started writing.

Kovid Batra: Okay.

Limor Bergman: And I found out that first, I really enjoy it. And then, I also, I’m not that bad. I mean, it’s not that terrible. And the great part nowadays, because everyone can be a writer, right? Everyone can write a book. Everyone can start a blog. You don’t have to be Shakespeare. You don’t have to be like super-duper excellent. Just express yourself, be genuine, express and share what you have, and do it. Everyone can do it.

Kovid Batra: Yeah, it’s a very simple thing, actually. Like, you just have to have that feeling of expressing your thoughts. You just, you probably can perfect it over a period of time, but you don’t have to fear starting off. You just have to have that feeling that you want to share what you have in your mind.

Perfect, Limor. I think that’s quite enlightening for me at least. All right, moving on to the next question. What advice would you like to share with young joinees in tech?

Limor Bergman: Yeah, that’s another great question. So, I’ll start with a quick story. So, when I started my first software development job, I was still you know, in university and I started like a part-time job. And, the experience was terrible because for multiple reasons. First, I had a very, very unsupportive manager. She was actually a woman. My first manager was a woman, but she was very strict. She was not nice. I guess she felt like she needed to keep a very clear distance. She was not supportive. I really did not enjoy working with her. The second thing is that I was working on ancient things, like on COBOL, on Mainframe, and I hated every second. I hated every second. It was clear to me that while it was comfortable for, you know, while I was at school, you know, because it didn’t require much challenge from my side, it wasn’t going to last. As soon as I’m going to graduate, I cannot keep doing what I was doing.

What I did was that I went to the manager above my manager back then, and I had a conversation with him and I told him, “Listen, I mean, I really like the company. I would like to stay here. But, I cannot continue working with, with that, you know type of work. That’s not what I signed up for. I want to move.” I mean, back then Java was the shiny new technology, new language. And there was a team that actually wrote Java Applets. Yes, I’m that old. So, and I told him, “Listen, I mean, that’s the team I want to join right after I graduate and move to a full-time job, otherwise, I mean, I just cannot see myself staying here.” So, I wasn’t threatening per se, but I was making clear that, I mean, that’s not going to work for me. And, you know what happened? He listened. I mean, I was lucky, right? I mean, he could’ve not listened, but he listened and he moved me to that team.

And long story short, I would say that the advice I would share is that even if you’re just starting out, appreciate yourself and what you are worth, know what you want and don’t be afraid to ask what you want, even if you are just starting out.

Kovid Batra: Yeah. I think I can, I can relate to this feeling and when I had joined my first job, I was always under this impression that something should not go wrong, people should not perceive me wrong. And on top, like the most important thing was the managers, the leads should not perceive me wrong in any way. So, I used to, like not express much and I couldn’t be genuine there and it definitely affected me in a negative way rather than in a positive way. So, that’s a very good piece of advice that you have to be fearless, in a reasonable way. Like, you have to be polite and respectful, of course, for others. But, you cannot be just listening and not expressing your views, not being genuine there. So, yeah, I think that’s a good piece of advice, Limor. Thank you for sharing that experience, by the way.

Limor Bergman: My pleasure.

Kovid Batra: All right. I know you are super passionate, super powerful. I get that vibe. And, I just want to understand what’s your daily dose of energy, like what keeps you going every day when you wake up? What is it that pushes Limor to, like go up?

Limor Bergman: Yeah, absolutely. That’s another great question. So, I like going to the gym. You see, my hair is a little bit wet still because, I just I got back from the gym about an hour ago. So, my daily dose of energy is just running. I actually discovered running, you know, when I was in university. So, I was going to a gym there. But, I stopped for years, you know, when I got married and started a family, I have four children. So, you know, it was hard and I kind of was very inactive. I lived very sedentary lifestyle. In the beginning of my forties, I really wanted to change that. I couldn’t believe I will be able to run. You know, I had those limiting beliefs, it’s impossible for me to run, but I actually worked on breaking those beliefs and started running and found out that it’s a great source of energy for me. It motivates me. It gives me not just motivation, but a lot of strength, a lot of joy. So, that’s kind of my daily dose, either running or just doing weightlifting at the gym, meeting with people, you know, that I already know. That’s what keeps me going.

Kovid Batra: Cool! All right, Limor. Thank you for this fireside chat. And I think we got to know a lot more than we already did about you. So, that really helps.

Now, moving on to the main section, uh, wherein we want to talk about a lot of things. But, we’ll keep our curiosities in our pocket and try to restrict it to a few questions. Can I get started with you there?

Limor Bergman: Absolutely.

Kovid Batra: All right. First of all, it’s already out there, and I really appreciate from the bottom of my heart, the kind of push you are giving to the women in tech. Really hats off to you. We know that this journey is different for a woman in the tech industry. How do you think it is different from the male counterparts? And, what you really think should be done about it?

Limor Bergman: Multiple reasons. I mean, first of all, we are still outnumbered. So, there are fewer women in tech compared to men. When I started my career, for years, I was the only woman working surrounded by men in my team. I was the only woman. It wasn’t terrible. Don’t get me wrong. And, I worked with wonderful men, very supportive. I learned a lot from also very supportive managers, but I felt different. Felt like, “Okay, I’m not exactly the same.” And, sometimes it was harder for me to feel a sense, a sense of belonging, right? Because the men, they wanted to do different things to hook up after work and maybe not everything interested me. And so it’s, it’s about belonging and feeling like I belong, I’m worthy, I’m like the rest of them. Men tend to be very competitive, ego-driven, not a bad thing. I’m not saying that negatively, but it’s like, “Okay, I’m better than you.” Like, they have this tendency to really thrive from competition. I don’t know if you’ve seen that, but men have this tendency.

Kovid Batra: No, definitely that’s there. It’s just that I’m keeping my thoughts to myself and listening to you.

Limor Bergman: Yeah. And for women, at least for me, less so. I thrive by growing and becoming a better version of myself every single day. I don’t care much about how I am compared to others rather than to me. And that, like having those different mentalities, it’s sometimes difficult because I don’t want to compete with someone else. I don’t want to prove anyone that I’m better, I don’t need to necessarily. That can create a lot of uncomfortable feelings. Sometimes confidence issues, when people make comments, not in a mean way, but just that’s the way to communicate because they want to show how better they are. You know, so a lot of more differences, you know, women, you know, create life that comes with its own set of challenges. So, I think that the mentality and the way of communication, and the way of work is kind of very, very different. And the fact that we are outnumbered.

Kovid Batra: Yeah. But, what do you think exactly can we do about it? Actually, that’s something which is a long-term, long-held problem. What do you think today.. I think that ratio has definitely changed from the time probably when you joined as a leader or a woman in tech. Now, it has changed. But, what according to the current scenario can be done around it to solve this problem?

Limor Bergman: I think, first of all, it starts with awareness. Even if you have a team that most of the team are men and there are fewer women, just take that into awareness that how can I make the women in my team feel like they belong, feel comfortable? What can I do to support them and be sensitive to them, to what you say or don’t say? You know, I remember I was deeply, deeply demotivated and hurt by just code review comments that people wrote me because they wrote it in a way that was not sensitive enough. It was like very blunt. Again, nothing, it’s not a bad intention, but it can really hurt confidence of someone when you make a code review that is very, maybe you’re right, or maybe you’re trying to make a point, but it can really hurt the confidence of a woman or even what you share in a meeting and how you, how you talk. If you’re telling someone ‘you’re wrong’, if you use strong words, right? When a woman starts to express an opinion and you kind of contradict her, or maybe talk over her, that can really hurt her confidence. So, just awareness and being a little bit more sensitive can go a long way.

Kovid Batra: Yeah, I think so. That could be the first step, right?

Perfect. Anything else that you have felt in your journey as a woman was different and could have been done differently?

Limor Bergman: I mean, I wish I had met more mentors in my career. You know, when I started, I felt, as I said, I mean, I was always pushing myself forward, but I felt a lot of times confidence issues and whether I’m good enough. I think having more mentors could have helped me with acquiring knowledge, with learning better and faster, with feeling worthy, and probably advancing my career even faster than I did.

Kovid Batra: Do you think does the same problem exist right now for the women of this gen? Like, right now?

Limor Bergman: Yes. But luckily I think that they are, because, you know, it’s a complete different generation. There are a lot of online communities for women.

Kovid Batra: And there are influencers like you who are now helping people.

Limor Bergman: There are influencers like me, that’s true. There are communities. I think that mentorship, sponsorship, you know, all of those things that I didn’t even know existed when I started are kind of the norm. I mean, and I volunteer, by the way, I volunteer in organizations in women-related mentoring organizations. So, yes, there is still a need, but I think that there is more awareness both from the women’s side and also, you know, there are different communities and organizations that support women, both paid and unpaid, by the way, which makes a huge difference.

Kovid Batra: Absolutely. Absolutely. It is critical, it is very important to have a mentor, be it a male or a female. But, how did you find it difficult for a female to find a mentor at that time? Like, again, is this just because of the gender difference or is it in general, like, women don’t have the tendency to go up to a male mentor and talk to them? What exactly is that?

Limor Bergman: I think that, back then I didn’t even think about that in, I didn’t even think that I may need one that even the word ‘mentor’ was not something top of mind for me. So, I didn’t even think. I was occasionally asking, you know, people for help, right? For, “Oh, can you look at something?” Or, “Can you help me?” But, I always felt uncomfortable. I think, I don’t know if this is a generic women thing, but I personally have a tendency that I’m always happy to help others. I feel less comfortable asking for help. And, I think that’s like the main, maybe barrier that if women feel uncomfortable asking for help, eventually that hurts them.

I was afraid of asking, afraid or uncomfortable, and also was worried whether asking for help is going to be seen as a sign of weakness, maybe I’m not as good, you know, because I don’t know something. Is it okay to tell my men counterparts that I don’t know something? That I haven’t heard of a term? Like, if I’m new, and I was new in many teams in technologies that I didn’t know, and like, is it okay to say I have no idea what you’re talking about? You need a certain strength and confidence to be able to say that.

Kovid Batra: Makes sense. Makes sense. But I think that, that problem of insecurity even lies with the men, I think..

Limor Bergman: Absolutely.

Kovid Batra: Even more there sometimes because of the “alpha” ego and that we carry. So yeah, I totally relate to that. But yes, acknowledging it and overcoming it, and then probably finding a mentor is the right way ahead.

You just mentioned like, people have to be more sensitive when there is a woman in the team and try to be adjusting and offering help. One more thing I realized right now, like it’s a biologically also, it’s a very different journey, right? Like, we can’t give birth to babies, right? Unfortunately. But, that is a time when I know a woman has to choose between work and personal life, right? And I’m sure you have had that point of time in your journey also. How did you go through it? What’s your piece of advice as a mother and a woman leader to the aspiring woman leaders?

Limor Bergman: Wow! That’s an incredible question. So first of all, I am a mother of four children. And, my oldest is 19, and I have a 16-year-old, and my youngest are twins, they’re 13. And, I worked throughout my career. So, it is possible. I worked and I advanced my career. Children are not a barrier. It depends what you prefer and what, you know, it’s very personal. I would say that it was not easy for me, and as you said, like, choosing. It shouldn’t be that way. I shouldn’t need to choose between career and family. Because men don’t have to, right? I mean, there’s a mother and there’s a father. Why should there be a difference? I know, yes, we give birth. Yes, we stay with the babies a little bit. But, why should there be a difference? And, there were times in my life, actually, there was a time before I was planning my second child that I was very unhappy at my work and I was debating with myself and with my husband. What should I do? Whether should I leave and find another job and start someplace else? Or should I stay and expand the family? My husband was very supportive, and he told me that’s my choice to make. But, why would I need to make that choice? If I was a man, that wasn’t the question. The men would leave and find another job and extend the family. But a woman, like if I’m planning to expand, I felt uncomfortable even interviewing for a company, knowing that I may be pregnant or may be pregnant soon. And, why should it be that way? It shouldn’t. And I do see a change. The good thing, I do see a change, but not frequent enough and not enough that employers sometimes, you know, even higher women knowing that they are pregnant, talk more freely about it and say, that’s not a problem. Join here, start and then go take care of your baby and come back. So I do see some employers do that, but I, I guess what I would like to say is don’t look at it as a barrier for employer sides, for manager side, and try to be more open-minded. It’s not like a problem. It’s natural cycle of our lives, right? I mean, expanding the families and women, we are very capable. We are capable of doing so many things, taking care of our kids and our careers, and doing everything. And, we do it very well and we know how to manage our time and be very, very effective. So, trust us that we know what we’re doing and don’t treat us as like, Oh, you know, “She’s having a baby, so she cannot do that.”

Kovid Batra: Yeah. I totally feel that. I respect my parents, but I have a little more respect for my mother, because I genuinely feel the kind of like, a, it’s a naturally built thing and it is hard physically and mentally and you still fight through it. So, you are better warriors, maybe you are the gladiators. The hard reality in the industry is people seek profits and when it comes to work, people forget, like we need to be sensitive towards such things. But I hope, I wish, with this messaging, with these kind of thoughts, we are able to change a few more lives.

Limor Bergman: Absolutely.

Kovid Batra: All right. That was really intense and interesting. Let’s move on to something that I think the audience would also love to know. Like, coming to the core work thing, like how do you deal with situation of fast-changing technology in your engineering teams? So basically, what kind of challenges you face? How do you deal with those challenges? Can you just give us a few examples?

Limor Bergman: Absolutely. So, as I said, right, I started with the story that I started with COBOL and I moved to Java. I didn’t know anything about Java, nothing. And, it wasn’t like today that you have so many online trainings and courses and so easy to learn something new. And, I just had to learn it basically by myself. There are some books. Yes. But I had to learn for myself and ask a lot of help, right? I mean, be willing to ask for help. I was joining a team of super-smart people, very talented and much more experienced than I am. So, don’t be afraid to ask for help, I guess. And, be always willing to learn. And then I, I moved from, as I said, I started with Java Applets, and then moved to backend to Java enterprise edition. It was back then in infancy was the hot new thing. So, don’t be afraid. Don’t be afraid to learn. We are constant learners. Technology changes so fast. And, if you are not willing to adopt and to learn, you will stay behind. You will stay behind, I’ll tell you that. You know, I took a challenge, you know, when I moved to Sun Microsystems, not at the beginning, but, but after about a year, I joined a team that did real-time Java. So, I actually had to dig into the virtual machine itself, and handle with real-time threads.

So like, I’m not saying I’m the bravest and smartest. But, I wasn’t afraid of trying, of getting into very, very uncomfortable situations. So, just keep on evolving and learning. I mean, never be afraid of a challenge. Be willing to learn and grow, stay up to date, and don’t be afraid to ask for help.

Kovid Batra: Perfect. Now, let’s say, as an engineering leader or an engineering manager, you’re working on a project and you feel that this new technology would be more supportive to the requirements of the business, and you have to take this hard ball of maybe branching out and working on this piece. Before you do that, this can go both ways. Like, it can become a problem in the fast-paced growth of a company, right? You’re adopting a new technology, then you have to skill up and do things. When you take this call, what all considerations come into your mind? How do you lay out that structure that, okay, now we have made a conscious choice, made a conscious decision that this is the right thing or the right technology to go forward with? How do you do that?

Limor Bergman: I think you start with the first, what you’re trying to build. You know, what do you need, what technology to use I think you need to assess, you know, what is out there, maybe what other companies are doing, what is industry standard, you know, be always, you know, on top of what’s going on of the trends and choose a technology that can provide you with solutions to the problems you need in the best and fastest way. And, a lot of times engineers are married to something, right? Because they, that’s what they know. So, there are, you know, I had like, engineers that wanted to use a certain database just because that’s what they know. Is this the right choice? Maybe not always. So, ask yourself, I’m just taking a database as an example, am I choosing it just because I know it? Or I have some, some favoritism for this? Or is it really the right choice for what I need? So, make a list, those are the requirements. And, consider several options. It’s always good to consider multiple options before making a decision, not just one. Try to remove the bias. Make it more data-driven rather than opinion-driven.

Kovid Batra: Yeah. I think getting rid of that bias automatically opens your mind. And, then get down to the point where you, you know that, okay, this is beneficial for the business, this is what we need in the next six months as a product. So, then you start thinking that way. Otherwise, I think it’s, if you go by the gut, if you go by the instinct, then of course you would do something that you already know. So yeah, it’s very important to get rid of that bias and then take a decision.

Perfect. Next thing that I would like to ask you for anyone, how should one progress in the career in tech? Like, how one can make the best choices for them? And especially, I would love to hear a perspective again on the women in the tech industry, like how should one progress in the career and what, how should they make the best choices for them?

Limor Bergman: I mean, that’s a hard question to answer because it’s very generic, because I would say, at first you need to be deliberate about what you want in your career, and what interests you, what you’re passionate about, how do you see yourself in a few years. I didn’t always know that. I remember when I was promoted to a staff engineer at Sun, that was when the career kind of progression was split between management and IC track. And, you know, I was on the IC track. My manager decided that, you know, that’s the right next step for me. But, I actually started doubting whether that’s what I wanted. Do I want to become a specialist? Do I want to continue being a software developer for the entire career? And I realized that no, I didn’t, and I wanted to, to become a manager. It took me several years to do that, just because I wasn’t really thinking about that strategically. So, be strategic and then find opportunities to build the skills that you need in order to move forward towards the direction you want. Whether it’s learning new technologies like I had. I had a client who wanted to move to machine learning and artificial intelligence. So, they knew what they wanted. So now, it’s about, okay, how do I learn? How do I find opportunities to meet people? And with that knowledge, build a network, contribute to open source, whatever. I mean, just you have to be deliberate about what you want and start building a plan towards that.

Kovid Batra: Makes sense. Makes sense. So, having a clarity on what we exactly need, and what, where we want to be based on that, the choices should be made. Yeah, that makes sense.

Perfect. This is my last question to you. Now you have been coaching and mentoring multiple engineering teams and engineering leaders. How do you define the success of an engineering team, and how do you measure it? How do you make sure that while you’re thriving for success, You’re taking care of the developer well-being also, you’re taking care of their experience, so that at the end of the day, your team is happy and motivated to do whatever you want to do as a team?

Limor Bergman: Yeah. So, there are multiple things, right? It’s about culture, motivation, and all those soft things. And there are productivity, you know, effectiveness and those things that, that you want to measure. I think, about soft areas, the motivation, it’s about connecting with people. It’s about caring for them. It’s about knowing how to ask the right questions constantly being interested in them and their career aspirations, what interests them, what they want to do, what they like doing, what they’re good at and helping them thrive, and building those connections.

About the team, whether they’re productive or not, there are different areas to look at that. So, you can look at quality, you can look at reliability, you know, there are different aspects, development speed, how predictable you are as a team. And, the best way to know that is to measure and look at data. So like, bare minimum, like when you run a team, use a tool, could be JIRA, whatever, I mean. And, start estimating your work, story points, whatever you want, doesn’t matter, you know, whatever works. But, start, you know, estimating, and then compare how much time it actually took to you to deliver versus, you know what you thought. Do retros and, and constantly improve, because you want to see how good you are with estimating, how predictable you are as a team.

I also, you know always looked at what was not planned. What kind of work did we do? And, I was forcing engineers to put in JIRA, I kid you not. Tags of this was not like, I don’t remember the tag you use, but like, this is something new that came up because it was important. And I explained to them, always explain the why. I explained, “That’s not because I want to spy on you, but it’s because I want us as a team to understand what are the things we haven’t expected and how much buffer do we need to take to those unexpected things that will come up.” Right? Eventually, we cannot avoid all of them. Maybe some of them we can.

And then, you have to measure things like mean time to deliver, mean time to recover, all those, you know, measurements that you can do with different tools to know how effective you are as a team, how fast can you develop a new feature, how fast can you find a bug, how fast can you recover from an incident. So, you have to measure all those things, and constantly thrive to be better.

Kovid Batra: Makes sense. Makes sense. This really helps. And with that, I think, we have come to the end of our show today. I would have loved to talk more on a few topics that I’m really interested in, but in the interest of time, like we’ll have to close here.

Any parting advice for our audience?

Limor Bergman: I mean, parting advice I would say based on all I said here, just continuous learning and growing, it’s a journey. And then, don’t be afraid. Don’t be afraid to fail. Take challenges and ask for help. It’s part of growth.

Kovid Batra: Perfect. Thank you so much, Limor. It was really a pleasant experience having you here.

Limor Bergman: Thank you so much. Kovid. It’s been a pleasure.

Leading Tech Teams from 0 to 1’ with Peter Kristianto Widjaja, Co-Founder and CTO at Hubble.Build

In the recent episode of ‘Beyond the Code’, Host Kovid Batra, welcomes Peter Kristianto Widjaja, Co-Founder, and CTO at Hubble.Build, Singapore. The focus of their discussion revolves around ‘Leading Tech Teams from 0 to 1’.

The podcast starts with a fireside chat with Peter, providing us a glimpse into his personal background. Moving to the core discussion, he offers an overview of Hubble.Build and shares the challenges he faced in his engineering journey. The conversation then takes a deeper dive where he discusses the importance of ‘Purpose-driven values’. Further, Peter sheds light on 360 evaluations and the importance of psychological safety within teams for measuring their well-being.

Peter concludes by offering parting advice to the audience.


  • (0:07): Peter’s background
  • (0:34): Fireside chat 
  • (4:22): About Hubble.Build 
  • (5:10): Peter’s engineering journey
  • (9:56): Importance of ‘Product-market fit’ approach and ‘Purpose-driven values’ 
  • (15:30): How to measure and ensure the overall well-being and efficiency of your teams?
  • (27:37): How to address and rectify workload imbalances in the team?
  • (30:45): Parting advice for the audience

Links and mentions

Episode Transcript

Kovid Batra: Hi everyone! This is Kovid, your host at Beyond the Code by Typo. I’m back with another episode and a new amazing guest who’s an entrepreneurial soul from Singapore. He’s the CTO and Co-founder of Hubble.Build. And also, he is one of the youngest leaders so far on the podcast. Great to have you here, Peter.

Peter Kristianto Widjaja: Hi. Hi, Kovid. Hi, everyone.

Kovid Batra: All right, Peter. Thank you for coming on the show. And, as a usual format, we have this quick fireside chat with every guest of ours. And here, we would be knowing a little more about you personally. All right?

Peter Kristianto Widjaja: Sure. Let’s go. Let’s do it.

Kovid Batra: Perfect. Perfect. So, let’s get started. All right. So, tell us about your first production blunder.

Peter Kristianto Widjaja: Oh, hmm, okay. Well, production blunder…I guess it’s when the company was still small, right? So, it’s about 2017, 2018. We were running a very small engineering team, about three people. Everybody doesn’t know what’s a good engineering practices and we really prioritize speed over other things, you know? And, some of the points, you know, there’s some bugs on productions that happened. And as a CTO, obviously I have production access, I’ve root access last time to everything, and we tried to make a very quick fix for our customer because it was a business critical issues and it made things worse. Classic, right? And yeah, the customers scold us for a good few hours, the CEO has to hear all the customers making noise to us. And yeah, yeah, that’s pretty much, you know, and then we learn our lessons and then we know, “Okay, no more”! Right?

Kovid Batra: How many calls did you get from the customers that day?

Peter Kristianto Widjaja: How many what? Oh, oh, dude, don’t, I mean. I guess it’s just… okay, the good thing, it was, we’re still small, so it was just one customer, but it affects a lot of users within that customer. But, yeah, we have to say sorry for about 2,000 times that day, I guess.

Kovid Batra: That’s the best thing you could have done.

Peter Kristianto Widjaja: Yeah, I mean, but we managed to, I mean, we have backup. Luckily, we have backup, so we managed to sort of roll back things. But it took a while because everybody was not seasoned, yet at that point, yeah.

Kovid Batra: Sure, sure. I mean, I see that there’s a lot of energy, you’re young, but still, there must be some daily kick for you, daily source of energy that gets you through work I would love to know about that.

Peter Kristianto Widjaja: I mean, obviously the first thing in the morning is a cup of coffee. So, you get your caffeine kicks. That’s the first thing, the most important thing for all engineers. Well, I’ve been doing this with this company for about, six, seven years, right? Since it started. Obviously, you know, it takes a lot of things to keep it going. And, you know, sometimes you have just no motivations to wake up and like, you know, the same things that you were building a few years back, it was still at a stage, you still need to do something. But for me, it’s the people, right? So, we have grown so much that now I have a lot of people in the company, and you know we are doing great things. Everybody’s so talented in the team that it just makes you feel like, you know, it’s fun, right? Because everybody just heads down, talk about ideas and implementing it. Obviously, there’s the not so fun part about, like deadlines and all those things, but yeah, I mean it comes together, but it’s fun.

Kovid Batra: So, it’s people for you then.

Peter Kristianto Widjaja: Yeah, it’s people.

Kovid Batra: Perfect, perfect. All right. One last thing. What’s your favorite go-to video game?

Peter Kristianto Widjaja: Well, I’m an old-school guy. So, I still play Dota pretty often, and not that often, but it’s too often for my wife’s liking.

Kovid Batra: Got it.

Peter Kristianto Widjaja: I should… You know, yeah, well, yeah.

Kovid Batra: Well, great then! Great. Perfect. So Peter, this was great knowing you. These were some fun things that we got to know now. Now, moving on to some important substance. We know what Hubble.Build does, but for our audience’s sake, first of all, I would love for you to tell them what Hubble.Build does.

Peter Kristianto Widjaja: Cool! So, Hubble.Build- we are a construction tech startup. We are based in Singapore. We are mainly providing a lot of solutions, B2B SaaS, especially for the different construction companies, here in Singapore and Southeast Asia. We’re looking into essentially digitizing, automating, and obviously at the end of the day, doing more of insights, for our customers. Yeah. So, it ranges different operation and verticals in the industries.

Kovid Batra: Thank you. Thank you, Peter, for that introduction. So, now my question is, I personally have been an entrepreneur. I have seen that journey, but unlike you, I mean, this journey of 0 to 1, my experience is a little less than you. So, I would love to hear your experience, how it has been starting from a garage, because last time when we were talking, you told about this. It was just three members and now scaling it up, having around 40 dev members. So, this is definitely a journey and it’s almost been a decade for you into this, right?

Peter Kristianto Widjaja: Yeah. Yeah.

Kovid Batra: So, how has it been? Let’s start with some of your best experiences of this journey. The most challenging experiences of this journey.

Peter Kristianto Widjaja: I mean, you know, as a Co-founder/CTO, starting with three people and now you’re leading about 40, the whole company is about 70, 80 people. It’s about that transitions of like, you gotta, I would say adapt, and your role keep changing as the team grows. You know, when, when we started with three people, essentially I’m an engineer, I have to code, right? Everybody, like me and my, one of the other engineers, we have to code and I have to go deep into the backend, the frontend, everything. Every day is about code, code, just keep developing and launching new products. When in which 10, it’s about being a team lead and a manager, right? So now, you have these 10 people and you gotta make sure they are happy and everybody is aligned with what they are doing. Now, you grow into 40, it’s a different ball game by itself. And, each transitional period needs a lot of self-reflections, and also just humility just to know that, “Okay, I’m not good at this. I gotta improve on this.” But, if you are the person that, say, likes coding, right? At, you know, 40, you’re not gonna code most of the time, right? So, you gotta be like, okay, you know, you pick your poison. Obviously, you still can code outside of your most responsibilities, but you have to understand that your main responsibility is not to code anymore, it’s to inspire and direct the vision of the team. So, I guess, I guess that is the most challenging part Yeah.

Kovid Batra: Doing that transition from being an engineer to a leader is definitely a transition.

Peter Kristianto Widjaja: It’s crazy.

Kovid Batra: And, I think it doesn’t come easy, particularly with the engineers, right? They have this habit of just coding, being with their laptops and desktops. So yeah, it definitely is. So, let’s talk more about some of those incidents where you actually had to change your daily habits or behaviors while you were working as an engineer to a leader today. Let’s talk about those, some of those challenges.

Peter Kristianto Widjaja: Yeah, yeah, again, I guess the journey from 0 to 1’s and obviously 1 to 10’s is going to be very different between, you know, one community to another. For me, um, it’s when I think we reach, let me count, 1, 2, 3, 4, 5, 6, about 6 people in the engineering team. That’s when, you know, I’m still heavily coding and then what I realize is that people are just doing their own things, right? And, there’s a lot of miscoordinations with regards to what we are building, how we are building it, and somebody got to take charge, right? Somebody has to make sure that, you know, we do have product managers at that scale. So, somebody has to lead the product, talk to the CEO, most likely the CEO leads the product, right? But, you know, but the CEO also has to do sales and all the other functions. So, somebody got to step up and make sure that there’s a lot of coordinations and we are building the right things at a point in time, you know. I guess that’s sort of the trigger and like, “Okay, I can just keep coding. I got to, like you know, do something else, and should I hire someone to make sure that I don’t need to put that much anymore?” That question start to come to mind. And, you will realize that because you fe