Introducing metrics to an engineering organization with Lena Reinhard

Rebecca: Hi Lena.

Lena: Hi Rebecca.

Rebecca: It is so good to see you again. I haven’t seen you in 10 years and then I saw you for five days in a row a couple of weeks ago.

Lena: Yes, and now I’m seeing you again here. I’m really excited to talk to you because I’ve been meaning to speak with you about this whole topic for a while; sitting here like this, I’m very excited.

Rebecca: Me too. We have lots and lots to talk about. I was trying to catch up on everything that you’ve done since I saw you 10 years ago and there’s a lot. Tell me a little bit about what you have been up to and what you're up to today.

Lena: Well, honestly I am still trying to figure out who I am, including in the business context. But that also is part of the work that I do now, I guess. So, first of all, I’ve been working for almost 20 years now, which makes very easily a lot of things. I got started in finance, wanted to become a photographer, my parents made me work at a bank… That’s how I had the not-super-unique pleasure of working at a bank during the 2008 financial crisis, which was interesting and also very helpful again now in the work that I do.

Who would have thought, and then I — very accidentally — got into tech. I had my first startup job in a very small SaaS, 10-people, everyone-does-everything company. I did a lot of open-source work for a couple of years. I was and I still am an official contributor to Apache CouchDB. I’m just very grateful they don’t take those badges away from you once you’ve earned them.

But as someone who doesn’t have an engineering background, that was my pride and joy. I did a lot of marketing work for them, community building, things like that. And then ended up co-founding a startup and where that business background was quite useful.

That’s also how I got started in management because we were bootstrapped and had to do consulting work, kind of quote unquote “on the side”, which means as a full-time job while you’re also full-time building a product. So I was there then went on to become VP of engineering at Travis CI, and later VP of Product Engineering at CircleCI. Did hyper-growth with them for three years. And now for the last two years, I’ve been doing coaching, consulting, advisory, organizational development, and a lot of just individual work with organizations and leaders. And ultimately what I really do is basically helping people and organizations navigate complexity and do great work despite and with that complexity, I guess. So the fun stuff.

Rebecca: Well, part of the reason I wanted to talk to you today was because of that background that you have in developer tools. And I know you've recently been writing a lot about stuff that I care about quite a bit around metrics and using metrics in engineering teams. So hoping we can talk about all that and more today.

Lena: Oh yeah.

Rebecca: Maybe start out with what drew you to developer tools. I kind of wandered my way there through the front end. You wandered your way there through a bank.

Lena: And the front end actually!

Rebecca: How did you gravitate toward developer tools or was it purposeful or just happened?

Lena: The main reason I got into dev tools was because people asked me to bring my business expertise to help them get a software product off the ground.

I didn’t really get into dev tools. I just, honestly, needed a job to pay my rent, and I liked the people I was going to work with. I already knew them from the open-source work I had been doing. And then I stuck around. I think I did dev tools in some shape or form probably for eight years.

I do love the whole idea of it — I mean enabling people and understanding what they need to do great work and be successful at what they do and enjoy it. Ideally, that’s fun work, and I think it’s a great honor and pleasure to be able to do that kind of work.

And then, especially later on, first SVP of Engineering with Travis CI, when we were about 50 people in engineering, then at CircleCI at some point over 200 engineers alone. And then, you’re in a position where you’re building a product that you’re using yourself, but you’re also building it for a much greater magnitude.

Just the impact is so incredible and hard to fathom, and so that’s honestly one of the reasons why I also stuck around for it. And of course, there’s the whole discourse of what makes humans productive? How do people exist in the workplace? That’s something that’s always really interested me, both from an individual perspective, but also in terms of how to build a team and organization where people can do their best work, and what role can tools play in that?

Rebecca: You’ve been in a ton of leadership positions, and now you’re coaching leaders. One thing that I know is hard as a leader, especially the bigger your scope becomes, is just maintaining situational awareness of what’s even happening in your organization.

This is probably really easy when it’s you and your four friends, and it’s probably a lot harder when you’re trying to understand what’s going on with a couple of hundred engineers.

What have you learned? What have you done wrong? What do you do right now? What do you do correctly today?

Lena: I love that you call it situational awareness because I usually just frame it as visibility, but I love the specificity of situational awareness because that very much dives into what I tell people about and have also learned about it, which is that it’s a very situational thing. Basically, you need to be on it at all times.

So what have I learned about it? Honestly, first of all, to your assumption that this is easier to do with your four friends, it can also happen that you learn at some point that you were not as aware as you thought you were. I think the first point that I’d probably start with is what is the point of situational awareness? Coincidentally, I’m working on an article right now about my favorite metrics and spent a lot of time thinking about exactly that yesterday. And I think there are two big purposes.

One part is that, of course ultimately there’s me as the leader of the team and my job is to at all times — first of all — have an understanding of how we are doing in terms of spending our money. Are we achieving our goals? Are we creating waste along the way? That’s the whole effectiveness efficiency stuff. As part of that also how are the people doing?

As for the second part, though, I think situational awareness is not just for me, and I think that’s an important part of it. If I’m the only person who has a sense of what’s going on in the organization, that’s a problem. To me, the whole point of situational awareness — and the tools that I use for it — is about creating the culture that I want in my organization. Because having visibility, all of those things are also tools to create accountability, to make sure that we're all aware of what everyone's doing. Of course, not to a point where I need to be on everyone and micromanaging everyone at all times, but generally, we have a sense of what’s going on.

We have the situational awareness and there’s the culture of continuous learning. If we don’t know how we’re doing, we will not be able to improve and all that. And so I think even just breaking those things apart. And then I guess one part is about me — and just me — doing my job. And the other part is that in itself it is also a tool for how I build my organizations.

I think the first part is just understanding that visibility and situational awareness is your job. And when I say your job I don’t just mean someone who has a formal leader or manager title. I honestly think, especially if you’re in an organization that has somewhat run along the lines of modern DevOps principles, visibility is everyone’s job. If the visibility isn’t there, that is a huge flag.

And that also means, for example, if you’re a junior engineer, you should still have visibility into what your team’s goals are, what your team’s metrics are, and how you’re doing against those goals. Ask for that visibility if you don’t have it.

So that’s honestly the very basic starting point, and that sounds so basic. But at the same time, I mean, I’ve done a lot of organizational development at this point, and most startups, scale-ups, even corporations that I’ve worked with, that in itself, honestly, is the first very big goal, and that can take a year to even get some rudimentary visibility even into place.

Especially if it’s visibility that’s not just for example about the company finance, because, let’s be honest, finance teams are typically really good, but a lot of engineering organizations are just terrible at it. There are so many reasons and making initial investments, basically, what do we even know about our systems, about how things work, about our architecture? Honestly, even in growing organizations, first of all, retaining someone who can speak to the architecture and maintain an up-to-date architectural diagram is a part of visibility and can be one that can be incredibly hard to do.

I’ve worked with several teams now where we would maintain a Zoom recording of one person walking through the architecture of our system. That would be the thing that would get shared during onboarding. And then in a good year, we would be able to update that every three months.

Visibility is my job. What visibility do we actually have, and then, in the first place, the biggest visibility goal is often to just get from no visibility to some visibility. And then the next step is usually understanding, “Oh, now we either see way too much, we're getting swamped with errors that we’re not going to be able to address or whatnot”. But then you can start sorting things out from there.

That’s the more implementation focus side. The other side for me, if I come into an organization, I usually run an assessment of how they are doing. Where are things at? And visibility for me is usually probably at least 60% of that, because even the question like “What metrics are you all using to run your company or to run your engineering organization?”

How are those metrics discussed? Do people speak about those? Who has access to them? A lot of organizations are weirdly cagey about not wanting metrics to be shared down to lower-level line managers, which I think is absolutely terrible because those are the people who are deciding how everyone spends their time every day.

They have a fricking huge lever for efficiency, productivity, and all of those good things. As part of that, also, how are your goals set? How do they roll up? How do you tell? How far you are in with your quarterly goals, for example. All of those really rudimentary questions are usually incredibly good signals about how an organization is doing because, ultimately, having that visibility means that you have a grasp on how your organization is performing, which also means you can take action if it’s not performing the way you want it to.

One of my favorite questions to ask when I run those assessments is what happens in your organization when goals aren’t met. And, honestly, typically the answer is just nothing, and then of course, I ask tell me more about that. Do you just continue to pretend that that didn’t happen?

I found that visibility is such a wonderful starting point for pulling threads on an organization’s wellbeing and then seeing the whole thing unravel. Also at the same time, when it’s not working, visibility can also be a really powerful tool for building an organization, for building the culture you want, and getting the productivity and the goal achievement that your business needs.

Rebecca: What you just said, on the one hand, sounds obvious, but it doesn’t sound easy at all, especially if you have an organization that hasn’t been investing in any of that. Then there’s this stuff that is relatively easy to invest in when you’re small and gets a lot harder to invest in as you get larger and larger. On the flip side, the problems of not having visibility don’t necessarily show up until you’re at a point where you are probably full of regret that you haven’t done anything about it yet.

How do you help organizations reshape their priorities and reshape how they’re thinking about work so that they get this stuff in place and don’t just keep developing product blindly?

Lena: Good question. I found that the answer really just depends on essentially what the pain points are for the company leaders. I found that especially higher level leadership teams need to figure out where the pain is felt. Otherwise it’s going to be really hard to get those kinds of really large changes in motion. Honestly, at some point you’ll probably have your finance person come to you and say, “Okay, here’s all the engineering money that we’re spending. Here’s your budget. It’s a chunky number. It's a big boy — as they say, I used to work in finance, I know the terms. Are we getting out of this money, what we thought we would spend?”

That is typically when you have a bit of a problem because you probably have no way of answering that question aside from, “I guess so. We could have done worse.” Then you start pulling initiatives, and start talk to your product folks and whatnot and start justifying the investments that you’ve made retroactively. That point comes for many businesses at some point, especially if you’re a scale up, you’re trying to go public. There are a lot of things that just need to happen in terms of regulations and whatnot, where visibility is just an important part of it.

It’s a good pointer that there are state regulations in place for visibility because it is an important thing. So figuring out the pain point, finance is often one. Another pain point is often just that a leader can’t — basically isn’t capable of — continuing with things anymore because they’re not getting the same budgets they used to.

At the moment, that’s a big issue. A lot of engineering budgets have been cut — even just development budgets — so a lot of it just often comes down to money and figuring out basically what are the pain points and what are the things that are going to actually motivate organizations to change.

But I focus mostly on high level leadership right now or so far. I always find it really important to look at essentially the low levels of the organization. So when I start working with orgs, one thing that I do is basically run interviews through all levels of the hierarchy and speak a lot to individual engineers, as well as line managers for single teams. This is because improving visibility can — and I think at some point has to — be an organizational focus, and you’ll probably have to invest some time and money and tooling into making this happen. But you’ll never get there if you don’t take the people in your teams along.

And now the thing is typically by the point that high level leadership members complain or have concerns about low visibility. That’s the lagging indicator meaning those are usually some of the last people who feel it. The pain has very likely already been felt for a really long time at low levels in your organization.

How’s the pain been felt by engineers getting woken up in the middle of the night unnecessarily for production issues that they haven’t had the budget to fix, or haven’t had the skills, or haven’t been able to coordinate work with other teams. Or the pains been felt by just everything taking forever because there are too many dependencies in your system and teams have to work together way too much. Or the pain’s been felt just in teams and feeling like they aren’t getting things done because they have to wait 10 hours for a build until they can actually get things done, get things live.

The daily paper cuts, your teams have likely been feeling those for a very long time until you’re actually aware of them. I found that understanding what are the actual things you need to go and ask the teams because teams usually have a list of things that they would love to tackle and that list is very likely also going to be very tightly connected with your visibility problems. You’ll just have to make that connection.

Rebecca: How does that happen that leadership becomes so disconnected from what’s going on? You talked about it being a lagging indicator when leadership realizes. What are some leading indicators that people can actually be on the lookout for to say “Oh, we have a problem here?”

Lena: To the first part of the question of how it happens: A lot of scale-ups have gone through that in the last couple of years, right? They’ve just grown very, very quickly. Oftentimes in higher levels of leadership, you have folks who don’t have a ton of experience, don’t know what good looks like, don’t necessarily know how to train other leaders up, and don’t know how to basically operationalize situational awareness.

What metrics do I need in place at what point in time? Probably you know DORA metrics, great framework. Do you need them when you’re 20 people and just trying to figure out product market fit? Maybe, maybe not. A lot of things are overkill when you’re early stage, but then — as you said earlier — at some point you probably realize that now you need it and it’s kind of too late.

If you don’t manage to bring in discipline quite early on, and with discipline I mean process discipline and good leaders, but also both from a technical and people perspective at various levels who are able to bring in some structures who know what good looks like.

And who basically managed to create visibility upwards and downwards throughout the organization using metrics but also just having the right conversations. Then I think it’s very easy to become very blind, because ultimately — also from the flip side, I don’t necessary blame executives there to say — a big part of that job is leading at a very high abstraction layer.

That’s what makes it very hard in a lot of ways and makes it very easy to, for example, decide mass layoffs. Because then you’re at a high abstraction level. That’s just how these roles are designed. And so I think unless you’re really making early investments and those are the right investments — and a lot of companies have just struggled with doing that — it’s honestly very easy to miss.

And to the second part of your question, what kind of leading indicators should you look out for. Honestly, just like for me, the question is how much do I feel I have a grasp on how our organization is doing. For me, that is one of the most important ones.

Obviously I have a bunch of experience now that feeds that kind of instinct, but it’s not just that. For example: Sure maybe we don’t have a ton of metrics that we’re using yet. It’s fine. But are we on track with getting those in place? Is everyone in our teams actually using metrics to make decisions? Are they using them to improve? Do they feel they have control there? Do I have confidence in the direction that we're moving in? Do I feel I have a good sense, or we have a good sense as an organization of the risks that we’re dealing with and how we're tackling those? Ultimately I think it’s about do I have a sense of what’s going on and then do others.

If I feel I’m confident in what’s going on, my boss says, “Well, Lena, hell no!” then well that’s a good conversation starter. Or same with my direct reports. I think honestly, that simple question is just a really good place to start because if there's going to be a breakdown somewhere, you're going to have a conversation with someone who says, “Yeah, I don’t think I know what's going on.” And then you can figure out why that is.

Rebecca: So we agree that metrics should exist. There’s no question about that and that they’re really powerful when they do exist. What have you seen as far as successfully rolling out a metrics program? Maybe I’m making too big a deal out of it, but I definitely know that developers can feel watched if you start to watch them and start to assign numbers to something that they consider perhaps a more intellectual endeavor. What have you seen work to start to introduce these in a way that’s actually healthy for the organization and doesn’t freak out the people who are being measured?

Lena: I’ve worked with a lot of companies on that and I’ve also dealt with a couple of them where people were basically actively refusing and threatening to quit if that metrics thing was going to go through. And I will say there were cases where ultimately leadership decided that they didn't feel it was worth it. I didn't agree with that decision but that's a story for another podcast.

Rebecca: I'm actually curious about that though. Cause one thing that people often ask me is how do you do this in a low trust environment, cause maybe that's the most interesting thing. If you're in a high trust environment and it's a small company, then this is probably pretty easy. I think where it becomes harder is when you don't have that trust built up between leadership and the folks.

Lena: Honestly, I found that basically the whole “we want to introduce metrics” discussion — even in most cases — turns like a self-described high trust environment into one where there’s at least a bunch of doubt about how good that trust actually is, and — I will say — understandably so. I think with all of this, there are just two parts. There’s one part where there are just no guarantees. If I as a leader in an organization tell people “I’m not here to weaponize this against you, yada, yada.” Sure, but also am I going to be around forever? What about the next person who’s coming and what are they going to do with the systems that are in place then?

I think there is a part that just can’t be sort of negotiated or change-managed away, and I think that part is very justified to be part of the conversation. That’s why I honestly treat any metrics rollout as basically one in a low-trust environment just because people will have concerns.

There are also legal implications depending on where your company is operating. You have a variety of different requirements in terms of just what people are legally required to be made aware of when, when data is gathered about them. I think that’s a good thing that there are these kinds of legal protections in place. But there are these foundations where you can’t just YOLO your way through a metrics rollout. You shouldn’t YOLO your way through a lot of leadership things in general, but that’s just my free advice today.

I’m a big fan of basically change their influence. Like Esther Derby’s done a lot of really great work there. The first thing that I find incredibly important to understand is why the heck do we even want to do this, and that’s so easy to forget. Metrics are not the solution. They are a tool to solve a problem, but in the metrics — and it’s metrics with a capital M and a capital E — and whatnot discourse that easily gets forgotten. They are a tool. What is the problem you’re trying to solve?

I know I say a lot of basic things today that just from my experience I know are very hard to do, and this is one of them. Yes, I’ve gotten mandates from my bosses — or from whatever oversight, committees or whatnot — to track certain metrics, where it's basically, “Well, we have to know this metric, period.” That that is also a problem to solve. It’s not my favorite way of defining a problem statement, but “My boss really needs this for their reporting” can be a problem statement. But really scope out, what problem you’re trying to solve? Are you trying to be better about your spending and what does that actually mean? Define those things and define those things as a leadership team.

I think the other part — is one of the reasons you and I are here to talk about today — is figure out as part of that, what you want to use the metrics for. I love teasing apart metrics based on whether metrics are for a group or whether they are about a group. Metrics for a team are essentially metrics that the team uses themselves to make decisions, improve how they’re doing, iterate together. They review those metrics regularly, they know them. They see how the trends are going, and the metrics are a tool for the team. I found those metrics really crucial. And the same, you can do that at an organizational or domain level, doesn’t matter. It works anywhere.

Giving a group metrics as a tool to solve their problems can make a metrics rollout a lot easier because, ultimately, metrics shouldn’t just be a thing that you use to basically monitor your employees — or actually they shouldn’t be that at all. Metrics should be a tool to help you get visibility or to be more mindful of your spending or whatever else you want to do. And they can be a great tool to help team self-improve. Use them for that, which also means rolling out metrics can also start with, first of all, where do we have pockets of trust?

To the low-trust conversation earlier: If you don’t have trust in your teams at all, then you probably shouldn’t think about metrics, but redoing your entire organization. Let’s assume you have trust somewhere at the team level or in sub-teams. There are some pockets that have trust. People start talking about where do they lack visibility? What are the things that they wish they had more insight into? Where do they actually feel a need to have a better grasp on how they’re doing, how things are going, or even on what’s getting in their way. A lot of engineers love getting blockers removed because it’s annoying, it’s bugging them.

Finding the pockets of trust, understanding the problems that people are facing there, and how those problems line up with the ones that you’re trying to solve at a higher level when it comes to visibility. That's probably the biggest one. Quote unquote “metrics rollout conversation” shouldn’t be a metrics rollout conversation, it should be a conversation about the problems that we have as an organization and metrics being a part of addressing those.

I don’t want people to just randomly monitor my keystrokes. And that’s the other thing: define the problem well, work with people at lower levels to understand what problems they’re dealing with, figure out how metrics can be part of that. People will likely also need other things that aren’t just metrics. For example, I’ve run a lot of product engineering teams, right? We needed more help from the product teams. We also needed better alignment on how many technical investments we were able to make in order to get, for example, less interruptions on our work. So make it zoom out. Make it a bigger thing and don’t just make it about rolling out metrics. And as part of that, that also means you need to arrive at things that are meaningful.

My favorite example is employee engagement. So many companies now run employee engagement surveys, generally a decent idea. Most companies that I hear from run these surveys. And then I asked them, what do you do with the survey of results? And they’re like, “Well, nothing. We review them as a leadership team, or HR reviews them, and we as a leadership team don’t have access to them.” And that is absolutely terrible.

Employee engagement can be such a helpful metric. What happens is that people actually submit that information. I love reading employee engagement services, so insightful. People have really good ideas. But then if you don’t actually use this metric and using the metric means you play back to people what you’ve heard in this case, you run a meeting, you say: Here’s what we’re hearing from you. Here’s an aggregate, here are the patterns. You tell people what you decided to do with it. Here are the actions that we’re going to take. Here are the things that we won’t do anything about, dear employees, because we can’t, we don’t have the budget — whatever the reasons – here’s why we made those decisions. Here’s what’s going to come next. Here are the next steps that we’re taking on this. Here’s how you hold us accountable. Here’s also how you give us feedback on how we did this whole process.

That’s how you use a metric. And that’s the same thing with whatever the metric is, but if you’re not actually using it — and I do think that’s where metric rollouts are a great example. Let’s say you’ve been doing these employee engagement surveys, nothing happened with them. How should people trust that you’re going to make better use of other metrics that you’re rolling out? I think as part of that, it’s also worth taking a really hard look at how you’ve been running your organization so far.

The whole leading by example is another very basic thing, but I think there’s a lot of power in you as a leadership team starting to use the metrics that you already have, because likely you have one or two things that you’re looking at on a regular basis. Or even just saying, “Hey, team, I wanted to share with you here are things that we’re looking at as an executive team on a regular basis. Wanted to make that transparent.” And then you talk about that next month again.

I think it’s also about building culture where people have an interest in those things. There’s so much more that you can do than just starting with, “Hey, we’re dropping our big bucket of metrics. That’s the hammer coming down now and now deal with it.”

Rebecca: Sounds like you’ve had a lot of opportunity to experience this sort of thing firsthand. Tell me about a time that maybe it didn’t go so well.

Lena: Full disclosure, I have a couple to choose from. The one that I think I learned most from was a company I’ve worked with and I’d been brought in in middle management-ish position. One of the reasons they had brought me in was that I had a lot of prior experience — including with professionalizing organizations, introducing that discipline that I mentioned earlier in terms of process, situational awareness, visibility — and in hindsight, I realized they were trying to undergo a culture change. At the time I didn’t really get that, to be honest.

I was still quite inexperienced myself in a lot of ways, but still had more experience than a couple of other people I was working with. So what happened was that essentially they tried to roll out OKRs for the first time — that was at a time when OKRs were still quite new, still hyped — and the whole thing went sideways, basically immediately.

Employees were — outraged is probably an understatement… were not happy. The management team became divided about it with some people who basically took the employee side and said “We should just not measure, we should just trust people that they’re doing the right thing and that they’re doing the work.” The leadership team fighting became sort of trickled more into the organization, and became more known and the whole thing just went completely off of the handle. In the end, basically none of that happened. The teams kept working the way they had prior. The company didn’t recover well from that kind of dispute is really an understatement. So that worked really terribly.

It’s been something that I’ve been thinking a lot about in the last years because it’s been a while and especially what are the things that I could have done differently and how could I have bridged gaps or navigated those if I had a bit of a translation function between higher and lower level leadership?

One big thing that I just learned from that is ultimately how much the context matters. When I said earlier a couple of times things like, “Hey, it’s not about the metrics. The metrics are a tool. They’re not the solution.” Similar with process. I mean, we love our frameworks, but none of them matter. What matters is that people actually understand what you’re trying to do and that you understand what you’re trying to do. Especially as a leadership team, the fact that we weren’t all on the same page about it, wasn’t helping. I make a very conscious effort with even when I just come in as an organizational developer, for example, or as consultant or interim leader: we speak with one voice because otherwise it’s just not good leadership and it’s not going to be helpful.

And I also think we should have done much more work early on to basically understand what the actual problems are that the employees are concerned with. As I mentioned earlier, find the pockets of trust. Understanding what are the impediments that engineers are dealing with. What are the things that could help them? An OKR process or metrics… how can those be part of the equation?

Honestly, having those conversations with open mind. If I go in to chat with the team and basically already know at the back of my mind — I really just want to convince them that they really need to use DORA metrics — it’s not going to help my listening ear. It’s about having genuinely open conversations and really trying to understand. I think we should also have been — to your whole point about situational awareness — much more aware already. Initially affect how big this topic was going to get. That we would either need to prepare much better, in terms of actually making this a much longer process, involving people much more in designing what this would look like, what and how metrics would be used, maybe policies and guardrails that they would want in place to prevent misuse things…

Those are all things you can do to make it a much more collaborative thing and less a thing that sort of kind of dropped out on them. Or we should have decided to basically — if worst comes to worst — accept that, for example, part of the employee base was going to resign. We should have been much more aware of the risks and also of what price we were willing to pay.

Rebecca: Thank you so much for sharing that. I know it’s not always fun to reflect on those mistakes of the past, but we learned from them, right?

Lena: Lessons learned. Yes. I think I’ve learned a lot especially in terms of how to actually roll out metrics and similarly large changes. How to roll those out well and in a way that actually gets people excited and on board. Cause that’s the thing that we’ve been talking a lot about: sort of the downsides and the parts that are tough with this. But metrics can be so valuable for having the right conversations and for getting people excited.

And that doesn’t just include fricking executives, but also engineers and teams. That’s possible even in an organization where people are just more hesitant or they’ve made bad experiences. I also don’t want to gloss over that part.

Rebecca: I love metrics and I know you do too. Lena, it’s been just a delight to talk with you again. Tell me where can people find you if they want to know more about you or get in touch?

Lena: Find me on LinkedIn. This is such a weird thing to say, but that’s currently the best place I have. Well, I also have a website. It’s lenareinhard.com. On the whole metrics topic, I have a new workshop series coming up. January is when the first cohort is going to start. You can still sign up. I’m doing a workshop about maximizing team impact and efficiency.

Rebecca: Well, thank you again so much. What a treat. And I hope I see you again sometime soon.

Lena: Same. Thank you so much, Rebecca. It was a pleasure.