The DORA Lab #01 – Lena Reinhard | Tech Mentor, ex-VP CircleCI

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!