Inside this episode
In today’s episode, I am joined by Lena Reinhard, a Leadership & Executive Coach, Mentor, Organizational Development Consultant, Advisor, Speaker & we are answering the question What engineering metrics should I use as a leader?
Host: Aaron Rackley
Guest: Lena Reinhard
Book Recommendations:
Show Transcript
These transcripts where auto generated by Descript. If you see any issues, please do reach out and we can rectify the issues.
Aaron Rackley: [00:00:00] Hey everyone, and welcome to the Tech Leadership Decoded podcast, where through conversations, we unravel the intricacies of leadership in the tech industry. My name is Aaron, a tech lead here in London, UK. And in today's episode, I'm joined by Lina Reinhardt, a leader and executive coach, mentor, organization development consultant, advisor, and speaker.
And we are answering that question, what engineering metrics should I use as a leader? I really hope you enjoy today's episode. And if you do. Please, can you take a moment to like this episode and leave a review on the platform you're listening on? It will really help us reach more people like you. And with that, let's get into today's episode.
Okay, and welcome to our podcast, Lina. How are you today?
Lena Reinhard: I'm good, and thank you for having me. Brilliant.
Aaron Rackley: And with the start of 2024, I've got a couple of podcasts coming up, including your one, which is all about kind of like looking at the year moving forward, how to think about yourself as an individual leader, like goal [00:01:00] planning, you know, thinking about your team on what metrics and all this kind of stuff as like a, a fresh new year, new beginning.
And I was reading a blog post that you obviously wrote called what engineering metrics should I use a guide for engineering managers, directors And I wanted to get you on to obviously Have a quick chat about as a new leader, who's in the role, what kind of engineering metrics I should be looking at, or what kind of things can I do to keep an eye on my team, essentially.
But before that, why don't you just spend a few minutes just introducing yourself, let us know about your wonderful self, and for anyone that's listening, Lena's sitting outside at the moment, so if you get any, uh, any sound, that's why.
Lena Reinhard: I hope we don't get too much of that. So yeah, I'm Lena Reinhardt. I'm an engineering leader.
I've been in the. Workplace for almost 20 years. My background initially was in finance, but I've [00:02:00] been in tech for 14 years now. And my work is in any role I've had is basically about helping people and organizations manage complexity and be successful with it. And practically that's meant I've been a startup software as a service, um, co founder and CEO.
I've been VP engineering at Travis CI and Circle CI. And, um, I've also been an engineering manager in a couple of places, and now I do the same work. Um, so helping leaders in the technology space succeed in complexity. And I do that work now as a leadership coach and trainer, mentor, and organizational developer.
And so for me, it's all about these systems of humans, tech and business and making success with those. Yeah, no,
Aaron Rackley: that's awesome. That's a very variety driven experience there, which
Lena Reinhard: Yeah, I'm just a curious person and that's what happens. There's a career path if you'd like to say
Aaron Rackley: yes to things Yeah, mine's exactly the same.
I jump around [00:03:00] just because I I need to just be doing something new all the time Yeah, love a good challenge. Yeah, 100 percent So thinking about um metrics for engineering leaders, I think the first question i'm going to ask is like what What is the most common pain point you think of someone coming into leadership of choosing what is the right metrics to do?
And then we'll come to implement them later. Yeah. How do you, what do you choose? What is there?
Lena Reinhard: So. I will admit that I'm always torn about that question and how to answer it best. Um, because my, in my experience, especially working with new leaders and also also being a new leader at some point, um, the challenge is that, um, it always really helps to basically have a very concrete starting point.
And so I do think, um, basically talking about what exact metrics can be helpful for which purpose, I think that's helpful. And I'm looking forward to talking about this. And at the same time, I've also [00:04:00] found that like with any framework or any, um, example, basically of how to run a team, there's technically the answer always has to be it depends.
So it depends on what metrics you should choose, depends on your organizational context, your role, where your team is at, et cetera, et cetera. And, um. So I find that basically even to answer the question properly, there, there are these two aspects to it for me, basically, as a new leader, you need a starting point, absolutely.
And at the same time, I have also found that especially as you're growing over time, it really helps to have a bit of a framework that you can use to understand why certain metrics are important or when to pick which ones for which team at what point in time. How do you feel
Aaron Rackley: about that? Yeah, no, that's good.
So there's a couple of things, right? So you're saying that there's like some core kind of metrics that you could use across everything and then there's like frameworks that you can use. So maybe we start off with like some of the [00:05:00] metrics that you find are quite common across different scenarios, right?
So what kind of metrics are there that we can look at?
Lena Reinhard: So if you're an engineering manager and, um, meaning you have a team of engineering managers reporting to you, um, and there aren't already metrics in place, honestly, that could be a really good point to start from basically look at the metrics that other teams are using, ask your peers, ask your boss what they're familiar with.
Um, that said, um, I would say at the engineering manager level, um, I, the reason why you're using metrics is usually twofold. Um, the one part is essentially to help your team learn about themselves in the sense of how are we working, how is, um, how are our processes. What are the impediments in the work that we're doing together?
Um, so essentially it's about helping a team understand themselves and, um, get better. And so it's in that case, [00:06:00] metrics are really a pillar or core aspect of, um, DevOps culture of learning agile culture. Um, and a really important part of that. Um, the second part, um, in addition to helping your team, there's also metrics that are.
I always call them metrics about your team, so metrics that you use to convey to other people how the team is performing and honestly also just to have those for yourself because metrics are an important part of having visibility and situational awareness of how a team is doing. And those metrics about the team are a bit more for people like your boss, maybe a product manager.
If your team has one, if you have a platform team without a PM, maybe there's there are other platform teams or upper leadership that you have to provide some sort of visibility to. And so keeping these audiences in mind, I find this really helpful. Um, and so in terms of concrete metrics, metrics for a team, um, Of course, there are the classics, there are Stora metrics, um, which are [00:07:00] quite sort of engineering centric in the sense that they're about ultimately being efficient as a team, being effective as a team.
And, um, so those can be really helpful. Um, I would also always recommend talking to your team, because especially if your intention is to help your team learn and improve over time, they will. Maybe have some ideas for what they would find helpful. Some teams, for example, are struggling with observability where either not much is in place or they're getting overwhelmed with alerts that are meaningless.
And so, um, understanding basically what the problems are that your teammates are seeing and then how to measure those is honestly always a really good conversation because it also helps engineers then wrap their head around the metrics, helps with avoiding resistance to adopting metrics. If that's not a practice people on your team are used to yet.
Um, So yeah, basically what the engineers want, DORA metrics are a good starting point. Um, I would also suggest, um, for the whole topic of helping a team learn [00:08:00] metrics that are more about the agile process can be super helpful. So things like, um, cycle time can be a really good one or the PR review time.
Um, if it's more about helping a team basically work in smaller increments, some teams also like to use story points. Um, that's always with a bit of a caveat that They're only meaningful within the team. But if, if you want to help the team work in smaller increments, make faster progress, um, basically helping the team understand how well, how good they are doing at breaking down work.
That's where story points can be super helpful. Um, yeah, that's sort of as a starting point.
Aaron Rackley: What do you think? No, that's really good. I think, um. We've had a few people that mentioned DORA, um, and across a lot of different managing areas. So, um, I think they're very useful, especially like, like you said, Dave, you've got like cycle time, deployment frequency, that kind of stuff.
Once you've got this data, um, you started to notice, [00:09:00] I don't know, the deployment frequency started to slip or sometimes getting longer, you know, what, what kind of things can that data tell you? And, um, What can you do to try and adjust that, I guess?
Lena Reinhard: Mm hmm. Um, that's, I honestly find, I love that question because it's usually one of the sticking points with Metrix, because it's one thing to basically see, hey, we are not doing well or we're having struggles in a certain area, but then what do you do with this information?
And so I mean, specifically, if your deployment frequency is going down, you'll basically start debugging. In the same way as you would do with a core code base, you start looking at the system. So, I mean, honestly, I always recommend grouping your team in as much as possible. And so probably say that quite a lot today, just because, um, the engineers on your team are subject matter experts.
And of course your responsibility is kind of to. to surface that expertise. Um, but so they probably have ideas. Maybe they were [00:10:00] just, you know, very simple things like requirements weren't, um, ready on time or there had there had to be some rework or you had someone new on the team or just people were working with an unfamiliar code base and so understanding essentially the people perspective is always a really important component of honestly making any metric meaningful and useful.
Um, so I'd always say start there. You can probably also I mean, honestly, um, you can probably also see some things just based off of the, um, the work that's happening. So for example, you know, did PR size increase? Um, what made that happen? What were the factors that got you there? And so, um, That's where, like, basically having metrics in place is great, but you're going to get only the most use out of them if you actually look at them on a regular basis, for example, once a week, and then talk with people about it and try to understand what is actually happening there.
Aaron Rackley: Yeah, I think, um, that's a good point. As you become an engineer, a lot of people that become [00:11:00] engineering leaders do come from engineering first, right? So you're used to breaking down the code base, the systems, to figure out where the bugs are, and you're doing exactly the same thing, right? But you're just moving it to people and processes.
Yeah, exactly. And you're finding the right problems, right? So yeah, um, I think as a technical leader, I think one of the things I think I've struggled with in the past is striking the balance between starting to use all these metrics for accountability, but also still using them to make sure that you can foster that culture of learning and.
You know, experimentation where people want to try and do stuff instead of just trying to hit metrics, because I found in the past, like, especially with a scrum, for example, just randomly, if you've got 20 story points, people start to live for 20 story points, instead of pushing forward, trying to find more, you know, they get into a happy, happy medium.
So how can we strike that balance, do you think?
Lena Reinhard: I think [00:12:00] that's something, honestly, that a lot of people struggle with. And that's probably going to be a continuous topic for you throughout your leadership career. And by you, I mean, basically all of us. Um, and so I think a couple of things, one part, I found is essentially the systems you set up around metrics.
So I mentioned the point already around involving your teams, um, having regular conversations like that can be an important part of it. Um, the other is just in what metrics you even select. My recommendation is always start with three or four metrics at maximum. Honestly, I feel like even, you know, Dora is technically four metrics.
That's already a lot. Um, you may actually be better off if you just pick one or two Dora metrics and then something else that's really meaningful to the team. Um, and including a way to balance out your metrics in this. So, for example, if you only measured story points, of course, your team's going to optimize for that.
Like, [00:13:00] because how would they not? And that's, that's one of these really gnarly pieces about metrics that. I find really hard to like, honestly, that's really hard for people to wrap their heads around, which is that metrics are going to create incentives, and these, these incentives are going to lead to behaviors and those behaviors are going to create your culture.
And that's where I don't think you need to overthink the metrics, but I do think you should. basically iterate with them in the same way as you do with anything else in the sense of basically reviewing regularly. Are those metrics actually working? Are they helpful? Are they leading us to where we want to go or do we need to make adjustments there?
So in the story point example, it might be helpful to additionally add a metric around Something that's not about shipping a specific amount of story points and trying to, obviously now I'm struggling to come up with a good example. Um, but, um, let's see. Um, [00:14:00] I mean, honestly, another could just be, are you actually achieving your goals as a team?
Um, So the basically I do find looking at metrics that are more efficiency based and that's where I would slot story points in the sense of it's about how we work. It's about our processes, having something that's about effectiveness. So in the sense of are we achieving our goals? Are we getting things done that can be really helpful?
So basically have some balance embedded in the in the metrics that you're selecting. Um, and I think the. Last part for avoiding these misguided incentives, basically, or these, um, accidentally wrong incentives, is, um, continuously improving how you're using these metrics. And as a part of that, also not just making it your work, um, So I, you know, you mentioned the word accountability and I do think metrics can help with that, but at the same time, there is so much where I realize I've already talked about this a couple of [00:15:00] times now, where it's about building systems that work.
So in the sense that it's not just dependent on you looking at metrics, but your team understands why you're doing this and the point of this and that story points, for example, measuring those is only a crutch in order to help you achieve a goal and the goal could, for example, be that knowledge is distributed more evenly across the team.
So that's actually the much better metrics metric now I'm thinking of it. Um, so, you know, do people actually feel like they understand code bases better? Um, and so keeping in mind that basically the metrics, metric is a tool to solve the problem and it's not, it shouldn't become the solution in
Aaron Rackley: and of itself.
Yeah. Yeah. That's interesting because a lot of that, as we just said, is, is focusing on the metrics of you looking internally as the team. And. I think there's a big conversation happening at the moment in general about like returning back to the office, working from home, all this kind of stuff. And I think I'm in a lot of conversations in lots of forums on Discord and Slack [00:16:00] where everyone's getting upset about being asked to return in general.
But I think, I think a lot of this comes down to, again, people not understanding the metrics that they're, they're giving back up the chain, right? So we've just talked about going internal, but going. The same has to be said for understanding what What information you're giving back, right? Because like you said, a lot of people are potentially ready to turn the office because your company doesn't think you're some visual metric or something somewhere that is saying you're not doing as much as you was before.
Potentially that's potential one reason, right? I'm sure there's financial reasons and lots of other reasons, but one of them is. Obviously, uh, kind of this kind of look at productivity and accountability and stuff like that. So, um, do you have, do you have any thoughts around the area? I know it's putting you on the spot, but I was just thinking, because it's a hot topic at the moment.
So it would be interesting to think about what kind of metrics we could use to let our, our bosses and our [00:17:00] company. know that we are still doing well. We're still, or even better than we was before.
Lena Reinhard: Yeah. Oh, I, I love this whole topic so much. And I, I also have to just say, I have a lot of, um, spicy hot takes on this and I will try to contain them.
Well, you won't, but other people might. So, um, basically the. Um, I do think this is important to talk about and to think about in terms of essentially how do you convey to your boss and your bosses that your team is doing work, that they're doing well, that they're, for example, getting better. It's something that most of us actually aspire to.
Um, and that all of that is possible in the context of, for example, remote work. I think that's really important before I talk about how to do that, though. I just want to preface it with essentially, um, I think, [00:18:00] I mean, ultimately statistics are very clear. People, like productivity is higher in remote teams, and I do, I mean, I have been working with distributed teams across the globe for 12, 13 years now.
Some of them were hybrid, but most of them were almost exclusively remote. The data is there. The whole reason why a lot of companies are really forcing return to office now, which is basically what's happened to me yesterday, I think, was when Google announced that people either have to make a choice to move to a certain area or they're going to lose their jobs.
Um, my understanding, honestly, is that a lot of this is essentially used by companies as an excuse and as a tool to make layoffs happen in a way that's easier for them to execute. Um, and, um, A lot of the reasoning that is given, especially by executive teams is essentially the CEO believes that [00:19:00] it's better if people are in an office, which is the CEO's personal belief system.
And that's played out, um, in, in those kinds of policies and whatnot. And so I do think there's a lot of smoke and mirrors around this whole topic. There's a lot of BS going on there in terms of how workers are treated and how, like. Policies are being shifted and whatnot. And a lot of this is essentially not based on data.
So I also basically want to say that yes, it's important to convey this picture of how your teams are doing. It's like managing up as a critical part of your job as a new leader or any leader, really, at the same time, there is a piece to this where you might be fighting windmills, um, and that doesn't mean that it's not worth it.
Um, but. It makes it a really tricky situation to navigate. I mean, that's as you, as you also said earlier on. Um, so yeah, and, uh, I'm going to stop there before I actually get into a rage.[00:20:00]
So in terms of how do you actually do this? Um, and I think. Conveying to your boss how your team is doing. It's important in specific contexts like the remote work stuff, but at the same time, it's also something you should be doing on a weekly basis, at least. Um, so I have actually, I have a template for how I've done this in the past on my site, and we can probably include that in the notes.
The whole angle. that you can think about there is basically pushing information. So in the sense that avoiding, you're avoiding that your boss has to ask you, for example, you know, how's the team doing? How are we progressing and whatnot? You shouldn't be getting those questions. You should. Always convey that information.
What's the word? Proactively. Um, so that's the starting point. Um, in order to actually talk about this, um, essentially the two things that any boss cares about and that I care about learning from my managers is, [00:21:00] are we achieving our goals? Yeah. And how are we Are we basically, are we spending the money that we're spending in a way that helps us get to where we want to go?
And so, in very practical terms, that should always mean, are we on track to achieve the goals that we have as a team? Um, you have, maybe you have OKRs or you have SMART goals, whatever it is, doesn't matter. Um, but, Are you on track to hitting those goals? Um, what are the risks? What are the unknowns? Um, and how, how confident do you feel about achieving those goals?
So for example, um, if you said, Hey, we're 90 percent there, but actually the last percent, the last 10 percent that are missing are about something that we haven't dealt with really that we haven't been able to plan because there's been too much going on or whatever the reasons are. These last 10 percent might actually be really gnarly.
And even though we still have a lot of time in the quarter, we might not actually get there. Dick. And so that means you have, like in this example, you have the metric, you know, how are we on goal achievement, like the [00:22:00] 90 percent and the context around it, which is, hey, I'm not super confident. Um, we are.
And then what are you doing about it? So, for example, you're working with the tech lead to de risk that project. You are working with stakeholders, whatever it is. Um, so there's, that's the. Are we achieving our goals piece, the effectiveness piece, and then there's the efficiency piece. Um, it might be that your company has given a mandate for teams to, you know, become more efficient.
It's been a big word that's been thrown around quite a lot. Or, um, you want to talk about the remote work piece. Um, and that's where you can look at how is your team performing currently? Has your, you know, how is your deployment frequency? For example, I would say, um, The slightly tricky bit with Dora metrics, for example, is that they are very engineering centric.
So if you're reporting to, for example, a CTO, um, who, you know, understands those metrics, understands their value, um, and understands what they mean, um, [00:23:00] those metrics can be really helpful. So you could incorporate your Dora metrics there, or you could, for example, say, Hey, we have, um, increased the number of story points that we're shipping because the team has gained more knowledge.
Um, we are on, on a. Positive track there. Um, and so essentially, ultimately there is a piece of understanding. What does productivity even mean to your boss and other business leaders in your organization? Um, and if you're not sure about that, or you can't really get that information, start with what you know.
Um, and if your boss then tells you, Hey, that's actually not meaningful at all. Well, then you can try something else, but really focus on pushing that information out and then dealing with the feedback. Um, and really, you know, you can iterate in your communication there in the same way as you can iterate in which metrics to use and how you use them with your team.
Aaron Rackley: No, 100%. Based on your, your, your experience over the long time that you said you've been doing it. The um, have you made any mistakes with [00:24:00] engineering?
Lena Reinhard: No, never. What? That's like, rude.
Aaron Rackley: I'm making more time. Oh,
Lena Reinhard: I have made so many mistakes. So the question is much more, you know, which, which area and, um, What do
Aaron Rackley: you think is the most common pitfall that probably new, new leaders would make with Metrix, I
Lena Reinhard: guess?
Um, so I kind of see two, honestly. Um, the one is basically just struggling to get started. Um, and I get that it's a very, it's not just a complex topic. It's also a topic that has quite a lot of hot debate around it, um, in sort of engineering circles. And so that can make it really hard. Um, so like we mentioned earlier, basically pick just something and start with it and involve your team.
If you're struggling with that part. Um, I would say the second [00:25:00] part that. It's really tricky. Um, but manageable is basically, um, starting to wrap your head around using metrics to achieve the results that you want, because one portion that's a bit more. The angle of, hey, you pick something, start there and then iterate from there, that's essentially what I would describe more as the observability aspect where you use metrics to understand how our team's doing, how does that relate to our goals and to what our bosses want from us, etc.
The other part is more where you can use metrics really effectively to drive change, like the whole piece. That I mentioned earlier in terms of metrics will create incentives, will create behaviors, will create culture. That is a really important bit. And so if you are essentially looking to, you know, help a team really get better at something specific, or you want to shift the culture on your team to be a bit more learning focused or a bit more experimentational or whatnot, um, that's when [00:26:00] it's just a different way of thinking about metrics.
And I found, um, That piece honestly was something that was really difficult for me for a while because I was used to metrics as much more, you know, Hey, the business wants this while we're going to do it, um, which is fine. There's nothing, nothing bad about that, but, um, using metrics in a way that's really motivating for a team and that helps them understand, you know, bigger context and all that, um, that I found can just take a while because so much of it then has all these.
Asterisk and it depends attached to it. Um, yeah. But yeah, I think those are the, the two ones.
Aaron Rackley: Yeah. I think, um, I definitely need a t-shirt with, it depends written on it because every set. Yeah. Every question for every fin in tech is, it depends.
Lena Reinhard: Mm-Hmm. . And that's so hard because I really like, I empathize so much with people wanting concrete answers and whatnot, but I think that also goes to.
Like, honestly, the crux of these leadership roles, like the ultimately [00:27:00] the thing that differs you is probably not the skill set or so that what differs you from the work that your engineers are doing, at least folks who aren't at staff plus level is essentially that your job is to deal with ambiguity.
And your job is to handle complexity and to handle things like, yeah, it depends. There aren't straightforward answers. Um, it's hard. Um, you need to look at all these different factors from your people to your boss, to your company, to your goals and whatnot. And that's a lot. And I found that basically I would also say in the, in any case, but also in the case of metric metrics, like give yourself time and.
just initially honestly start by just acknowledging that that is a thing, that that's part of your job now. And that also means the whole thing of like, nothing's ever done. Everything just takes forever. Um, or like a lot of, a lot of the work is also just about building good structures and systems. Um, like, you know, regular one on ones and retrospectives with the team and whatnot.
We do all of those things to basically it's leadership [00:28:00] hygiene. Um, and, um, that's work. It's more or less rewarding on any given day. Um,
Aaron Rackley: yeah. I remember when I first started out in software, I remember always I was joking with my colleagues, like what, why is our managers always in meetings and then you get to this level of role and then you go, and that's why, okay, I
Lena Reinhard: understand now.
Yeah, yeah. And, and, uh, I think, I mean, even for people who are more on the sort of technical leadership path in the sense that they don't have people reports, um, but they're owning larger contexts for technical projects and whatnot. Um, it's the same issue where some, at some point your basic, your job is to.
Either find problems that the business already has or like surface them and then solve them or just your handed problems and your job is to solve them. Um, and that's just that's just gnarly work.
Aaron Rackley: Yeah, but I find it very fun. Me
Lena Reinhard: too. I love it. But it's it's also initially you can basically think [00:29:00] about it in this.
Yeah, exactly. You can think about it like with an engineer where like a junior needs very well scoped tickets. Um, with very clear acceptance criteria and all that and like nothing against acceptance criteria. But at some point, if someone wants to become a tech lead, staff engineer, so you would expect that you can basically tell them, Hey, there's something wrong over there.
Please figure out what it is and fix it. And so it's the same thing with leadership. So give yourself time, but also. Don't let that block you or keep you from that work because it's really good work. I'm glad you mentioned that Shouldn't just talk about the hard part
Aaron Rackley: Yeah, I want to do an episode at some point which is like, um engineering management 101 like the first thing here's like a Blueprint of the 30 days things you need to learn from tech going from just being a tech software developer into that role, like what is the scary bits that you're going to encounter?
And it's like, cause you've spent all that time learning how to do the latest software, the latest repository, everything. But now it's like, Oh, there's this whole other books you need to learn. [00:30:00] Yeah.
Lena Reinhard: Yeah. And, and a lot of it basically is, there's just nothing has clear answers anymore. Right. Your job as an engineer is to basically Breakdown ambiguous, complex issues until they are not ambiguous anymore and you can code through them and Boom, it's done.
And I know that it's a hard job and it's a complex job, but in our line of work, that just barely exists.
Aaron Rackley: Yeah, yeah. Yeah. So we've mentioned Dora as a, as one of the kind of resources you can use. Do you have any other tools or resources that you could recommend for like gathering and analyzing this kind of data?
Mm
Lena Reinhard: hmm. Um, you mean more. for, essentially, you have the Dora metrics and you want to figure out what to do with the results,
Aaron Rackley: or? Yeah, let's go with that one first, because it's obviously, we've talked about it a lot, so it keeps it in the frame
Lena Reinhard: of where we're at. Mm hmm, yeah. Um, I mean, honestly,
I don't know. It's [00:31:00] like in, you know, beyond, beyond the whole, um, look at the metrics. Mm hmm. I'm a big fan of calendar events and reminders because my brain just, uh, otherwise doesn't function. So, you know, if that's you or even if it's not you, maybe it's worth a try, but have a weekly reminder in your calendar to look at your team's metrics.
Um, make it part of your team meeting, um, or team planning template. Um, so you talk about them every week and then, or also talk about them during your retrospectives. What are the things that you've learned from them? How do you want to deal with these lessons learned? Um, involve your stakeholders. Um, so if you have a product manager or then again boss, um, you may have to talk about, you know, hey, we, for example, realized our deployment frequency has gone down.
Here is what we think is an issue there. Um, here are the things that we would like to do. How can we prioritize that work? Um, because metrics are going to get very demotivating very quickly if you're just seeing that everything's on fire and [00:32:00] no one has the capacity to do anything about it. Um, and so involve your stakeholders, um, and.
And honestly, that's, that's pretty much it. Um, I don't know if you were thinking of anything specific in terms of No, no, no, that's fine. That's fine. I
Aaron Rackley: just wanted to, to gauge what you think. Yeah. Um, I think one last question then is, we've just spent all this time telling you why we think you should use metrics, but what is the last bit of nugget you would give to someone who is just Listen to all this, but they're still hesitant to want to do any metrics.
Like what, what would your one motivational sentence be?
Lena Reinhard: I'm afraid I can't boil it down to a sentence yet. Okay, thank you. So my first question, and I honestly I hear that a lot from, especially managers who are just moving into the [00:33:00] role. So my first question at someone in this position, basically, what are your concerns and where do you think those concerns are coming from?
Because in my experience, honestly, a lot of managers are. Um, scared of what introducing metrics is going to do to their team and to their relationship with their team. Um, a lot of engineers have made bad experiences with managers in the past and have dealt with, you know, feeling micromanaged, being micromanaged, um, or feeling like metrics were used against individuals, um, instead of actually as a tool to learn, um, things like that.
Many engineers have made experiences like that, unfortunately, um, but that also means. Maybe that's part of why you're concerned or you're concerned of becoming a quote unquote bad boss or, you know, someone who's annoying their engineers. Or it's you're in a company where that's not really part of the culture.
And so it feels weird to be the person who kind of [00:34:00] introduces that. So digging into basically what's your hesitation, where is it coming from? Um, and, um, validating that. So especially if your concerns are about, you know, how will your engineers react? What's it going to be like for them? Speak with them, say, Hey, you know, and, and as part of that dig into.
Why do you want to use metrics in the first place? Because, of course, it gets thrown around a lot. We all say it's kind of important as part of visibility and situational leadership for a team. Sure, that's all true, but that's also very abstract. So, like, what makes you think that metrics would be helpful with your team at this point in time?
And then go into a conversation with your engineers about that. So, for example, say, hey, you know. Hey, teammates, I would like to get a better sense of how we're doing just for us, um, and I would get a better sense of what I can tell the business about how we're doing it. For example, to help convey that our productivity is improving, even though we're all distributed.
Um, [00:35:00] dear teammates, what do you think about this? What does it bring up for you? Um, what concerns do you have around it? Um, so basically. Don't just keep it in your head, but especially if you're concerned about wanting to protect your teammates, um, which is very, um, very good intention, um, validate those things and speak with people and at the same time, you know, you can still say, Hey, I do believe metrics would help us get better if there's hesitation on the team, you can speak with them about, you know, what What would those metrics look like?
What would, what kind of practices around those help the engineers feel at ease or would actually help your teammates get use out of those metrics as well? Because of course, like no one likes to measure a bunch of stuff that in the end, no one will care about. Um, or that again, like no one will be able to do anything about.
Um, so I would start there. Um, because honestly, a lot of, I mean, all of us have made experiences in our workplaces. Not all of those were unequivocally good, unequivocally good at all times. And, um, That also means that we all [00:36:00] have some baggage and we bring those, that baggage and our own ideas about how people react and what not into the workplaces that we're in and into the teams that we're running and that's okay.
That also helps us because it also means that it's part of our instincts. Um, but the thing is that our instincts just aren't always right. And so, um, I think reflecting on the idea of why are you doing those things? Um, why do you find them important and how can you use them and do them in a way that is in alignment with what?
Matters to your teammates. Um, and how can you do this? Well, together, I think is a really good starting point.
Aaron Rackley: No, that's that is absolutely great questions. Yeah, I I am obsessed at the moment of just trying to understand all of All Dora, all metrics, all this kind of stuff. I like to analyze problems. I like to try and figure out where the bottlenecks are and I think it's a great tool to get there.
Um, so I appreciate you coming on to talk about it. [00:37:00] One question I'd like to ask all our guests and I don't know if you saw this, but I'd like to ask our guests to recommend a book which I'll Buy and put on our bookshelf and it doesn't have to be tech it can be your favorite childhood book It could be anything but if you could offer one book for someone to read What would you recommend?
Lena Reinhard: um, so my recommendation is not tech at all. The book is called Into the Planet by Jill Heiner. Jill is a Canadian cave diver and writer, photographer, filmmaker, and one of the first things that I think she says in, this is her memoir, and one of the first things she says there is that she's She's specialized in cave diving, and if she has an accident during her work or during this cave diving, there are three people in the world who can Come to her help.
And one of those is her ex husband, which I, which I just think is a really good preface. [00:38:00] So she's, she's incredibly good at what she does. I'm not a diver at all. I snorkel or dabble in snorkeling rather. But I don't think that's ever for me and I'm incredibly fascinated by the work that she's done and by her career because she's One, I mean, exploration is just a really fun topic.
And, um, the work that she does is incredibly complex and difficult. And there's so much about understanding risks and still doing what you're doing, just carrying those risks and also like working with other people to build a setup where those risks. are at least managed. But at the same time, there's no 100 percent certainty in it at all.
And so the book is called Into the Planet, My Life as a Cave Diver. It also includes a bunch of beautiful photography from her. So if you're not into digital books, I can recommend getting the paper copy because they're just Bye. Phenomenal. Um, so yeah, that's, that's my book.
Aaron Rackley: Awesome. I'll add it. And yeah, as you say, cave [00:39:00] diving, definitely scary.
I've watched some videos and the preparation, preparation, preparation.
Lena Reinhard: Yes. Yeah. Yeah. I'm not, I, yeah, no. I'm curious to try a lot of things, but that's, there's a hard line.
Aaron Rackley: Awesome. So before you go, um, Where, if anyone wants to find you online to talk more about this, where can they find you?
Lena Reinhard: Yeah, I have a website.
It's LenaReinhart. com. You can also find me on LinkedIn. I have on my website, um, bunch of articles, including about metrics and how to make them work for you and your team. Um, and the whole topic about, um, pushing information to your boss. Um, I try and, um, release a lot of sort of actionable things that you can walk yourself through and then.
Tailored to your situation and figure out paths for yourself, um, forward. And I think, yeah, website and LinkedIn is currently the biggest ones. I'm post X, but still haven't found a place to go.
Aaron Rackley: Well, I'll make [00:40:00] sure they're in the, um, show notes anyway. Thank you. Thank you
Lena Reinhard: for coming on. I loved your questions.
Thank you so much for having me.