In this episode, Dan discusses the importance of properly structured autonomous teams. He reflects on how leadership on these small teams can smoothly operate and their recommended size. Dan shares how these teams are the fundamental building blocks and that creating the right culture at the team level is essential. As a leader, Dan reveals that a continued focus on quality means that he is looped in when production issues are being discussed (Leaders, join the Slack channel!) and how strong leaders must be familiar with the severity and frequency of these issues.
Beyond focusing on quality, Dan dives into additional values he seeks to find in team members growing into leadership positions. He shares how pushing into an area of discomfort is key while sharing actionable mentorship strategies for providing those challenging and meaningful growth opportunities. Acknowledging how difficult tech leadership can be, Dan discusses the role of accountability and ownership, including how leaders must demonstrate the ability to receive feedback. Dan shares how opinionated, strategically disagreeable team members add value and, alongside other qualities that make them enjoyable to work with, are key members of teams that quickly find the right answers.
- (01:40) – Leading software engineering at Chamberlain Group
- (04:20) – Driving better practices
- (06:57) – Culture-creating behaviors
- (09:52) – A focus on quality
- (13:28) – Organization culture vs. team culture
- (16:05) – Accountability and ownership
- (19:47) – Embracing discomfort
- (23:42) – Building opinionated and innovative teams
- (29:14) – A willingness to disagree
- (30:57) – On leadership
About Our Guest
Dan Kirsche is an experienced technology executive and Senior Vice President of Software Engineering at Chamberlain Group. Previously, he was the Chief Technology Officer at CURO Financial Technologies Corp and lead software engineering at Enova International, project44, and Groupon. Dan earned his MBA from Northwestern University Kellogg School of Management and a bachelor’s degree in computer science from the University of Illinois Urbana-Champaign.
Subscribe to Your Favorite Podcast
If you'd like to receive new episodes as they're published, please subscribe to Innovation and the Digital Enterprise in Apple Podcasts, Google Podcasts, Spotify, or wherever you get your podcasts. If you enjoyed this episode, please consider leaving a review in Apple Podcasts. It really helps others find the show.
Podcast episode production by Dante32.
Full Show Transcript
Patrick: Hello, fellow innovators. This is Patrick Emmons.
Shelli: And this is Shelli Nelson.
Patrick: Welcome to the Innovation and the Digital Enterprise Podcast, where we interview successful visionaries and leaders and give you insight into how they drive and support innovation within their organizations.
Shelli: Today, we're delighted to introduce Dan Kirsche, Senior Vice President of Software Engineering at Chamberlain Group, a global leader in intelligent access solutions. Chamberlain Group, a Blackstone portfolio company, is known for its myQ ecosystem which delivers seamless and secure access to homes and businesses. They're well-known brands, including LiftMaster and Chamberlain, are found in over 50 million homes with more than 10 million users relying on the myQ app daily.
Dan graduated from Northwestern University's Kellogg School of Management with an MBA in entrepreneurship, business strategy, and decision science, and from the University of Illinois, Urbana-Champaign with a BS in Computer Science. Prior to his current role, he served as CTO at CURO. Under his leadership, Chamberlain Group has earned spots on three of Built In's 2024 Best Places to Work awards lists, including US best large places to work, Chicago best places to work, and Chicago best large places to work. We're excited to delve into Dan's insights on the future of intelligent access solutions and the innovations driving Chamberlain Group's success.
Welcome to the show, Dan.
Dan: Thank you. Great to be here.
Patrick: Dan, it's great to have you on here. If you don't mind, if you could share with our listeners a bit more about your role at Chamberlain.
Dan: Sure. So I'm still really new at Chamberlain, so like any new role, you're still kind of exploring what you need to do. But I was hired to, as SVP of software engineering, really lead our software engineering practices. We have millions of connected devices that connect back to our platform every second, and so we have to make sure that we're building a scalable infrastructure for future growth as well as build out new capabilities, new innovative capabilities. So my team is like any other full stack, front end, mobile, backend testing, and we're doing a little bit of gen AI as well, so leading that team forward.
Patrick: Awesome. For people who don't know, you probably have a Chamberlain product. If you live in a home with a garage, was it 80%, 90% likely if you have a garage opener, you have one of Chamberlain's garage openers? What is the market saturation for Chamberlain at this point? It's pretty high.
Dan: It's pretty high, yeah, I should probably look up the metric there. I don't have it offhand.
Patrick: More than likely, we'll leave it at that.
Dan: Exactly. More than likely. When you talk to folks, when I'm talking to friends and family and telling them what I'm doing, I start off by saying, "Do you have a garage door? Okay, if you have a garage door, your garage door opener is probably, what? LiftMaster?" Most people will think about it and then say, "Yeah, yeah, I think it is." And then I ask, "Do you have myQ app?" And then that's when they say, "Oh yeah, of course. I get notifications from my myQ all the time." "That's what I do." Everyone I speak to has it and knowing, man, this is something, this is an app that most people interact with many times a day, right? There's very few apps out there that have that sort of penetration, and it's really cool to be able to know that the application I'm working on and my team is working on is affecting millions of users on a daily basis.
Patrick: That is really cool. And I know you're relatively new at the organization. I can't remember when the integration with Amazon went through, but I remember seeing it on Amazon when Amazon let me know that they can deliver stuff to my garage now instead of dealing with the porch pirates.
Dan: Yeah, absolutely. That was about five or six years ago.
Patrick: Is it really that long ago? Wow, okay.
Dan: Yeah, Amazon Key. And we've since integrated with Walmart as well, as well as some car companies so that the cars can seamlessly provide access back into your home as you drive up.
Patrick: Wow, that is awesome. So you said that your mandate for coming in and your goals and your objectives with leading and advancing and expanding the software engineering practices. Conversations we've had previously, I know you've mentioned that you've had an illustrious career, you've been to a lot of very well-recognized organizations here in Chicago who are known for high-quality software engineering. You mentioned that there's a lot of things that when you engage in an environment like this that you consider repeatable or standardized or just kind of block and tackle, and I have to mention lacrosse at least 42 times in every single one of our episodes for some silly reason. And when you mentioned that, I did think about, there's just what I would consider fundamentals. When you're coaching a team, there's fundamentals that need to be executed on of like, "Hey, these are the simple things. This is what a high-performing team." Is that how you see it and what are some of those standardized processes that you're focused on that you think are really critical to reach a high level of capability?
Dan: Yeah, that's a good question. I'd say every team, every company that I've joined and looked at, how do we drive better practices, drive efficiencies, what are the challenges? I would say I always, always start with org structure. Always. And so you can start with architecture because there's always architecture improvements. That always ends up going to tech debts, we have a lot of tech debts and we don't have time to deal with tech debt. And then, "Oh, why don't you have time to deal with tech debt?" "Well, it's too many things to build. The product or business has just tons of stuff that we need to do and we just don't have time. And it kind of snowballs into many other things and it takes so long because we have so many dependencies and then we're in so many meetings," and on and on.
And it always for me, it always ties back to org structure, so I focus on that first. And I have, throughout my career, I've kind of fine-tuned it. It's not very different, I think, than most other companies, what they implement. Other tech companies kind of follow this practice as well. It's really standard agile. I think that there's some really key principles that are necessary, and the reason why I focus so much on this is the need to drive ownership. Ownership and accountability is like, first principle. You have to have that to do anything else and drive any other sort of change within the organization, whether it be architecture, like other sort of collaborative efforts, that sort of thing, you have to have accountability ownership, especially in super complex projects.
So I always go back to, there's a pretty popular book out there, Accelerate, they introduce the DORA metrics, and one of the things that they talk about is the need to have culture. You have to have the right, the generative culture. No blaming, that sort of stuff. Mistakes are acceptable and you just kind of have to drive towards solutioning. What was the problem? How do we solve it? How do we prevent it? And let's move forward with it, let's learn from it. I 100% agree with that. Now, what's so interesting, and what I fully buy into is you can't just change culture by describing culture. You could spend months talking about it and describing what this looks like, but really the way to do it is by changing behaviors. And so I think that's a critical point is to change culture, you have to change behaviors. It's a forcing function. Use changing behaviors to change culture, that's your forcing function.
And so the org structure to me is that forcing function. I actually just had conversations with my teams just recently about that, which is, you have to have a leader, you have to have an engineering manager, and you have to have the engineering manager is attached at the hip, a really strong partner with product, and you have a tech lead. The three, those are kind of your three-headed leadership of your autonomous group. And then below that, you have your cross-functional, front-end, back-end testing. So as long as you have that, that is like your fundamental piece. And you have the Jeff Bezos, the Amazon two pizza team I think is super important, too. You can't be too big.
That's your fundamental building block. Reinforce that this team is responsible for delivery, improving delivery, identifying opportunities to build technology, to drive efficiencies. They're an autonomous team and they're focused on delivering business value. And so what ends up happening is because you're enabling the engineering team to be autonomous and own, they will start driving just kind of as-needed technology improvements and so it becomes part of the standard conversation. "Oh, well if we do this, if we need to deliver this new feature, we should probably dry up our class or whatever it is to speed up software delivery, and it kind of starts getting built into what they are working on.
So to me, that is fundamental. You start there first and then you start moving towards architecture changes and I think once you have a good understanding of architecture, then you can become innovative. So those are really the three stages that I go through. I really want to point out, and I don't want to get too deep into it, but quality. This is another one to your point on what do you need to focus on? What are your first things that you need to implement? Another one is a focus on quality. That is so important. Engineering teams are super good at focusing on speed, like how do we get faster and deliver new features? Well, if your system is down or that feature is not working correctly, it doesn't matter how many features you have. It's not working.
Patrick: Hold on. That just almost makes sense. What is this crazy logic you're using of like, no, we should just be pushing out bad code, right? We checked the box. Sure, there's eight bugs on that one, don't worry about it. It's all good.
Dan: Yeah, you know, and it's so funny how both prompt and engineering gets wrapped up in delivering. And "Oh my gosh, we've got to rally around this new feature. Let's go deliver. Yay, we delivered the feature." Then it goes out and, "Oh, we've got some bugs coming in. All right, well let's put that on the backlog, right? We'll get to it later." And so that kind of becomes the default behavior for whatever reason, because we're so high in delivering new features. And so there's just the need to bring back quality, guys. Quality is the most important thing.
Patrick: I agree 100%, that's the foundation when we talk about the fundamentals. So there's certain things that I coach every year. So what is that thing where you're saying, "Hey, this is how we reinforce this focus on quality." Is there something that you do? Is there something you say? Is there OKRs? Is there KPIs? Is there some kind of metric?
Dan: Yeah, absolutely. I mean, I think there's a few things. Probably two primary things. One is, it's super important as a leader to get an understanding of often, how severe your production issues are. So one of the first things I do when I come to a company is I want to join whatever that Slack channel is or the team's channel is where all the production issues are being discussed. I really need to have a pulse on that, because what that enables me to do is ask questions, bring it front and center to everybody. Because without bringing it up and making everybody accountable for quality, it kind of gets swept under the rug. So I'd say that's a really big driver for quality. "Oh my gosh, I know leadership really cares about this because they keep asking about it." It's like just by asking is a huge driver for teams to start focusing on quality. So that's one piece of it.
The second piece is metrics, like you said, right? And so I've tweaked this over time and I continue to tweak it. Every place is a little bit different in how you track quality. I don't have like, this is an absolute metric that you have to track, but you need to have something that makes sense, some sort of quality metric that makes sense that is reviewed, normally on a quarterly basis so you can do the SLI, SLO stuff. I think that's great, although I think it can be very complicated for a lot of teams, and so they don't end up doing it. I think it's totally fine to just say, number of production issues, and it's so simple and straightforward that people can get it and they can get behind it. And so if you just track number of production issues and you set a target and year-over-year you try to drive that down. But set a target, teams tend to really rally around that and start driving towards meeting those goals.
Patrick: That's awesome.
Shelli: Dan, going back to the culture piece, and I completely agree with you that you have to change behaviors to change culture, but just curious because some of our listeners might be saying, "This is a great idea, I'd love to implement this in my tech team and change behaviors." But what if you're in a situation where the culture of the rest of the organization doesn't align with what you're trying to build within your teams?
Dan: It's a good question. What's interesting is every company I've been at has been different. The culture's different. They're very different, in fact. And when I first start talking about this, especially around, listen, engineering teams need to have a manager, they have to be accountable, they have to own their resources. The manager has to ensure that they control the team and what they're working on. It's the engineering manager's responsibility, and that's different than the product manager's responsibility, or product is like the what or the why and engineering is really the how. In trying to decouple that, they can really get overlapped, especially if you don't have the right leadership in engineering, which a lot of times when I join, it's like that. So the expectation, the culture either has different expectations than what I'm bringing or the culture itself is just different.
I always get pushback from my team or sometimes across the business units with what I'm trying to put in place. It's not huge. People are generally resistant to some sort of change, and so I have always I like to talk about it for a little bit. You can't just jump into implementation. You have to circulate, communicate, explain why. I like to do this in one-on-ones with different business leaders. Just talk about it, right? It allows you to fine-tune your message as you connect with different business leaders and get alignment. "Oh, okay. Yeah, sure. Your team still wants to own this piece to it. Oh, that doesn't matter. Sure. Yeah, your team can own that decision." And you kind of tweak it a little bit, but ultimately, I've found that you can always land on generality of your engineering team construct and the responsibilities of the team. So you talk about it for a little bit and then you just have to go. There's only so much talking you can do until you just have to go and do it.
And then you learn. I always have the mindset, we're iterative, we're agile, we're iterating. This isn't going to be perfect the first time. We'll figure it out. Try to get everybody to have that open mindset of, "Hey guys, we're agile. We're figuring this out. It's going to be okay if there's going to be some issues." And I tweak it along the way, I'd say you mold it around the edges to accommodate for the specific culture, but I think you can fit this in and I haven't found a place where I haven't been successful in implementing these changes.
Shelli: Awesome.
Patrick: Curious about the accountability ownership. You see plenty of statistics in the quiet quitting and people being a leader, being accountable, whether it's at the manager level, director level, they're difficult positions and I think maybe I'm biased because I live in the tech world, but I think it's very difficult to find tech leaders who understand the balance of ownership, authority, and leading. And we use this term servant leadership, which I think is a great structure that too often falls into servile leadership of I'm here to make my employees successful, not to help them be successful, not to be of service to them being successful. But is that something when you engage with an organization, I got to imagine you're assessing leadership skills at each one of these levels, and what is some of your secret sauce in addressing those challenges, whether that's coaching people up on it or identifying those types of skills?
Dan: Yeah. I think that's a really good question. That is one of the hardest roles to fill. I'd say it's somewhat unique, especially in the Chicagoland area, which, it's where I've had my professional career, what I have found is it's less common to have these engineering managers that are leaders, that are owners and accountable, drive change, make decisions. They don't necessarily just write code, they're there to be a manager or a leader, I should say, more so.
And so typically when I come into an organization, I think I'm all about forcing functions. I think you have to have one, I do a lot of one-on-ones. I think it's so important to get to know people. You can't get to know them in big groups. And I'm an introvert, so I prefer one-on-ones as opposed to large groups, but I also find that you just learn so much more about people and it allows you as you're kind of constructing the org structure, making sort of tweaks, where people fit in. Because really, it's somewhat of an art of understanding everyone has their strengths that we want to make sure we're focusing on, we're giving them the opportunity to focus on their strengths. And so finding the right place for people is super important and that's just listening, right? That's the conversations and that's listening.
So I do a lot of that, but I'm also a big proponent of you really have to understand the level that they're at in terms of their leadership capabilities and always give them a stretch opportunity. That is the number one way that I grow folks, is give them the stretch opportunity and then support them through it. You don't want to give them too large of a stretch where they're struggling and you have to essentially do it for them or if you don't, they're going to fail. You want to give them just enough so that they can come back to you and ask questions and you can observe and see where you need to catch them before they start going in the wrong place. But it's the stretch opportunities that I think are so important and then being there for your team to support them. Ensuring that they're successful, give them the confidence.
I have found that to be super successful. I've seen a lot of people have really strong career growth as I give them more and more and more, slowly give them larger teams, more complex projects, leadership, not just direct people leadership, but influential when they're not directly reporting to you, one of the hardest things to do, to drive a project with a lot of people that aren't reporting directly into you. So trying to slowly grow them and give them more stretch goals, super effective, so I'd say that's probably my number one secret weapon.
Patrick: Nice. Just to reiterate, because I think what you're doing is awesome. I think the idea that you have the one-to-ones, you do have these relationships, because I do think with the stretch goals and with growing people, it requires discomfort, so they're going to be uncomfortable. And even in the situation where you're supportive, it's not something that we do a lot where it's like, "Hey, we're going to ask people to be uncomfortable." And so I guess from your outcomes, I'm assuming they've been good, and I think a lot of that says a lot about how you engage as a leader. Because I think a lot of people when I see those types of environments, you have retention issues that crawl in because it is a stretch goal, followed up with not support, but maybe some feeling of failure. So when you know you're putting somebody into that level of growth slash discomfort, do you spend more time with that person? Is there anything that you could share about how you're doing that successfully?
Dan: Yeah. First around the discomfort thing, 100% agree with you on that. You're building a muscle. When you go to the gym and you work out, you're in pain. This is the best feeling in the world and then you wake up the next day and you're sore, but that's your muscles growing. It's the same thing. I think mentally when you build skills, you have to put yourself into positions where you're just a little bit uncomfortable. Just a little bit. Because you do it too much, and this is the art of it, you give somebody too much of a stretch, you're going to tear a ligament and then you're not going to recover. And so you have to be really careful with how much of a stretch, and it's just knowing the person, doing this a few times. What I have found is, I focus a lot on communicating the importance of ownership and accountability. And as I do that, it's kind of scary for folks, right? Because that's tough. What does that even mean?
Patrick: Blame. In a lot of organizations, it means blame.
Dan: Blame. Yeah, exactly. Yeah, that's exactly right.
Patrick: I worked in a large mobile phone company where accountability was career-ending, considering what... And this is a long time ago, but it became very clear to me, it was one of my first jobs, making decisions was not a good career choice.
Dan: Yeah, I totally agree. I mean, I see it all the time. People get put into a position where they're supposedly accountable for something and it's just not a good project, it's not a good place to be, you're kind of set up to fail, and then you get blamed for it. So I see that people get a little bit worried when I first start saying it. And so like I said before, you kind of just have to do it. You kind of just have to give them a little... Don't say it too much, don't focus too much on what accountability and ownership means, just start giving it to them. Give them a little bit more of it. And yes, you kind of have to gauge how much struggle there is, but I truly believe with that, how much time you spend on them, right?
There's situational leadership, which if you've been through, I think is a phenomenal... There's a framework, and I learned this as I went through the situational leadership training, there's different ways that you coach folks depending on how much skill they have, where they are in their development of a specific skill. And so you just have to identify that and maybe it's ask them questions, maybe it's give them the project plan, give them ideas on the steps along the way. Maybe it's give them the steps and maybe talk through the specific implementation, whatever it is. Maybe it's give them a partner to work with, but it's work. It's a lot of work as a leader to give somebody else something that's a stretch. You have to be really engaged to make sure that they're successful and ultimately, that's what makes you successful. Growing leaders, I think it really expedites your own career growth.
Patrick: Shelli, I know your whole career you've been focused on identification and the development of leaders within the organizations you've been at. Is there something that, a characteristic or something, that maybe other people just wouldn't see that you're like, "Yeah, this person can handle that accountability"? Because I do think it's easily said, it's very hard to do.
Shelli: Yeah. I think as long as you identify it upfront. For instance, we have three attributes that we always hire against. It's trust, bias for action, and entrepreneurial. So as long as we're sticking to the core attributes, we know people are going to be successful. So that's where I've seen it be successful in other organizations is everyone has the same north star, the same expectations, and you have to all be marching in the same direction. You can't have different leaders hiring for different attributes and styles and whatnot but to Dan's point, you always want to find out what have they done to develop leaders throughout their career, and that really speaks to how they're going to operate and how they're going to be successful.
Patrick: Awesome. And that was bias for action, entrepreneurial, and what was the-
Shelli: And trust.
Patrick: Trust, interesting. Dan, do you use something like that? We've got something in our organization that we reduce things down to just to kind of figure out is this the right fit culturally, not so much from a leadership standpoint, but we focus on leaders at every level. You can lead yourself, that is, it's not helpful to have leaders if you don't have individual contributors that can at least lead themselves. But is there something that you use that fits in that same kind of paradigm?
Dan: I don't have a standard, well-defined framework. I would say probably the couple big capabilities of folks or just the type of people I look to hire, one is I want to enjoy working. I spend more time working than I do with my family, so I have to really enjoy what I do and the people that I work with. So is it somebody that I want to work with, right? That's so important. I can't stress that enough, if it's an uncomfortable situation. And we're all different and so I strongly believe in hiring a diverse set of folks, but you can accomplish that and still really enjoy working with people.
Patrick: They're not mutually exclusive.
Dan: Exactly.
Patrick: Right. And in fact, it's nice to have some diversity in the band, right?
Dan: Absolutely. Yeah. I do not like working... Actually, I would never want to work for myself.
Patrick: Because you got one, right? You got one of you. I don't need another you.
Dan: That's exactly right.
Patrick: I say the same thing. If you have too many Pats in the room, it's not going to be productive. We're just going to argue about silly things, probably way too many movie quotes. It's not going to be productive, right?
Dan: And I'm actually the flip side, so we'd probably work well together, but I don't have any movie quotes. I don't watch movies. I'm the boring person in the room that's probably just thinking about how do I build this thing? And I don't want to work with another one of me. I want some fun people. I want some people that could start the jokes with me. So absolutely, I think you want to find people that kind of round you out, but also that you're going to enjoy working with. So huge, huge piece to it. I want somebody who's passionate. I want them to have an opinion. When I ask questions, to really have some sort of thoughtful position behind it. It doesn't have to be the same thing that the way I think about it, but I want them to be thoughtful and opinionated and I want them to be innovative. Everything we do, we have to come with a creative lens, and innovation gives the willing to take risks sort of thing, and so I think with those few attributes, I've found it to be successful for me.
Patrick: Well, I think the first thing, though, but you mentioned, I think it's really important, especially as people with engineering backgrounds, I don't think it's shared enough, especially when people are going through school, how important it is to just be a good teammate. To your point of, hey, you could be the greatest software engineer or the greatest engineer in whatever discipline. If nobody likes working with you, it's not going to be very effective, right? And so I do think that's one of those critical things that engineering school, I remember how much I enjoyed doing labs together and when you find your group, and we used to call it full-contact programming because we're fighting for the keyboard. Where it's like, "No, you're wrong. Give it to me." And those are the kind of attributes.
But the other part, in addition to the likability, you use the term opinionated and innovative. And I like using shocking words to get people to disagree with me because I am disagreeable. And I do think that, I think it gets misinterpreted. Intentionally disagreeable or strategically disagreeable or the capacity to be disagreeable with the idea that I disagree. Not so much I'm disagreeable because then there's that nobody likes working with you. But to your point is, there's a fine balance of opinionated and unlikeable. Of like, "Hey, how do I demonstrate that..." And it's critical to get the best out of everybody is that if you have an opinion, you should share it. Certain personality types, as you mentioned, some people are more willing to do it than others. Is there something that you do to encourage people to share that when it may be not their natural behavior?
Dan: Yeah, it absolutely takes time for people to feel comfortable disagreeing, being opinionated, disagreeing with me. So like Shelli said, trust is so important. And so it takes time. You have to build trust with your team, but I invite feedback. And I think the most important thing is you invite it and you demonstrate how to take it. And so give me feedback, and it starts off slow, but then people will start giving feedback and then kind of like the "yes and" sort of mindset. So you listen and "Yeah, and this." Or, "But, what about thinking about this?" It's super important not to directly disagree. That's how I feel. You don't want to shoot them down. You kind of want to start encouraging it, but being able to provide your own feedback while still encouraging.
So I started inviting it on myself a lot and I'll tell you, as a leader, back in the day when I had my first engineering team, it's uncomfortable to get that disagreement. To hear somebody else be opinionated and disagree is super uncomfortable, and it took me a really long time to get over that and to actually enjoy it. To actually say-
Patrick: To value it, right? Really value it.
Dan: Exactly, value it, yeah. That's a better way to say it. I really value that. And so I think it's uncomfortable for a leader to invite it and to take it, but if you can, you encourage your whole team to, and man, once you get your team, that builds more trust and then you really get to the right answer faster.
Patrick: Awesome.
Shelli: Did you have a boss or a leader in the past that inspired you or created the leader you are today?
Dan: Mm-hmm. I would explain it the other way.
Patrick: I get it.
Dan: Yeah. I saw leaders I did not want to be.
Shelli: That's equally as helpful.
Patrick: The anti-patterns are way more instructive to the future of like, "I'll never be that guy. I will never do that to somebody."
Dan: I just think you realize something much faster when there's pain as opposed to what's the opposite of pain, benefit, pleasure. You really don't want the pain, and the pleasure you kind of get used to over time and you forget about that.
Patrick: Or you mistake it as just the way it is, right? You're like, this is... Pain you got to deal with, right? Pleasure is like, "Oh, this is great. I love this chair and the coffee tastes delicious. And the boss is nice and he listens to me. He's not very effective, but at least he's pleasant enough to talk to me." Having to walk past all the empty parking spots at the company because none of the VPs are there in the middle of winter and you've got to park a mile out to go to the big back padding meeting of all the VPs talking about how great they are in front of 500 people where you're like, "I hate all of you more today. I didn't like you yesterday and I'm less motivated." The whole Office Space movie is a clear, this is what's wrong with most tech companies. Okay so leaders, like what leaders, what'd you learn from, who is that?
Dan: Bad leaders. Learn from bad leaders.
Patrick: Right, learn from bad leaders. Which is ironic, because one of my sons brought it up just yesterday. That he's like, "Yeah, I just know exactly what I won't be doing when I'm in charge." And that's like a 15-year-old. And so I do think that's really foundational. I think that's one of the bigger challenges when it comes to the tech space is that there isn't a cohesive or invested leadership development process. And I do see some of the challenges that the not healthy disagreeable people get promoted just because they're willing to talk and be disagreeable in the absence of other people who in a not healthy environment, they're not going to have opinions because they're just going to get themselves into trouble so they don't talk, right? And so the advancement of some of the people that you really don't want to have leading others, unfortunately, is too high.
Shelli: I think on the flip side too, a lot of people get promoted because they're very, very good, but at the end of the day, they don't enjoy being managers. They just want to-
Patrick: That's true too.
Shelli: ... keep doing great work. Have you ever run into that, Dan?
Dan: Oh yeah, absolutely. So I mean, a lot of my time is spent as I'm thinking through org structures and I talk about engineering managers and their people leaders and quickly people go to, "But I don't want to be a manager. Are you saying the only way for me to move up in my career is through management? After a senior software engineer, I have to go into management, is that the thing?" No, it's no, right? And I think we're seeing that a lot of the org structures, the career ladders, having both a management career ladder as well as an individual career ladder. You don't need to, as an individual contributor, you don't need to become a manager. You can have equally as much impact and scope as becoming a principal engineer or a staff engineer, architect. So we have to make sure we're finding the right path for folks and not artificially moving them into the wrong place because like you said, we don't want to put the wrong people in, especially as you get to the leadership role, you don't want to put them into the wrong position.
Patrick: But it's almost like the ones that say, "I don't want to be the manager" are the ones you want to have as the manager. And there's a great book by Lencioni called The Motive, and I think it really, like all his books, they're great and they're short, and so I like the brevity as much I like the density of the good stuff. But he touches on this challenge of most people when they're looking for promotion, it's either prestige... It's inward stuff, it's selfish, right? They're looking for higher salaries, they're looking for more power, more authority or prestige. And really, you're looking for people who care about others.
And Shelli and I have met so many, what I would consider, those non-commissioned officers in the military where these guys are the absolute sinew of how our military works. Now, their love for their teammates is so obvious, how much they concern themselves with their teammates, but they also have this dedication to mission of like, "Hey, this sucks. I'm worried about all of you, but we still got to go do a thing." And I do think there's a way that we, the military, the Army specifically, spend so much time on developing these leadership skills. I just think this is the thing that we think about with AI and the advancement of the criticality of high-performing teams and that pizza team size leadership is going to be... I tell everybody my strategic initiative is, whoever has the most leaders will win. You don't even need to be strategically advantageous. You just have to have more adults, more leaders, and you'll win. And so strategically, that's where I think the greatest risk is the idea that no one's a leader.
There was a thing in Wall Street Journal that said 75% of Americans believe they could be just as productive without their manager. And I thought they should rewrite that to 75% of Americans think they can be just as unproductive without their manager. And I think, again, I'm not picking on that. I'm saying it's the absence of good leadership, right?
Dan: Absolutely.
Patrick: What is that clarity? And you talk about how do we get them to do the behavior before they have the belief, right? How do they demonstrate that so that it actually becomes, "This is how I do things." So we're running out of time. I would love to keep this conversation going. I really appreciate everything taking the time today.
Dan: No, this is great.
Patrick: Honestly, it's great leadership stuff. I really, really enjoyed this conversation. Congratulations again on the new job, really wishing you nothing but the best. They're lucky to have you, man. I know they're a great organization, but you're a great leader and they're very lucky to have you.
Dan: Awesome. Yeah, thanks so much. I had a great time chatting with you guys. Really love this stuff. I could talk about this for hours or days, and maybe some time you'll invite me back and we can talk more about some innovation.
Shelli: Yeah, absolutely.
Patrick: Well, now you have no choice. Now you made a promise. I'm going to hold you to that one.
Dan: Yeah. Awesome.
Patrick: Awesome. Thank you. So we also want to thank you, our listeners. We appreciate everyone joining us.
Shelli: And if you'd like to receive new episodes as they're published, you can subscribe by visiting our website at dragonspears.com/podcast or find us on iTunes, Spotify, or wherever you get your podcasts.
Patrick: This episode was sponsored by DragonSpears and produced by Dante32.
