TL016: When It Comes To Product Design, Don’t Trust Your Gut

Speaker A: Foreign

Speaker B: this episode of technically leadership, Dan McKinley joins me to talk about how people are consistently overconfident in their ability to predict outcomes in product engineering and general organizational experience. Dan was one of the early engineers at Etsy and has been at a number of companies, large and small in all sorts of engineering roles from principal engineer to vp. We get to discuss productivity in engineering teams and how early startup perks were more about helping people innovate with less capital and focusing on building a healthy organizational structure. We also sneak in a little bit about DevOps at the end. I love Dan's perspective, and I really hope you enjoy this episode. Let's get to it. All right, and here we are. You will have heard the introduction by now, but I'm really delighted to have you here, Dan. I'm, um, very excited.

Speaker A: It's great to be here. Thank you. Thank you for having me.

Speaker B: Yeah, we got a chance to meet just very briefly at DevOps days Austin while I was running around, but I got to hear your keynote about egoless engineering there, and I really wanted to talk with you about that topic as well as the topic from a lot of your other talks that you do and that you have. Um, and just so that folks know, if the show notes, you will find links to all of this. So I highly recommend you go check that out because I think part of the fun is actually looking at your slides and seeing the jokes that you're sneaking in there.

Speaker A: So, uh, yeah, I try to do two track talks, like jokes, uh, on the slides and um, narrative alongside it.

Speaker B: I just thought it was great. I want to dig in on, I think, like, a common theme on your talk, which is that people are consistently overconfident in their ability to predict outcomes. Now you've said that a few times. Can you explain that to people, like, just in a nutshell, what you mean by that?

Speaker A: Yeah. Uh, so I, like, I had this realization, uh, like I. Early in the Ego Less engineering talk. I like, frame it as like the latest in a, um, in a very slowly moving series of talks that I've been doing. Um, and then I kind of. I had the realization that the. The, um, the frame that they all fit in. Like, there's one about doing data driven product. There's one about. There's one called Choose Boring Technology which is going to be etched on my tombstone. And then egoless engineering. Like in my mind, these kind of like, fit into an arc, um, or like they are all chipping away at the same kind of thing. And I think that that's just people tend to think that they're better at predicting what's going to happen than they are.

Speaker B: Right, right.

Speaker A: Just in life. And so like, I think that's true with like, um, trying to predict what product idea is going to work out in reality. And that's true with. And that's kind of the first talk. And it's true with, um, trying to predict how an engineering project is going to go. Um, and that's like the choose boring technology talk. Um, and I think it's true with trying to design organizations to like create, uh, product or engineering outcomes. Like, I think people are also like, they're just, just like a, you know, a notch or two too prescriptive because I think they, they tend to overrate their own capacity. Like, we all do it. Right. I think we're all. Or many, many people are afflicted with that.

Speaker B: Oh, I think we all are.

Speaker A: I find it fascinating. Right?

Speaker B: Yeah, it is kind of fascinating to look at for sure. It's the, um, it's the fact that I think we as human beings all always think that we're better at something than we actually are. We. We're better at estimating time. That's probably one of the most common ones I used to hear in physics is that, you know, can you estimate how long a minute is? And some people are better at it than others. Right. But. Right. It's the same kind of idea when you start to think about it is that time is just as malleable to humans as our ability to understand it. So.

Speaker A: Yeah. And I mean, we can conquer that with the invention of clocks.

Speaker B: Right.

Speaker A: Uh, and I think like in, you know, technology industry walks of life, I think there are, um, you know, there are things you might do differently if you internalize that fact about yourself. It's like you're prone to overconfidence. I think is like something that. Something m. That you can bake into your thinking and adapt to.

Speaker B: Yeah, yeah, you had said that the first one that had kind of come to you when we first were talking about this podcast episode. You first had said that the product one, that, that data driven talk was the first one where you started thinking about this idea. And you had mentioned that there were ways that you can get around the overconfidence. Do you want to talk about that a little bit? You know how.

Speaker A: Yeah.

Speaker B: How do you bring product to.

Speaker A: I mean, so that, that talk was kind of like my, my summary of my, my tenure at Etsy. Like I worked at Etsy from 2007 to 2014. And uh, at least in that period, like beyond the core value proposition of the company, which was like, you can come here and uh, search for handmade stuff and buy it, um, there were just a lot of product initiatives that attempted to expand on that. Um, and some of them were successful in some ways, but none of them were successful in like, uh, you know, at the end of the day, okay, this, this makes way more money.

Speaker B: Yeah.

Speaker A: And like I, and I just like watch it, watch the movie happen like six or seven times at least with like different, different principal actors or sometimes the same principal actors. And like, you know, I was always involved in some way where we just like, this is it, this is what we're going to do this year is we're gonna um, we're gonna do this, this particular product idea. Like, huge percentage of the company is going to put all their effort into it and everything's going to be up and to the right when we're done. And like at the end of the year we would just like, we'd ship the thing and then like maybe six months would go by and we um, shut it down because nobody ever used it. And then never speak, never speak of it again. And I just like, I, I just like saw that happen enough times that I just like, I started to think like, it just can't, it can't be like this forever. I don't know that I've got perfect answers to this. I don't know that anybody does. If I had perfect answers to this and you know, have built a product company and be a billionaire, but I'm not. Um, but I think like, what I wanted to say with that talk was we should approach these things with more humility and do our, do our damnedest to get ideas, contact with external reality as soon as we possibly can. Because we're just like, we are clearly not very good at predicting, um, what product idea is going to be a winner. And the things that are winners are things that we didn't predict were going to be winners. And that talk, somebody called it opportunity sizing for engineers or something like that, part of that talk is my realization that you can do math about product ideas and like you probably should because some of those year long projects that we worked on were things where like, well, if you went to the whiteboard and multiplied a couple of numbers together, you'd pretty quickly realize that this was a crazy idea that was never going to work because it was like at the end of the some, not all of them, but some of them were of the form like well 700 people like get to this place on the site a day which is, you know, nothing because millions and millions of people come to the site every day. Um, and like what if they all, what if they all did something amazing? Well then we'd have 700amazing events resulting in $30. I don't know, just like you know, it's, you can, you can multiply you numbers together and pretty quickly make amazing ideas look bad or make ideas that don't sound amazing to you, um, look really like surprisingly great. And I think like that's, that's um. Have we considered doing math about this is like my main takeaway from, from that era.

Speaker B: Well, I mean I have to say one of the funny things about it is if you think about it, computer science is all math, right? And yet everyone is not interested in doing the math about. Does this idea.

Speaker A: Yes, this is another common thread between those talks I guess is like yeah, computer scientists, we study all this stuff in the domain of computers, complexity theory or queuing theory or um, basic arithmetic and things like that. And we just kind of, we have a tendency to turn that part of our brains off when we're, we're stepping outside of the computers and thinking about teams of people or we're thinking about um, you know, a product idea or you know the, the socio technical uh, engineering platform we're trying to build uh, for engineers to be productive and things like that. It's right, like we kind of systematically refuse to do math a lot of the time and I think maybe, maybe we should reconsider that because math is um, unreasonably effective. There's no reason, there's no, there's no known reason why math should be this effective. But it is and we should, we should take advantage of that.

Speaker B: Right? So I mean you had talked about like getting in contact with users earlier when it came to product for, for the data driven one. Like we're still data driven talk. But um, would you say that doing the math encourages you to actually talk to the user as a leader? You think it kind of helps you understand what users to even think about or is that like separate.

Speaker A: It definitely can like I think it's. Well I, I think it can relate. Right. Um, like in the, in the context of Etsy it was pretty difficult to talk to like the median user. You could certainly talk to users but definitionally like they like for a big consumer Internet website, like they definitionally are like kind of weird because you're able to find them and talk to them. Like, that means they're not the typical person. Um, and there can certainly be a lot of value in that. And like, you know, there can certainly be a lot of leverage in your most engaged users. Um, so, you know, your most engaged users are more likely to buy stuff. And when you write out the math for, you know, what doing, having a small effect on your most engaged users might do, it's like those effects at the end of the day can be very large. So it's certainly worth doing that. It's worth thinking about, um, which users you're addressing with a certain, with a given, given thing that you might do and then doing the math with their particulars. Um, is certainly like a, um, important thing. And like, you know, talking to people can certainly get you thinking thoughts that you weren't going to have otherwise. Uh.

Speaker B: Right.

Speaker A: And, you know, I also like something I have aside from outcomes. It's like something I have noticed about my career is that, like, I personally just am much happier and more effective at work when I, like, care about.

Speaker B: Yeah.

Speaker A: Care, um, about, like, who I'm making the software for. Um, and uh, you know, in areas of my career where I was working in finance or whatever, like, I just had like, a lot less of that, um, I had a lot less of that dopamine than I did working at Etsy, where you'd go to, uh, go to work at the renegade, uh, craft fair booth in Williamsburg or whatever in 2000 and everybody would just be overjoyed to see you. That really motivated you to work hard.

Speaker B: Uh, it is very different. Very different. Going to like, an enthusiast conference or an enthusiast, like, hobby fair or something like that versus going and talking to the suits in a, uh, in a finance world. Right. Like, the excitement level's a little different. Just a little bit.

Speaker A: Yeah. I mean, certainly, like people, people get excited about finance and like, I maybe via, uh, the Matt Levine newsletter, have rediscovered like, a little bit of that.

Speaker B: Okay.

Speaker A: My older age, but, you know, with my foray into finance, I was like making an Excel plugin, uh, or whatever. And if I was ever talking to a user, it was somebody who was working 110 hours a week, was really angry to be talking to me.

Speaker B: Yeah.

Speaker A: So I got bellowed at a lot over the phone. I didn't really build that kind of connection with the people who, um, were using the things I was making.

Speaker B: Yeah, yeah, I can understand that. That's definitely a difference.

Speaker A: That was why I freaked out and moved to Brooklyn in the first place.

Speaker B: That's fair. That's fair. Well, I want to, I'm going to awkwardly transition, um, because I wanted to get into the boring tech discussion that I think is very similar because you're coming at it from the angle of engineering at that point. Um, even though this was, this was really still about Etsy in some ways.

Speaker A: But yeah, it came out of like experiencing the world outside of Etsy. And I was like wait, yeah, like there's something that we were doing there that was special and companies outside of this need to hear about it.

Speaker B: Right.

Speaker A: And so I think it's like um, it was definitely like about like what Etsy engineering culture, like how it. Etsy like at that period, I, I thought was like a really, really effective engineering organization. Um, the company as a whole like had a lot, a lot of growing to do I think. But like something, something really amazing had happened engineering wise where like we um, you know, after five or so attempts by people to just rewrite the whole thing, like we, we ultimately like battled our way to having a plat, an engineering platform that like, if you accepted the constraints, the artistic constraints that the platform gave you.

Speaker B: Mhm.

Speaker A: Um, it was, it really made people productive and effective. Um, and it was built on stuff that nobody would consider um, exciting at the time. It was like MySQL memcache, php, um, which is you know, like extremely. Nobody gets excited about that. Like even um, even the people who created those things don't get excited about it. I don't know. But like what we, what we. By getting all of that out of the way, um, I think we um, uh, we were able to achieve some pretty impressive things just by you know, taking. I don't know, I, I have like Brian Eno in my head every time this comes up. But it's like I don't just accept the, except the artistic constraint, except the thing that you're going to have as a fixed point which is like we're going to do this on MySQL even if we don't like it. Yeah. I mean, and then apply your creativity elsewhere. Like I think that that's.

Speaker B: Yeah, Yeah. I guess people who know me, people who have heard me before, often hear me talk about shiny tool syndrome or shiny object syndrome that like every developer has that oh, hey, I'm starting a new project or I'm going to refactor this project, I'm gonna go try it with this new thing or that new thing. So like basically kind of what I got out of that talk. Now mind you, I didn't get a chance to see that talk I have read it. Is that shiny object syndrome, the anti Shiny object syndrome idea of save your mind space for other things that are

Speaker A: more important than m. Well, I think where like the overconfidence thread, like connects with that is like you, you just like have unrealistic expectations about how awesome it's going to be to rewrite your website in Haskell or whatever it is that you want to do. Right? It's like, um, you've picked up the Haskell book, you've read about the standard prelude, you've read about the no side effects thing. Like, you've wrapped your head around monads, but you haven't learned all of the things you hate about it yet. Um, those will exist.

Speaker B: Yeah.

Speaker A: There will be a lot of them. You need to try and like, you need to try and do a real thing with it to find all of those. Um, and there are certainly people who go through careers just going from one version of that to the next. Um, because at least for a while there, like you could, you could migrate from job to job and just be like, well, let's try this thing. This thing will be perfect this time. But like in a longer tenure, ah, at Etsy especially, like, I, like, I lived with something that sucked long enough to just be like, all right, yes, this sucks. Um, but everything else sucks. And like I gone through that mistake myself enough times at Etsy where like I tried to rewrite a Scholar service or something and like went through that arc of this is going to be great. There'll be no problems. You know, all of, unlike php, like all of the functions that manipulate strings have consistent argument order. So this will be great. Um, and then, you know, six months later, uh, I hate it more than anything in the world. Um, and like that. Yeah, yeah. So that after many, many times touching the stove and burning myself, I was enlightened.

Speaker B: So how do you. Is it just that, um, that you're giving these talks and I do want to get to eco less engineering. Don't worry, we will get there, folks. Um, but when you're giving these talks, is this like your attempt to prevent the younger generation from burning their hands on the stove? Is this like. Or like, how did you do that in the job? Like in process, how do you prevent somebody from thinking the grass is greener and diving after it?

Speaker A: Yeah, um, in some sense, like a lot of this is non transferable knowledge. I think it's m. Like in the domain of like mistakes you just have to make yourself if you're ever going to believe that. And so. And like, I don't. Like, I. I don't know. I. Imperfectly, I guess, would be the answer. Like, I. You know, many has been the time where somebody's like, we're going to rewrite all this into TypeScript and GraphQL microservices, and we're going to take two years to do it. I'll, uh, just like, look them in the eyes and be like, you're gonna get fired, man. Like, it's. You're gonna do this for a year. You're gonna be nowhere near the end of it. You're gonna get fired, and then a year later they get fired and they come talking afterward. No, no amount. Like. Like, to some extent, it's like you just. It's very difficult to get people to believe that the stove is hot. Yeah. Uh, but, you know, I do have. I have attempted to, um. I have attempted to, um, actualize, uh, choose boring technology in companies. And like, I think, like, the missing parts of that talk are about that. Right? It's like, how do you, um. How do you build a system that gets you to a platform that is. Is, um, you know, crappy in ways that are understood and, uh, productive for people and something that maximizes the group velocity of the team, which is what you're trying to do. You're not trying to, like, make it so that one person can, you know, type a feature from start to finish as quickly as possible. You're trying to make it so that the team as a whole, um, it moves quickly together because, like, that's. That's how you scale up. Um, and I think like, the missing pieces of that are, you know, having some kind of, like. So you. Something that is frequently misunderstood about the talk is. Or, you know, is. Is that it's, um, a Luddite talk. And it's super not. Um. Like, I think it's. It's, um. Or that's like. People conceive of me as I actually received a book. Like a. A book agent got in touch with me and it's like, you know, we need to. We need to turn this into a business book where it's like the. The magic. Like, choose boring technology. Subtitle the Magical Power of Being a Luddite. And I was like, oh, no, I never. Please do m. Not ever call me again. It's like, not. That's not what the talk is about. And it's not obviously, like, if you, uh, build your site on MySQL today and then don't touch it for 50 years, the world changes around us. We have to adapt the things we're doing. We need to start using new things. We need to upgrade what we're currently using, et cetera, et cetera. You need to build a system, um, uh, that maintains the set of stuff you're using in production. And what that system entails I think is you need people process um, to augment this and like that can take the form of uh, things I've attempted to use are um, just like a checklist where hey, if you want to use a new thing, um, here's like some questions to think about before you use a new thing. And so question number one is like what are we trying to do? Um, and sometimes the answer to that is I want to use this new thing. And then you conclude the discussion number one and that and then you know, but often, often people are smart enough to notice that is a bad answer and they're like well I'm m trying to make feature, uh, X. And then question number two is like how would we do that without using the new thing? Um, and generally if you've, if you picked um, a couple of pieces, you know, a programming language for the server and an approach to JavaScript and like a database and some, you know, a few other things, the answer is like only very rarely is it like we literally can't do it.

Speaker B: Right?

Speaker A: Um, and like question number two, like is this exercise in um, this exercise in like thinking through how you do it without adding a new thing. Right? And then like often that's enough to just like get people to snap out of it and be like, oh, you know, okay, maybe this is like, maybe this sucks maybe 20% worse than what I was imagining it would be if I added this new piece of, piece ah of gear to the stack. Um, but that's not you know, like if we add this new piece of gear to the stack, then we're going to be on the hook for alerts for it for the rest of our lives. So maybe I should just like eat the 20% schedule schedule hit and like doing PHP or whatever.

Speaker B: Right, right.

Speaker A: Um, and so you know, those, those two questions are magical. But uh, you know, it's, it is the case that sometimes you want to add things and like sometimes like um, the questions downstream of that are about like who do we know who's using this thing? Can we ask them questions about like what they like and don't like about it? And there's a way to like fast forward to you know, us in six months once we've Discovered all the things we're going to hate about it. Like maybe we, maybe we can find somebody who's already done that and they can tell us the things that we're going to hate about it. And like we can accept those as we can accept that stuff or we can um, we can accept that stuff as risks or we can be scared away by it. Um, that's, you know, that's open and then it's like ways to make people. Questions like farther down the checklist are intended to get people to think through. Like, okay, like what is the, what's an easy way to like low risk way to get started with this? Right. How can we check in on it over time to make sure we still want to do it? Um, if this is like um, something that's replacing a piece of our stack. So say we currently use MySQL and we want to add Postgres. Um, like are we, are we saying we're going to have MySQL and Postgres both together forever or are we actually saying we're going to cut over from one to the other? Um, that's an important thing to have a, ah, clear opinion on. Um, like early on and then as you go. Um, and so I think like that that kind of system, um, is what you need to evolve, um, input. Like manifesting that system in a free for all is a high wire act. Uh, I would say, yeah, high wire act of leadership. Because it's kind of like, okay, we're gonna, we're gonna arrest the, the uh, free for all now. And like it happens like in a meeting where like a person like has to have a realization that they are proposing to do something crazy and everyone sees them doing right. And so making that go well, um, is tricky.

Speaker B: Yeah.

Speaker A: I, um, think you want to, you want to introduce such a system with uh, you know, some senior people who are allies of yours.

Speaker B: Right.

Speaker A: Perhaps do some Potemkin meetings where like you have, you have someone show up and be like, we're going to rewrite everything in CoffeeScript. And you'd be like that doesn't uh, sound like a good idea. And they'll be like, oh yeah, you're right. And then you just show that it's fine. You keep doing it. You keep. To have that conversation. Yeah, um, but yes, it's very, very tricky to impose such a system.

Speaker B: Yeah, I mean, I guess I didn't get that out of the, out of the um, boring tech talk just because maybe I've dealt with that too much and I Understand that the grass isn't always greener. There is a lot more, uh, organizational chaos that's going to cause. And also you have to keep learning and you have to keep innovating. But um, this I think ties in very nicely to the last talk of egoless engineering. Because I had written down, uh, before this podcast episode, I had written down a few notes of what I had taken out of the talk. And one of them was as a leader, giving people permission to be curious is important. And so this, it's kind of like the other side of it saying you're allowed to be curious but do it smartly. Right?

Speaker A: Yeah, I think. And connecting back to like the overconfidence thing, I think it's just like it's real easy for, for leaders to think they know exactly what people should be doing right at all times. And I don't uh, I just like, I don't think that's right. I think, um, you want to, you want to bake slack into your system, um, when you're building an organization, right. And like this is again a high wire act if you're not the CEO of a company, because you probably have a CEO of your company who's um, yelling at you to get rid of all the slack time and make people type faster. And I think that that's uh, uh, you know, a pennywise pound foolish thing that, that a lot of people get up to. Yeah. Because people want to, uh, people just naturally want to build, build systems that like, make themselves more productive and make their teammates more productive and like they want to care about their co workers and like that these are all, like, these are all innate forces that you can, you can uh, harness and use to your advantage, um, if you're smart. And I think that, you know, building that kind of culture is smarter than building one in which everyone's miserable. So yeah, I think like, you know, the, the, it was a bit like, um, writing that talk kind of came out of just like watching the vibe shift in the tech labor market.

Speaker B: Right.

Speaker A: It went from a moment of, went from a moment of like a lot of labor power to basically none overnight. It felt like, like there was a summer where at the beginning of the summer I was being yelled at to hire faster and then at the end of the summer I was being yelled at to stop hiring immediately. It was like. And I think like that came with a lot of like, and now we don't need to let people have any spare time sorts of vibes. And I was like, that is definitely a mistake. Because that's how we get good outcomes. Um, and I think that um, you know, certainly like there's, certainly there's overreach in like, uh, tech jobs that have a lot of amenities and whatnot. But I think like what, what I was thinking about it at the time was like we were, we were doing hack weeks in 2007 when it was completely impossible to raise money like in New York. Um, and the reason we were doing them is because it made the, the engineering team better. Um, and it got us the outcome that we wanted. And like we were doing, um, uh, we were, do we. Like, we were giving people like large percentages of their time as, as free time. Because what came out of that was quite useful and made like, like a lot of these things that um, came to like, came to be viewed as like, you know, ostentatious, like tech industry amenities, like slack time, like new hire boot camps, like hack weeks. Yeah, stuff like that. Like, I think people misunderstand the history. Like those, at least in my part of the world, those were things that we invented in order to make the most out of the people that we had. Because we did not, we didn't have like infinite VC money when we started doing those things. That was what we needed to do to be efficient.

Speaker B: Yeah.

Speaker A: Um, and so like in, you know, in the uh, whenever, like 2024 or whenever that was, I was like watching people start to just turn the screws on tech employees again. And like, I was like, no wait, like this, this actually like these were things we were doing in order to be efficient. Like we were throwing the baby out with the bathwater here. So.

Speaker B: Yeah, that's, yeah, uh, it's kind of that meta thread that you also had talked about was just that it's not work people as hard as you can. Because when we first started talking about this, I was talking about um, the mythical man month and asking was this. Basically what you're talking about is the. You put more monkeys on the keyboard, you put more people on a project, you don't help them get started and suddenly magically you're going to get velocity. But you're saying that it's really about that just pushing people to work as hard as possible doesn't get you anywhere. It's better to provide that space. And uh, you mentioned being a force multiplier for other teams working towards cross pollination, driving that organizational change is really what this was all about.

Speaker A: Yeah, I mean, I think like uh, part of the, a big problem at work that people have a hard Time seeing. A lot of the time it's just like people. If you pick a random person at a reasonably sized company and ask them like, hey, what do you think we're trying to do here? Like, your. Their answer is going to be wrong in ways that will surprise you. Um, and I think like, just getting everybody on the same page about like, what our goals are, like as a team, as a company, like, what are we trying to do with our one precious life. Yeah, like that. That's underrated. Um, yeah, because like, once you get them on the same, Once you get people pointed in roughly the same direction, like they will come up with surprising solutions to getting to where you want to go that I think maybe like you wouldn't have predicted. And I think a lot of that at Etsy came out in, um, just, you know, people spending their spare time trying to make people in support have better lives or, um, you know, people in support, like learning enough programming to do some stuff to make their lives better themselves. You know, just like you. It's um, like that kind of side activity is easily underrated as like a way to get, get things going.

Speaker B: Yeah. When, when I was at Rackspace, one of the things we were trying to do, I was a developer underneath the technical writing team and one of the things we were doing was we were teaching support how to submit pull requests against our documentation because we were actually doing the docs as code mentality and support, uh, was excited they got to finally come in and fix documentation that they constantly got phone calls about or, or otherwise improve it. Find a way to answer this differently. Maybe they wanted to translate it just. But I don't think that if, if we hadn't done that, if, if that hadn't been an idea of, hey, we're going to do docsis code, we're going to go teach support how to do this. And yeah, sure, it's outside of their, their technical role and we're supposed to be doing it, but they're the people there, they're the people experiencing this and we wouldn't have gotten that experience otherwise. So I guess that's more of a, uh, a validation I guess, for me saying that, yes, I saw the same

Speaker A: thing,

Speaker B: but I mean it definitely does better. But I guess it is still something that people don't quite get.

Speaker A: Um, yeah, and I mean like a lot of I, stripe, uh, had a lot of that, um, that kind of ethos too. It manifested somewhat differently than Etsy, but it was um, like stripe when I was there, had a lot of that Kind of, you know, cooperative. Cooperative spirit.

Speaker B: Yeah. Yeah, I'd. I'd. I'd say, you know, hey, this is the spirit of DevOps, but, uh, I won't open that can of worms on both of us.

Speaker A: Right now I'm burdened with DevOps opinions. Yeah,

Speaker B: I mean, we both are.

Speaker A: It's fine. It's all good. Of course. Yeah.

Speaker B: I mean, it's the evergreen conversation. Right. What exactly is DevOps? Is it. Is it all kinds of things?

Speaker A: Yeah. Well, it is a portmanteau suggesting that you should break down the barrier between Devon Ops.

Speaker B: Yes. And other groups too, though. So that's a little newer than what it used to be, of course.

Speaker A: But, um, we should invent words for those things because. Well, maybe we shouldn't because, um, they'd instantly become job titles.

Speaker B: Yeah. What is that?

Speaker A: Yeah.

Speaker B: So how long do you think it's going to be before you have, ah, a job title of Eagle? As engineer.

Speaker A: Um, Perhaps I should.

Speaker B: You should be the first one. There we go.

Speaker A: Maybe I should.

Speaker B: Maybe Senior Fellow egoless, uh, engineer. That'd be highly entertaining to me. But it'd be good because I think this is a really important topic. I think it's a really.

Speaker A: I always wanted to be a fellow. I'm not entirely sure what is, uh, what that entails. I'd like to just have a business card that says Fellow on it.

Speaker B: I mean, you can.

Speaker A: Why not? Yeah. I don't even need a reason. Just make it.

Speaker B: It'll be good. All right, well, as much as I want to keep continuing this conversation, I think there's so much we could talk about. We are getting close to time, and as always, I like giving everybody a chance to kind of talk about what they're working on as my. Thank you for coming on with me and, and putting up with my questions for 30 plus minutes. So. This is your chance, Dan. Anything you want to share with everybody?

Speaker A: Uh, just, um. Mcfunley.com is my website. It's, uh, very, very slowly moving, um, uh, project. Uh, that'll. That'll link to everything else. Like I've got a domain collection that's a little out of hand, but, like, you can get.

Speaker B: I thought it was hilarious.

Speaker A: Yeah. Uh, and, um, yeah, it's. That's. That's where I. That's. That's. That's where I ponder. Ponder the overthinking instinct.

Speaker B: I think it's great. I think it's awesome. All right, well, you know what? Thank you so much for joining me. This was a great conversation. I'M so happy.

Speaker A: Yeah. Thank you for having me.

Speaker B: Yeah, absolutely. Absolutely. All right, folks, we're going to go record our hot ones or our hot takes. I, uh, did not say hot ones. Please, hot ones don't come after me for trademark infringement. We're going to go record our hot take and, uh, and do that. But for now we're going to say goodbye and I hope you enjoyed this episode. So bye for now. Thanks so much for listening to this episode of Technically Leadership. Feedback is a gift that I treasure, so please find me on LinkedIn, BlueSky, Mastodon, or the packet pusher Slack. Or you can send feedback through the form@packetpushers.net fu by the way, that stands for follow up. Links to all of those spots are in the description and show notes. Share this episode with your friends and colleagues and let me know if you have someone you think I should talk with about leadership. For now though, go lead.