I was reading one of your posts about code owners and you have an aside in there that the code owners file is basically lawful neutral. And I was thinking like I was I was trying to think about what is it? What does that mean? And so, you know, I went to go. Well, I mean, I know where it comes from, but like it's when you think about Dungeons and Dragons alignment, things aside from the extreme ends, things get a little confusing. I think I think everyone knows what lawful good is. Neutral is a little confusing. You know what chaotic good is, the one that everyone chooses. And you know what what chaotic evil is. Yes. And and like everything else is kind of up to interpretation. And so like I was realizing lawful neutral is maybe the most confusing one. And so like like what is your understanding of what lawful neutral is? Yeah, I guess like in the context of code owners, it's like having the file there is a neutral thing. It's like lawful, right? There's no. It follows the rules. Yeah, it follows the rules and it's not in and of itself good nor evil. It's just there. But it's all about the implementation and what you choose to do with it that takes it somewhere else. And, you know, I've seen teams use code owners as a form of documentation and that's all it is. Great. I've also seen teams don't they don't let anything get merged unless you have, you know, two reviews from someone in the code owners file. Those teams are generally a little less healthy in my observation. So I don't think I don't think inherently, you know, the idea of a code owners file where you're listing out, hey, this person has the most subject matter expertise about this thing or they're responsible for this component because we can dig into some like team topologies sorts of things and cognitive load. And, you know, is it a best practice to limit the surface area that a group of developers should cover? I think that's an interesting conversation.
2:00And I think that ties into the idea of code owners. But I think the way code owners is often applied is like, I'm blocking you because this is my shiny thing and I don't want you touching it. And that would get you more towards the evil. Right. Because in the Dungeons and Dragons alignment system, evil means selfish. I think it's basically like it means kind of guarding, trying to drive your own value at the expense of others. This is my cave. These are my resources. Please do not enter. Yeah. Yeah. I do see we have just over your shoulder the same D&D set. That's right. I have that one right there, right back there. So I'm glad that we're in good company. We can talk about these things. That's right. Hence, when I came across that, I was like, oh, this is interesting. Something to pick up on. I mean, I think just to close out my commentary on that, when I was thinking about it, it made me realize that there's – that's the issue with the alignment system is it doesn't – it has very simplistic understandings of moralistic behavior. And so, like, you know, it doesn't – there's not really a lot of latitude. You know, if you're in some sort of societal system in the Dungeons & Dragons world and you are following the rules to it, but those rules were kind of, like, cruel, that doesn't necessarily mean that you're evil because you could think that they're good and you're following the right way of doing things. So, like, it's very – That is true. It gets kind of confusing. It does get a little dicey in there. I wonder what it would be like to kind of list out all of these, you know, methodologies for measuring developer productivity or developer performance on that matrix as well. Because, yeah, I think there's going to be a – I think there's definitely – and maybe that's actually a nice way to describe it is, like, from the stance of the business, which metrics and ways of measurements are selfish for the business because they have something to gain from keeping tabs on everything versus what is really empowering for the developer and gives up control. From the business side of things. Yeah. I think that's a whole – I think that's an interesting conference talk.
4:00I'll just put that out there. Anyone? And I think the perspective you brought into it is good, too, right? Like, the – it's really – when it comes to metrics, it's the alignment of the people who use them that really matters more than the people who are being measured by them. And, you know, I mean, that's, like – so, we were – you wrote some stuff recently about, like, technical debt. Or, you know, there's all sorts of words around it, like, you know, managing your legacy software and things like that. And as you're getting to, right, like, what I find interesting and what you were writing about in the technical debt sort of conversation is, again, that perspective of not necessarily the teams or the developers who are dealing with it. Because I feel like they know, right? Like, like – but I find what I struggle to live with, what I struggle to kind of comprehend is, like, why – to put it in a silly way, like, why it's an issue. Like, it seems like such an obvious thing that you would address technical debt. And yet, it's a huge issue out there. And I think a lot of what you are addressing is kind of getting to that point of explaining it to people. Like, kind of letting them think through it. So, I'm interested to hear you, you know, kind of go over how you explain tech debt to people where it's not immediately obvious to them. Yeah, I mean, I think this is all rooted – I don't know. Can we go back to, like, cavemen era? Like, this is all rooted in our displeasure with delayed gratification. Let's get – let's just, like, zoom way out here. And I think that's the trouble with tech debt is that you would look around and be, like, it's obvious that we should do these things. But there's something else that's going to give gratification more immediately. And as humans, that's just always our preference or the tendency of a business is to do the thing that's going to get more immediate gratification.
6:07So, you know, we were talking about how your office is a storage room. And, of course, I have this nicely manicured backdrop. But you could see that there's chaos everywhere in here. I know that I should spend some time tidying up my office. And it would definitely probably make me think more clearly and, like, be less, you know, less stressful for my life. But I choose not to do it because I can get gratification by doing something else. Sure. And, you know, I think there's a point where my office will become so untidy. Or if you think about cooking a meal in your kitchen, when you don't have any more pots and pans to cook with, you need to stop and do the dishes. And if you go into any Michelin-starred restaurant, that kitchen is going to be immaculately clean, just beautiful, regardless of how many people are in the dining room. And so there's, I think there's definitely some, something to talk about, like human motivation and what we're drawn to, what businesses are drawn to, that makes technical debt something that we know we should do, but something that's easy to put off. And I think the key to getting it front and center, because it is annoying, it's not fun to live with, is, like, you need to be able to express the value better to the external stakeholders about why this can provide more immediate gratification than building feature X. Yeah, I mean, I like the avenue you have into this, because, you know, not normally, but, like, one approach would be to start with the financial outcomes, right? Like, or risk managing it. But it is, you know, it's always nice to start with a, just like a real life analogy. I mean, you wouldn't buy a car and never expect to have to rotate the tires or change the oil or work on the engine or charge it or whatever it is that you have to do, right? Everything comes with a cost of maintenance and everything comes with a cost of operation.
8:10But, yeah, in software, we kind of forget about that sometimes. Or I think some people that are not coming from a development background don't see that as part of the deal. When you build something, you've got to maintain it. Do you think, like, where do you think that comes from? The, I mean, I don't mean this to sound in a whatever way, but just, like, not understanding the full lifecycle of software? Yeah, I think, I think there's, I think that there's an education point of view, like a gap that could be closed, certainly. But I think it's something more, I think it's something deeper than that. It's just pressures of the business. I, one of my, I don't, I don't want to call it a hot take because it's not a hot take. This is just, like, this is the way that I see the world is, like, only successful companies struggle with tech debt. Only successful teams struggle with having crap in production that they don't want in production. It means that there was so much pressure on the business that your customers and your users were wanting more that you needed to deliver rapidly. And you're still around to talk about it. There's certainly a lot of companies out there that have crap in production that are going to go belly up. That's, that's, I'm not saying that that doesn't happen. That does happen in that, I mean, I guess that should happen. That's the, that's the game we play. But there's this, like, you know, I talk about always the prototype that ends up in production. That's not a problem that failing companies have. Generally, that means that there was enough business pressure and enough demand for whatever it was you're building that you needed to iterate quickly. And, like, you found something that was working and you just had to run with it. And you had pressure to build something different or give your customers what they wanted and it ended up with, you know, suboptimal stuff in, in production.
10:10I would also love your take on this because I was reading an article or list. I think I was listening to a podcast. I can't remember what it was. But that tech debt has been miscategorized. And right now our understanding of it is, like, suboptimal choices that we've had to make to cut corners. When really the definition of tech debt is, like, building something in the best way but without full understanding of the problem. And then when the problem fully reveals itself to you, you need to go back and rework what you did before. Yeah. That is, like, I like that thinking of it because, you know, kind of as you were saying, I've tried to think of tech debt and legacy software. I mean, obviously, I conflate them together. Or I put them in the same room. Ah, really? Yeah, yeah. And the way that I think about it is I'm always, you know, with my liberal artsy background. I spend too much time thinking about words and what they mean. And, like, whenever someone says tech debt or legacy, it means they don't like it. Like, no one's ever, like, boy, I'm excited to go work on that legacy software. I have worked with one such developer in my career. Sorry to interrupt you. Oh, no, no, no. Go ahead. When he told me, he was, like, yeah, you know, just give me that old Rails application and just, like, let me have at it. Yeah, totally. I was, like, we need more of you. Yeah, you know, there's totally that mode you get in where you're just, like, I want to fix stuff, right? Like, I want to, I like your framing. I want that gratification of fixing something, right? Yeah. Like, I had to replace a, well, we have those silly, we don't, what do you call them? They're not doorknobs. They're French handles or whatever. Oh, yeah. We got those everywhere, which are terrible when you have a dog because then the dog can go wherever they want. Like, I'd love to put, I'd love to put knobs in at some point and just confuse the dog, see what happens. But, so I had to replace one of those.
12:10And, you know, of course, we here in the household are very comfortable with tech debt. And it lingered for many months and you replace it and you're like, oh, that was wonderful. And so I imagine there's that gratification. But, like, you know, I often think when someone talks about legacy software, you know, they call it that because they don't like it. Otherwise, they would just call it their software, right? Like, you put legacy in purposely to say that you dislike it. But the perspective that you're getting from that I think, and you were getting to this earlier, that I like is, at some point, this was actually not only good enough, it was the right choice. Yeah. So, like, and in fact, having been an application developer a long time ago and, you know, still talking with a lot of developers, there is a bit of too much perfectionism in the way developers sometimes think. And so it could also be the case that, like, what a developer calls tech debt is actually great to the rest of the organization. Like, you know, you could think in a different domain where, like, especially for developers, it's easy to think that meeting could have been an email, right? Like, things like that. Whereas, like, if you are the people who's, and I mean this in a positive way, whose job it is to be in meetings to run the company, you could think, like, no, that meeting was perfect. That's exactly what we needed. And so, I don't know. I mean, I think there's a lot of perspective that comes into play. Yeah, well, here's the thing, you know, I didn't pay cash for my house. I took out a loan, as most people do. Because, you know, sometimes you need to take out a loan in order to be able to do things. And I think there is an aspect of tech debt that we can kind of directly compare to, like, a financial transaction where, okay, we need to get to market with this thing, with this
14:12milestone by X, or whatever that time pressure is, or whatever the economic pressure is. And so, we make a choice to borrow against our future selves in order to expedite whatever it is we're trying to do. Yeah. The thing, though, is I can't just not pay back the interest on my loan. Yeah, it's obvious, like, what you've got you taking on. It's obvious the boundaries of that transaction there. It's like, I'm taking out a loan. And now, every single month, I'm going to pay back that plus an extra bit of cash, which is now becoming, you know, not so extra with insurance rates going through the roof. But it's very obvious that this is an obligation now. And I'm signing myself up for distributed pain across a longer term in the future in order to be able to expedite something now. And I think there are definitely times, and even myself and my own team, teams, I've been on teams that I've led, we've made a choice to do that. Because the benefit of what we could get by making that choice outweighed the cost of having to repay that debt over time. Yeah, yeah. Yeah, that's it. I'm so interested in your, the connection that you have of tech debt and legacy. Because I always say legacy code is revenue generating code. For sure. But you're right. Like, saying something is legacy is a value judgment in and of itself. We don't call things that we think are great. Legacy. It's always a slightly negative connotation. Yeah. And you're right. It is the, it's the thing that makes the money. Yeah. Otherwise, it wouldn't be around, right? Exactly. Yeah. Yeah. No, and I like the, the idea of, and that's what's intriguing about, you know, like some of the thoughts you've had about the type of thinking you've had about, we need a way of quantifying this, this, this technical debt, right? And it's, it's, it's trying to replicate exactly what you're saying is like you and, and I, you
16:18have to pay the interest. So you, you know, depending on how much you pay attention to this stuff and you automate your payments, but whatever, like every month, you know, you're paying interest. And if you think about it too long, you're like, I'm kind of paying twice as much as I should. That's, that's crazy how compounding interest works, but like, but it's, but you're aware of the cost of what you're doing. And maybe, maybe, you know, I think one of the frustrating things with tech debt is it's almost like that cost isn't apparent until it's too late. And back to what you're saying about, you know, more instant gratification. It's hard to, if you don't have to pay a bill, it's hard to express to people that there's a problem and like, and, and the thing I struggle with, with not struggle with, but that I find unsatisfying about tech debt conversations is when you try to come up with, you know, I'll use the word anyways, but a fake or a synthetic number that represents that tech debt, because it's kind of like, yeah, but you just made that up. And, and like the, the only, the only thing that is maybe hopeful that I can think of is I'm always very envious of like security people, because I feel like they're dealing with a very similar thing where they're like, nothing has happened yet, but it could. But it could, yeah. And when it does, it's going to be very expensive. Exactly. Much less expensive than fixing it now. And I feel like there's something we could not learn, but expressing the, the cost of tech debt feels like something similar. I'm, I'm, I'm not sure. Yeah. I think about it in, in a, in a lot of ways. I think at the end of the day, businesses speak money. And so if I'm working with a leader, coaching them to try to help advocate for tech debt project or tech debt time, one of the first things that I actually coach them to do is to stop using the word tech debt, because to an external stakeholder, to someone that you need to convince to spend time working on this stuff, tech debt just feels like, well, I don't
18:24like it. And I want a do over. It doesn't have great connotation in, uh, in a lot of contexts. It's hard to understand what's, what's meant by it. And the business value isn't clear. I guarantee you every other department, every other person has stuff in their daily working life that they would love a do over and they don't get to do it because there's business pressure and they need to move on. And what can come across as very unfair or even entitled from development teams is when, when there's this presentation of tech debt of like, well, I know better because I'm in the code, this is really bothersome. We need to fix it. Just trust me. And we don't expect them to come up with the same metrics, goals, outcomes that we would expect anyone else in the company. Um, and that's a disconnect that just needs to be resolved immediately. If we're going to make progress toward carving out time for these projects that are very important because they do affect developer experience. They add drag to development. You know, it's not fun to work in an environment that's full of broken windows. People will quit. It's expensive to rehire them. Um, there's a lot of business value to fixing these things. We just got to get better at talking about it. Yeah. I mean, you may be, I don't know. I mean, tell me what you think, but maybe one, one cool trick, so to speak, just like is to wait for urgency to make an uninvited call. Right. Like essentially like at some, at some point you might need to like implement as an organization, you might need to implement some feature or make some change. And at that point, if, uh, if there's a lot of tech debt, then it will become very apparent. You'll say like, oh yeah, well, we got to do this. We got to do that. Like there's all these things that we either, we either need to fix because we made compromises or we need to, I mean, there's another type of, I don't know if it's tech debt, but there's sort of like lack of agility that, that I think, I think, especially whenever you do, uh, I don't
20:24know what your experience is, but I feel like, especially during like the pandemic, this came up a lot, but even before that there was this desire to have like omni-channel retail. Right. And I remember like Gartner had like maybe eight combinations. If you take how you buy something, how you pick something up and how you return something. I think there's like, there's several combinations you can have of that from like in-store curbside online, blah, blah, blah. Right. Like all this kind of stuff. And so if you wanted to actually, as a grocery store, anyone selling physical items, which is what a delightful way to make money selling three additional objects. But like, if you try to apply that to your current way of doing stuff, I think you end up exposing a lot of lack of agility debt or something like that. And maybe at that point, it's good to say like, aha, tech debt, right? Like, and now let's start quantifying it. Yeah. I think that, that drag, and that's, I think a good, a good way to think about it is just like, it's friction. And it feels like you're just pulling a boat over like dry land sometimes, you know, and the water has been drained and you got to fill the water back in. But that loss of efficiency and effectiveness can be a really compelling way to advocate for projects that, you know, might also be resolving scalability, reliability issues, security issues, whatever it is, but also help accelerate development on the, you know, the feature side of things. I think that's always a compelling thing. I say, you know, everything comes down to money, but often time is a more compelling thing because even for, even for features that are brand new greenfield, it can be very difficult to articulate and to quantify and calculate how much, you know, revenue that that's going to bring, unless you have, you know, it's Amazon and you're fixing performance on the checkout page by however many milliseconds. And you can tell from your like, you know, terabytes of telemetry data that that's going
22:27to improve revenue by X percent or whatever. Most of us don't have that kind of data and most of our forecasts or calculations are, it's more than a hunch, no doubt there's data informed, but a lot of it is back of the napkin math that we can just hope is going to, going to play out. So if I can say, oh, this, you know, if we refactor this part of our, um, application and we're touching this thing, you know, once every month and it takes on average twice as long, I, I, maybe you can say that's going to save us 20 grand in developer hours. Um, but it's might even be more compelling if I say that's going to free up three extra days of development time per whatever cycle, what can you do in three extra days? Does that mean we get three extra days to improve quality? Or does that mean you get your, your stuff three days faster, but that's every month then now from this point forward, three days faster. And then it doesn't take long until now we're a week or a month or months ahead of schedule. And we've gotten efficiency gains. Um, I find that argument to be much more compelling when we're looking at opportunity costs, because really it's the call of doing it now versus when it's an emergency. Um, and trying to convince someone to do it now is always better. I, I like that a lot. I think, I think that probably is a good idea to start talking about friction or like if you use the metaphor of pipelines, the pipelines clogged, right? It's just like, you got to go in there, whatever, whatever it may be. But, you know, with so many of these terms, like, like the, the, the biggest term of all like agile, it's almost like, you should probably not use it. You should like, you should use a different word because it's got so much, like so much lore. And like, I guess the word would be baggage. The metaphor you would do. Baggage, scar tissue. I think just define it with whatever audience. Um, and you know, that is a, a crucial step that I think we often forget to do or just don't do because it's not a habit is like when you come into the, this conversation, not everyone
24:32is operating with the same dictionary. And when I say something is agile, that might be wildly, I might have this like, you know, idea from all of my previous experiences of what agile is. And you have a very different experience of that. And we're just going to end up talking past each other, or maybe we agree. And then it looks like we disagree because we're just not using the same terms, um, productivity, efficiency, effectiveness. These are all things that quite honestly, I think very widely depending on the organization and their goals, um, because organizations value different things based on how they make money and based on their engineering culture and just getting on the same page with people for these kinds of conversations, for example, what is tech that when does maintenance become technical debt? This is a question that I ask when I, uh, in, in some of my coaching programs. And honestly, I don't have a great, great answer. I can't tell you, Oh, it's after this amount of time that maintenance tasks become tech debt. Um, but it's interesting to see how different companies that I've worked with have categorized make regular routine maintenance tasks, updating dependencies as tech debt. Other companies, as you said, legacy code is tech debt. And that requires a lot more effort to, to course correct on. Um, yeah. So usually a bigger chunk, usually a bigger chunk. Um, but there's just wildly different definitions here. So, so there, you know, you, you brought up a few more things, some, some areas that I think, uh, uh, it'd be, it'd be great to, to, to, to talk with you about, but first, why don't you introduce yourself? You've mentioned a few things that you do here and there, but, but, uh, what's, what's your deal? Who are you? Hi, I'm Laura taco. Uh, I'm CTO at DX. We're a developer insights platform. Um, we help improve developer experience by figuring out what to change, um, from the source, which is your development team. So, um, aside from that, I'm also an, uh, an executive leadership coach for engineering
26:34leaders. I've been coaching for about two and a half years now, formally as kind of like, you know, a big part of my job. And I've worked with, um, you know, 300, I think now plus companies, um, either through coaching or through a course that I do on measuring development team performance to help them increase effectiveness, increase, increase efficiency, be, become better leaders. Um, and yeah, we know each other because of our good friend, Betty, who I know from way back in the day. Um, cause I was involved heavily in Docker and the Docker ecosystem when it was just a tiny little baby, a container was just a, a thing like that no one knew about. And then, um, now they're everywhere. They're everywhere to the point where we don't even think about them anymore. I, I, I hear, uh, there's, there's, uh, I hear someone's writing a book about all sorts of startups they worked at and including Docker and, and you, which, which should be interesting. We'll see if it ever comes out, but it is like there, there's certain companies that like many people have passed through and had experiences with. And, uh, I think, I think that's, that's one of them. Like, I remember at the time I was working, uh, in, in MNA at Dell back when I was in Austin. And, uh, I remember someone like kind of went over, man, I'm drawing a blank blank now. It used to be called something else, but they, they went over what it was and they were like, you should check out these container things. They're wild. And, and like, like at the time I was just kind of like, eh, I don't know, whatever. And I just kind of moved on from it. Then years later it was like containers, they're wild. Right. Containers. They do everything. Yeah. Yeah. But it's, it's a good, uh, it's a good little nexus point in the, uh, the, the history of, of time going through things. And, you know, I was, as you were describing the, uh, uh, the, uh, the DX work, I was, it was, it was making me chuckle a little bit because like you, you kind of, I think you, you, you put in a, you made a good litmus test for doing any sort of consulting or introducing some new thing is like, unless it's telling you something to change, why are you doing this?
28:38I had this deep thought this morning actually. Um, cause I'm, I'm working on a long blog post, which maybe by the time this episode is out, the blog post is out and we'll link it in the show notes or whatever. I'll send it to you. Um, but it's about just the, the fallacy of unobtrusive measurement. And I get questioned a lot, this question a lot, how can I measure, can I collect Dora metrics? Can I collect all these measurements about my team unobtrusively? Cause you know, I don't want to bother them. But then I thought in any other, any other avenue of life, if someone was collecting data about you unobtrusively, we would like press charges against them, you know, it wouldn't be categorized as like a good thing. I'm like, thank you for doing that for me. Um, it would be like, what are you doing? Yeah. You would call it spying. We would call it spying. And I think that is for me, that is such a deep rooted belief in a conviction that I hold that you should measure for change. And if you're not measuring for change and you're measuring for surveillance, for spying, uh, that's not healthy in general. I think there are times that you measure things that you don't take immediate action on and that's fine. Like health metrics, for example, we want to just keep, um, keep tabs on our cycle time or keep tabs on how many times we're deploying whatever, but it should be transparent, uh, and publicly available. And it should be known who's collect, who's collecting the data, why it's being collected, what they're doing with the data, who's seeing the data, all of those things. And, you know, maybe in some people's definition of unobtrusive, that is still true. And I think that's, you know, that's fine. We have a little wiggle room there, but, um, you know, this idea of like, well, I just don't want to bother the development team. So I would just like to collect this data, like kind of without them knowing. So that I could just see the state of things, um, to me as a smell. Yeah. What, what, what do you think? You know, I, I, uh, this is several months ago now, but you know, I love it when there's
30:40a big nerd fight, uh, about, about when there, when there's like a big and a specific type of nerd fight, when there's a, basically some large organization that mostly does consultative stuff that isn't kind of a big part of the, uh, the Gabby tech community. I know exactly where you're going when, when, when they come out with a PDF and, and people get very upset. And the first time this happened that I really paid attention to it was years ago when Gartner came out with this idea of bimodal it. And what they were saying there was basically like, you know, with the it estates you have, and we, we even talked about this at some point, uh, in our conversation here, like you have stuff that's running in a quote unquote old way and it's fine. And then you have stuff where you want to run in a DevOps way. And then of course the DevOps people are all like, you know, just burn it to the ground. Like if, if there's a, if there's, if there's an optimal way of working, you should apply it universally and not relegate these, uh, these, these other people to the terrible way of doing things or whatever. And like, it was, it was a, it was wonderful. Like from a, you know, it wasn't wonderful from, uh, uh, advancing the state of knowledge, but it was, it was entertaining, I guess, you know, uh, in that way. And then, and then of course, like, yes, as, as you well know, right. Like the most recent nerd fight was all about like McKinsey comes out with like, how, how, and it's, it's, it's kind of interesting. It has, to me, it has, it has a similar structure of the Gartner thing where it's like, maybe we should give them the benefit of the doubt and see where they're coming with this, um, and help them modify it along the way. Because I think they were, they were trying to do something exactly like we were talking about is like, how do we quantify this? Right. Like if I'm not a technical person, but yeah, I, I feel like the error and, and you were kind of going over this. I think maybe the lesson we learned from that is once you measure an individual in some way,
32:42that's dangerous for, for advancing your cause. Like it becomes political. It becomes lawful evil at that point. Yeah. I think, uh, first and foremost, software development is a team sport. And I think taking measurements on a team level is appropriate at times trying to quantify someone's country contributions, looking at things like workflow data alone is incredibly misguided. And I think if you asked any staff engineer out there and there've actually been quite some studies, and I think I saw a couple on at least one on LinkedIn that was looking at, you know, the, the 10 X engineer on this team, the staff engineer was spending, you know, all of their time coding and doing all of this stuff. But the only way they were able to do that was because the senior engineers on their team were doing all the planning and all the coordination and all the other stuff. And so it's so unfair to try to compare them because one enables another, and you can't just take them in isolation and apply the same. Rubric to whatever they're doing and get a fair outcome. So I will say this about McKinsey and I think this has been right. Nerd, nerd fought in, in public for long enough, but I think that McKin, the McKinsey came because we don't up until now have great benchmarks for things like developer productivity. We have Dora, which is, I call it the tomato of productivity because, you know, tomatoes are not a vegetable, but we treat them like a vegetable. Dora metrics are not productivity metrics. They measure capability, but at this point, everyone treats them as productivity metrics. So it's like, is ketchup a vegetable? I don't know. I don't know about that. But I think for a lot of intents and purposes, although the intention of Dora is to be capability metrics, everyone uses them as productivity metrics and it would, I can sit here and be
34:46like, well, that's not what they were intended for, but it's the reality of how they're being talked about and used. And so I have to, you know, meet people where they're at. But we don't have the equivalent of that sort of that industry-wide benchmarking on the developer productivity side. And that is what McKinsey offered with their DBI, their velocity index. So, I mean, I get the economic pressure and sort of like the draw. There's so many C-level executives that just want whatever it is McKinsey selling. And oddly enough, there was a great Last Week Tonight episode about McKinsey. I think it aired like in late November. Not at all about developer productivity metrics, just an interesting consequence. But check that out, brief aside. I will say this, my summed up position on McKinsey is like, I think there are actually a lot of good things in that article. It's calling for executives to better understand software development. It's saying, hey, we have to measure this like multi-dimensionally. I think those things are great, but the parts of it that are bad are really bad. Like, you know, equating developer productivity to just writing code and not understanding the subtleties and the nuances of a team sport. I think that it's sort of, you know, I was like, oh, this is not so, this is maybe okay. And then it was just like, oh, I really don't agree with this to the point where it sort of overshadows all the morsels of goodness that were in the article. Yeah. Yeah. Yeah. No, I, and I think I, I, I like, I like the idea of, of Dora match measuring, not measuring is even the wrong word, being an indicator of the capabilities that you have. Right. Like, yeah. And essentially, and it kind of, it touches on a lot of what we talked about here, where I don't even, I'm, I'm, I don't even really know how to articulate it despite knowing software,
36:50but like, it's almost like doing software development isn't really about productivity. It's about having capabilities available. And I'm purposely avoiding using the word flow because that's another like crazy blown up word at this point. But like, it's knowing that you can do something and you probably are going to want to do something, but like having the option, having the option to actually execute it and do it in a reliable way is like what ultimately is valuable. Like, like I was, I was doing something, I was talking about something, you know, to the camera yesterday. And I was thinking like, you know, I mean, if you're like a pharmacy or a chemist or whatever you want to call it, like, you probably don't really need to change your software every week. I mean, you only need to change it when you really need to change it. And then you got to change it, right? Like, and, and, and so like, if you, even if you were to look at the Dora metrics, like, again, if you were to look at the Dora metrics as, do you have the potential and the ability, the capability to release every week? That's great. But if you're measuring, are you releasing every week for like a pharmacy? It's kind of like, uh, who cares? Do you need to? Yeah. Yeah. Like, like, is that, is that capability giving you a competitive edge in your business? And like, you know, we can, for that particular one, we can talk about decoupling deployments and releases and like the subtleties between them and feature flagging and all this stuff. But you're absolutely right. It's like, um, you know, the difference between did we build the thing right versus did we build the right thing? There's going to come a time when you have the right thing to build and you want to make sure that you build that thing, right. Right. And that's where the capabilities come in. And that's where Dora and the benchmarks can be very helpful because if you have the right thing to build, but you can't build the thing, right, you're not going to get anywhere.
38:50And so there needs to be both. I think where a lot of the, the discussions about developer productivity and efficiency and effectiveness start to sort of get into dicey territory or sort of just lack clarity is when we talk about to what ends, like, you know, the name of the book is called accelerate. But the question I ask is like accelerating where, because I, I've worked with a lot of companies and I've worked at companies before that were elite right out of the gate, according to Dora. And I think honestly, if you're a new company or even in like the last, I don't know, post container post post DevOps world that your, your team was grounded or your, your founded grounded. I don't know. That's the German word. What did we say in English? I don't remember. Or the, you know, your team or your company. And I think it's hard to not be elite right away. If you're just using. Yeah. Yeah. You don't, you don't have all the baggage. You don't have any baggage, you know, it's like, oh, I'll just click, you know, circle CI check deploying to AWS, whatever, and just set up your, your workflow that way. And it's very easy to be elite continuously shipping stuff. If you have good engineering culture, of course, there's the people component to it. But what are you building? Because if you're building something very quickly that no one wants, it doesn't matter how fast, how many times you're deploying, because no one's going to buy it and your business is still going to fail. And I think there's a conflation of like, if we are elite in Dora, that means our business is good and successful and really building the thing right. And building the right thing are very different things. And often engineering is not even responsible for building the right thing. They don't get to make that call. Yeah. Yeah, that's, that's, that's, I mean, you're touching on it. I haven't gone and looked at the last, I don't know, three, four years in detail of those reports. But I, I was always curious to see, like, I want to see the spreadsheet where, where they relate
40:52higher performing to making money or, or whatever it may be, right? Like, I mean, I'm even forcing what I want to see in the spreadsheet, but it is, there is some relationship there, as you were just pointing out that, like, I never find in the, you know, the last four pages of in the methodology part, that would be, be fun to see just if only because it would be instructive to help answer what you're talking about, right? Like the, the, the, the car that efficiently drives, but ends up going nowhere is car commercial. Yeah. Yeah. Yeah. Well, it's fun, fun to drive. I'm sure. Yeah, exactly. You know, but before we wrap up, so like, uh, yeah, there's, you have, you have a lot of, uh, uh, a great articles on, on, on your blog to, to read through. And one of them, one of the themes that came up a lot that, that I, I was trying to boil down as much as possible is I don't know if I have the number right, but I feel like a lot, one of the common things that you're saying is like, probably 80 to 90% of meetings shouldn't exist. Right. Like, like, and, and, you know, you've got to, you've got a good position of like, when people do say this meeting could, could have been an email, they're probably right. Like there's a lot of things we do that we don't really need to do anymore. Uh, yeah, it's like the information is available somewhere else. And then you have a meeting just to check that the information is still available somewhere else. Um, right, right. Any meeting that doesn't have anything at stake where there's nothing of substance being decided or of substance being discussed that hasn't already been discussed asynchronously. And you've decided that you need to have an asynchronous conversation because it's so complex or nuanced that you just need the people talking to each other. Um, most of those meetings don't need to happen. Um, I think the, the little caveat I would put there is, you know, I've worked remotely since 2012, um, primarily remotely, and it is nice to have face time with a team to build rapport.
42:56And so that is a consideration if like, if it is an important team ceremony to have everyone together once a week during a planning, just to like get the energy up and get feel united on a common goal. That's a very, that is a very fine reason to have a meeting. Um, but just make sure that that's clear. It's not like, I don't trust that whatever you put in JIRA is accurate. Um, it's like, no, we're going to just like come together and see each other's faces so that we can work together effectively as a team. Um, that's part of the deal. And so no, that meeting can't be an email because we miss out on that human time. Yeah, a lot of meetings can be emails. I like that categorization. Like one, if, if you're not, if, if there's not a decision that is going to be made, then you probably don't need to have the meeting, right? Like the point, like that's definitely one type of meeting and probably a lot of them. And then, and then exactly your point. There's the, the, this is another phrase that would be good to have a better one for, but there's the team building get together, right? And, and, and like just talking with someone, especially if you're remote, like, you know, you kind of get that if you just go out to with, to lunch with people all the time, or like, you know, you, you have those meetings in the hallway. There's no hallways anymore. I think the last time I really worked in an office, we actually had offices in the hallways. It was a glorious time, but like, uh, so there's that. And there's almost like, like, I, I guess there's a third type there's, and they become not meetings. There's like, you know, a workshop where you're actually a decision isn't made, but you're like working on something collaboratively. But again, I mean, I really like your, it's like those other two things like are almost not meetings. And, and really a meeting, a capital M meeting is like, we're here to make something happen. Yeah. Yeah. We're not here just to fill space. And this full circle back to your point of like developers saying, oh, this meeting was really unimportant. I didn't need to attend versus
45:00the person who called the meeting being like, that was the best meeting ever. It was so important. You know, knowing what you want to get out of that time together is really crucial. Here's a quick tip for anyone who finds themselves in the position of needing to organize meetings or facilitate them for any reason. There's a difference between a decision meeting and a discussion meeting. Decision meetings should be made clear. We're deciding this thing. And as soon as the decision is made and the meeting, you don't need to go the whole half hour or the whole hour. If you come to your conclusion in the first 10 minutes, it's fine. Just say, bye, everybody. Maybe get better at estimating how much time you need in the future, but that's fine. Discussion meetings should only happen if you've already done an async discussion and you figured like this just isn't enough. We need to address this point, this point, and this point. And have it clear that it's a discussion meeting and that no decisions will be made because then people are just going to leave unsatisfied if they're expecting a decision from a discussion meeting. Yeah, that's really good. I like that. Super easy. Super easy. And you're also building in motivation for people to come to a decision. Totally. I was thinking a jokey way in my mind. Someone made a decision here because they wanted to get to lunch. They just had a reason to finally get a decision, but that's great. Well, I mean, speaking of, if people want to check out your blog and stuff like that and other things you're up to, your coaching and courses, where would you send them to? Just go to laurataco.com. T-A-C-H-O is how you spell my version of taco. Head there. I have courses blog. I'm working on some new self-paced courses for anyone who's finding themselves in an engineering leadership position and thinking, oh, well, I never learned how to do any of this stuff. I know you're all very busy, so I'm making kind of an express self-paced leadership course that should be coming out in the next couple of months. So check that out.
47:04Yeah. Well, great. Well, it was really fun talking with you. I appreciate you being on. Yeah. It was a great conversation. Yeah. And I'll put links to that stuff if you want to find them. If you're watching a video, they'll just be below somewhere. That'd be odd in the future if they move links to somewhere else. And there's like, you know, 20 years of people saying you should click below. Yeah. But maybe by that time, they'll just be AI that can go fix everything. Yeah. It'll just be deep fakes. Someone can like deep fake this conversation and update it. It'd be great. Exactly. And if you're listening to it or otherwise, you can always go to tanzutalk.com and search around and find the episode. And with that, We'll see everyone next time. Bye-bye. Bye.