Host - Pat Sweet: Just quickly before we get started. I wanted to let you know about a free ebook. I wrote a little while back called engineering leadership, 1 0 1 practical insights for becoming a leader at any stage. It shows you how to grow as a leader, no matter where you are in your career. The important differences between management and leadership and it dispels some of the common myths engineers have about leadership. And like I said, it's free. So if you're interested, you can go ahead and download your copy@engineeringandleadership.com slash leadership. 1 0 1 that's engineering and leadership.com/leadership. The number 1 0 1. This is the engineering and leadership podcast with pat sweet episode 41.

Host - Pat Sweet: Welcome to the engineering and leadership podcast. The show dedicated to helping engineers thrive today. I speak with Dan Landrigan CTO of bureaucrat about helping engineering teams take ownership and stay curious.

Host - Pat Sweet: Hi everyone. And welcome to the show. I of course, pat sweet and I'm very excited, very, very excited to have you back here again with me for this. The 41st episode of the podcast have a great interview with Dan linchpin lined up, but just a couple of public service announcements. Before I get to that first, I wanted to mention an upcoming webinar. If you're listening to this just as it's released, the webinar is going to be within 24 hours. This is the inbox detox webinar, where I present a system on how you can take better control of your inbox and make more time for real work. So you can sign up for that@engineeringandleadership.com slash inbox, detox webinar. Again, that'll be happening on October 26th. So if you miss that one, no problem. You can still sign up and I'll notify you when I run this webinar again, at some point in the future, I'll absolutely be doing this one over again.

Host - Pat Sweet: And I'm very excited to announce the winner of my lead from the jump seat signed book contest that I've been running over the last little bit. Unfortunately I don't, I'm not quite ready yet. I'm very, very close. I know the winners email address, but I still need to hear back from them to make sure that they are a real person and B to get the contact information, their details, so that I can announce an actual name instead of broadcasting someone's email address on the internet. So stay tuned. You'll be hearing about that next week. Thanks to all of those who entered the contest. If you didn't win, still do go check the book out, go pick up a copy. It's a, it's a great read. Can't recommend it highly enough. You can check out a link to that in the show notes@engineeringandleadership.com slash episode 41. All right, let's get to the main content for today.

Host - Pat Sweet: Peter Drucker, the father of modern management thinking once said that culture eats strategy for breakfast, that wasn't a knock on how important strategy is rather he's emphasizing the importance that culture plays within the modern organization. Today's guest would no doubt share that same sentiment because today I speak with Dan Landrigan. The CTO of Vericut about the role culture plays in a technical organization, and specifically about the importance of both accountability and curiosity for Vericode's engineering team. Vera provides the first end-to-end quoting enrollment and membership management API platform for health insurance and employee benefits by simplifying the exchange of data between carriers and technology companies Vericut is enabling the digital transformation of the health insurance and employee benefits industry as CTO. Dan leads, the development and maintenance of aircraft's API platform. Previously, Mr. Landsman served as CTO at life Booker a marketing SAS provider for the health and beauty industry where he developed dynamic pricing algorithms and tools to manage the company's inventory of service abilities. He was also the CTO of law, dingo.com a platform designed to help people find and hire a lawyer virtually. Here's my conversation with Dan, Mr. Dan land, Kevin, welcome to the engineering leadership podcast. Thank you so much for being here with me today. Thanks

Guest - Dan Langevin: For having me. I wanted to get

Host - Pat Sweet: Started today and just learn a little bit more about, about you and your company and what your role is within credit as, as the CTO.

Guest - Dan Langevin: Sure. So their credit is an API middleware company. So it's a really technical company. We connect insurance carriers and their legacy systems to benefits, administrators and other InsureTechs better ultimately touching consumers and need to transmit and receive data from those insurance carriers, mostly around insurance products. So health insurance, or other employee benefits and you know, and distribution and management of policies once they're once someone's purchased a product. So my role as I'm CTO and co-founder so I kind of have worn a lot of hats throughout the our development I'm currently overseeing product and engineering and also our operations which is pretty large component of what we do actually. In addition to the product and engineering.

Host - Pat Sweet: Yeah, I imagine that's a lot, like you say, a lot of hats and huge breadth there and in that particular world I'd love to know what got you interested in, in this particular industry. This is, this is a world that it strikes me that it's phenomenally complex, highly regulated. I imagine from jurisdiction to jurisdiction, there's an awful lot that you need to, to, to juggle and think about. So what w w what got you into this in the first place?

Guest - Dan Langevin: Yeah, I think that the complexity is a really interesting challenge in this space and also the lack of really good technical solutions. So, you know, we think of we're talking to one of our investors a while back, and they were of the opinion that the InsureTech has kind of 10 years behind where FinTech was technically speaking. And there's a lot of need for this data. There's a lot of kind of early adept people who are really early adopters of technology. But haven't evolved with the time in the insurance space. And so it's a really interesting opportunity to kind of bring automation and modern technology to that space. But like you said, it's very challenging to, because there are 50 years of ingrained process around the legacy's systems as well,

Host - Pat Sweet: Spoken like a true engineer. You, you see, you see a, a complex challenge and you gravitate toward it. So I, I totally appreciate that. W one of the things I wanted to talk about today, or rather the main conversation today is more about, more about the people side of your role then than the underlying technology that those people are developing. And two of the themes that we wanted to cover today were curiosity and accountability. And from what I understand from the way you lead and what you find is important when running a large technical organization, it's, it's important to have that sense of accountability and curiosity, oh, why is this so important for a technical team that, that most people would think, you know, it's more important to know the coding and the infrastructure and the nuts and bolts. What, what, why, why did these themes emerge for you?

Guest - Dan Langevin: So, in my experience the technical part is usually the easier part and the people is the hard part. And that's true in a technology organization, just the same as it's true in any other type of people management position. And, you know, curiosity and accountability, I think are you know, marks of a, of a healthy culture where engineers are aligned with what the business needs and are pushing forward, you know, kind of product on the product roadmap of their own volition and adding to it rather than being dictated you know, a spec from the business or from product. But we think it's really important that engineers feel like they're part of that process and that they are contributing to the success of the organization as a whole,

Host - Pat Sweet: Right? So, so we're talking about this difference between a code monkey who understands the language and someone who understands the why behind it. And, and to me, that's a big part of, of accountability is, is doing, doing something with an understanding of, of what you're trying to accomplish. But, but accountability has kind of a negative, a negative connotation to it. You, you hold people accountable. I've, I've worked with organizations who held literally what they called hold to account meetings, where executives sat there and stared you in the eye to make you squirm until you confess you didn't do what you said you were going to do. I don't think that that's what you're talking about here. So, so in your, in your mind, what, what do you mean when you say accountability?

Guest - Dan Langevin: So the business needs predictability, our sales and marketing team need to know when things are going to be done. What types of functionality they're going to be able to sell and promote customers need to know what's going to be available. So I think, you know, accountability in terms of meeting commitments feeds into that predictability right. And in order to feel accountable and produce predictability, you really need commitment from the engineering team. So when when deadlines are being set, if there's, let's say there's an external deadline, a product needs to be launched by a specific date for external reasons. The first step is that you really need everybody across the organization to agree that this is achievable and you know, what success looks like. And once engineers are, are bought into that, I find that they're naturally very good problem solvers.

Guest - Dan Langevin: And they'll often suggest solutions that we hadn't thought of a product team. Hadn't thought of maybe the sales team hadn't heard from customers that can get us to meet those deadlines in a more quick and a creative way that that will get us there faster. But in order to, to, you have to empower them to make those suggestions and get the commitment from them that they understand why, why are we marching towards this deadline? It's not just an arbitrary deadline that somebody put there, it's a part of, sort of the company's mission and there there's meaning behind it. And they have that level of commitment.

Host - Pat Sweet: You've anticipated my next question a little bit with what you're saying here, how do you in, in really concrete terms, get a team to, to feel that sense of ownership, to, to feel accountable for their work. And I think, I think you said probably what's most important is you get that alignment first. You don't set a deadline, it doesn't come down from on high. There's a certain degree of collaboration first, a reasonableness test to make sure that, you know, it's something that you're not breaking the laws of physics to, to meet a crazy deadline. W w what other kinds of things can you do to really imbue that sense of ownership within a team?

Guest - Dan Langevin: The biggest thing to me is to allow engineers to be big contributors to the solutioning. So the way that something gets built and the exact feature set that ends up being delivered to customers. So rather than having the product team go to sales and customers and come up with a very prescriptive, this here's the problem. And here's how we're going to solve it. Start with here's the problem. Here's some ideas about how we can solve it, and let's collaborate on what the, what the final solution looks like taking into consideration external factors like deadlines. Like if there's some market reason that we have to have it done by the state, okay, how do we solve this problem in the timeframe that we have? We have three sprints to do this, what can we do to solve it three sprints? And that sort of starts it, it breaks you know a cycle of, you know, we D you know, from the business, we dictate this deadline and these features, and you must do it by this date. That's not something that the engineers have agreed to necessarily upfront, and oftentimes they will not have a very high level of commitment if that's the dynamic that created.

Host - Pat Sweet: Do you have any examples, whether it Vera credit or anywhere else where things did not pan out that way? Like, is there something in your mind that, that helped you learn that lesson? You know, I know your background is in is in software and web development. You, you come from this world I'm sure. At some point you were on the receiving end of an impossible deadline or an impossible ask, how did that, how does that make you feel as someone who's who's on that receiving end?

Guest - Dan Langevin: Yeah, I mean, I, I've definitely been in the situation where I felt like there was a deadline and that either was, or at least seemed arbitrary to me or was not achievable. And I think the main thing that, like, my takeaway from that is that the biggest problem was that I didn't understand what the goal was, why we were trying to achieve it and why it needed to be done by this time. Cause going back to something that we were talking about earlier your engineers are usually are often your, your best or among your best problem solvers and creative thinkers in your organization. So if you give them parameters, they'll often come up with a solution to them most of the time that will achieve whatever your goal is, as long as they have enough information to do so. So I think where our frustration comes in is if you don't have you as an engineer, don't have the opportunity to make a contribution like that. And instead you feel like there's an arbitrary deadline and feature set that you have to hit for reasons you don't understand.

Host - Pat Sweet: Yeah. I think, I think there's this natural attention almost between the, the, the engineering teams in an organization and stakeholders whether internal to the organization or external stakeholders, investors, there's this, there's this natural tension that exists between wanting to move quickly, wanting to do a really incredible work. And then, and then the understanding on the technical side of what it's gonna take to turn someone's vision into reality. I imagine that as a CTL, this is a big part of your work is balancing the expectations of the outside world while respecting the reality is your engineering team. Do you have any, any particular stories or lessons learned, any recommendations that you might make to others who are in similar situations? Because I think whether you're a CTO or you're a first-line manager, there's always going to be that tension between your team and trying to encourage them to do great work while at the same time, protecting them to some extent so that you're not constantly driving them into the ground, asking, asking for them to do heroes work all the time.

Guest - Dan Langevin: Yeah. I mean, I think there's a, there's a number of strategies that I've found work well. First there's, there is on some level an inherent tension. You know, the business is always going to want more, better, faster so that we can, we can move faster. And and you know, you as a, on the business side, you don't always necessarily think through all the implications of every new thing that we add. And that comes into for us on our operation side as well, because one of the, one of the challenges in our business is that transactions need to work a hundred percent of the time. They're they're financial type transactions. If somebody signs up for insurance, it has to work. We can't have, you know, if one 10th of 1% of the transactions fail, that's a huge problem.

Guest - Dan Langevin: Right. So as we add new things, we need to consider that either we need a technical solution to that that failure case, or we need an operational one. And those types of that sort of level of complexity doesn't is not always the top of mind on your, you know, on your go to market side, like your sales and marketing sides. So that will create a little bit of of tension there. I think that the the, the most important tool to me, is having a clear roadmap and a clear understanding of what we're doing and why we're doing it across the organization. So from your executive leadership, into your sales, leadership, and marketing through product and engineering, to all have a shared understanding of what we're trying to achieve, why we're trying to achieve it, what does success look like?

Guest - Dan Langevin: And, you know, what sort of a timeframe within that we we take a couple of different approaches to setting internal deadlines. The majority, wherever possible, the deadlines are engineering driven. So engineers will say, well, we'll commit to, we believe we can achieve this goal by this date, given these resources. Then we encourage them to be not too overly optimistic and setting those so that they're not sending themselves up for, for a crunch time kind of rotation. And just being really transparent about that. You know, the, the things that you know, you as a as an executive sound easy, might be hard and, and vice versa. So I think just having that, that two way communication is, is really clear critical so that we don't get into a situation where the team's worked really hard and they've produced something and it doesn't meet expectations. That's sort of the worst case scenario that you want to avoid.

Host - Pat Sweet: Absolutely. What are the themes that, that is emerging here is the importance of making sure your technical team understands why they're, they're being given the projects and the work that they're being given that they understand that, that business context. And I think that ties, that ties nicely into the, the second word that I wanted to explore here with you. And that is curiosity. And I think that when technical teams understand the why behind an organization, what is the vision, what are we trying to achieve that enables a certain curiosity, you can kind of start to think about, ah, how, how might we do X? How do you how do you encourage engineers and technical people to to follow that curiosity, it, especially in an environment, you know, th this is a, this is a fast growing company. You've got deadlines, you've got, you've got competition and, and stakeholders satisfy. There's not a lot of time for goofing around. So how do you, how do you, how do you satisfy that need to be curious both, both the need on the part of the engineers and the need from the company's perspective to, to come up with new and interesting solutions.

Guest - Dan Langevin: Yeah, so, I mean, I think engineers are going to be curious by nature, and as the thing we hire for that we look into through our interview process, we look for people who like curiosity and craftsmanship are two things that are important to us. So we want people who want to understand things about their work and about the world in general and just are curious by nature. And we take a lot of pride in producing quality product. So I think it starts, you know, I think you have to hire well as a, as a baseline from there, you know, engineers will almost always be curious about code and how things work. Usually they're also curious about the domain, so sort of the business context for what they're what they're working on. But we also encourage them to be curious about the business and its customers.

Guest - Dan Langevin: So interacting with product sales executive leadership, to understand what are we building, what problem are we solving and develop a passion for the problem that we're solving. So that's, and, and compassion for you. So those are things that, you know, we work to instill in the engineering organization and that feeds into some of the you know, their ability to contribute, to create solutions and ways to solve problems that we may not have thought of in a, you know, a traditional kind of spec. The other piece of this is that you do need to allow time for people to experiment and follow their curiosity. So we do that by allocating some amount of bandwidth, like leaving enough space in the roadmap that we don't, we can have you know, technical debt refactoring to pay back technical debt and encourage that our engineers think about how the code may have diverged from our understanding of the domain which is the definition that I use at least for technical debt. And then refactor, it such that did, is it is, you know, back in line or closer to back in line with the domain. And that in itself is is a sort of experimental process.

Host - Pat Sweet: Do you ever get any pushback when it comes to, to holding a little bit of margin to, to, to address those things? Cause I, you know, if I put on my my CFO hat for a moment, I look at that and I think, Ooh, overhead, what are those, what are those guys doing over an engineering?

Guest - Dan Langevin: So I think that is is a way that that people who have less experience in working at a tech first company might look at it the way that w that we think about it and where that I communicated with the rest of the team is that we're making it easier to do things in the future. If we don't do these things, the next feature is going to take three sprints instead of two sprints or whatever the case may be. So we're making investments that will pay off in our ability to execute more quickly in the future.

Host - Pat Sweet: Yeah, it makes perfect sense. Perfect sense to cast it as a, as an investment, as opposed to a cost. One of the things you mentioned earlier was the importance of, of hiring for curiosity and craftsmanship, and, and it, it occurred to me that that rolled off your tongue very comfortably. Like this is clearly something that you are looking for when you bring people on. And, and the craftsmanship is not one that I hear an awful lot of in, in technical circles. I'd love to know how do you, how do you find that? How do you evaluate that? I'm, I'm imagining sitting across from someone in an interview and, and trying to evaluate their curiosity and thinking that I'm not, I'm not sure how I would do that. How do you approach that at Veracruz?

Guest - Dan Langevin: So there's a couple and I won't go extreme detail on our interview process, but there's a couple of points where we, where we hit on that. The first is in our initial screen where we ask somebody to describe a a system they built or contributed to that they're really proud of what was good about it. Why w why did it work? And you get a lot from an answer like that in terms of how, how, you know, in-depth, the person understands the project code that they've worked on, and they're, you know, we're looking for like a sense of pride that they contributed something that was exceptionally good and why, and understand why it was exceptional. So that's more of a, you know it's sort of a softer evaluation criteria. But that's, that's one point. The second is that in our technical screen, we give we give the person a problem that we expect them to work through, but is not solvable in the timeframe allowed.

Guest - Dan Langevin: So you can't say it's not expected. You, they know that upfront, it's not expected that you're going to complete this entire task end to end. It's a, it's a larger project you're supposed to get started on it, and we see how you approach it. But one of the things that we go through, we leave time at the end and we'll talk through, well, if you had more time, what would you have done? What did you learn? What compromises did you know that you were making versus, you know, making what we would consider compromises that you didn't know you were making which would indicate sort of lack of understanding. And how does the person balance the desire for for craftsmanship with the time pressure that we create in this, in this interview situation is that's another thing that we look for someone who says, if, you know, given all the time in the world, I would have done X, Y, and Z. These are all the things that are, are wrong with the approach. But this is, this is the fastest way to get to this point. So these are the, these are the trade offs I made and understands those things.

Host - Pat Sweet: Yeah, I think that's brilliant. I think that's brilliant understanding how people think is, is ultimately what you're, what you're getting at there. And I think you can to learn a lot from those, those high pressure situations. So that, that, that's great. We've been talking about about curiosity and accountability and, and these are both things that are hallmarks of a particular culture. So I wanted to ask you a little bit about culture especially in light of that. There's some really good news earlier this year from Vericut I understand you successfully completed a series B round funding bringing $23 million into, into company coffers. So that's very exciting. But imagine as a, as an executive in the company, this creates not only excitement, but there must be a hint of dread because this will, this will fundamentally transform the company in terms of the size of your operations, the size of your team, if growth is the goal, then, then people come along with that. And from the conversations I've had with, with other, other executives, other CTOs maintaining culture over a period of rapid growth is a, is a major challenge. So I wanted to ask you about that, about how do you, how do you plan on maintaining this, this sense of accountability, this sense of curiosity, despite bringing in potentially a, a huge number of new new people.

Guest - Dan Langevin: And so just for context, we've more than doubled our engineering team in the last six months or so. So we're going through this right now first I'll, I mean, I'll go back to hiring it's in addition to, you know, the us evaluating the candidate, we try to be really transparent about what our values are and what type of person will be successful here. So ideally you want people who that doesn't align with the way that they want to work to self-select out, or, you know, make it clear that it's not going to be a good fit before they get in the door. I think that's you know, if you're looking to hire kind of that at all costs that's a potential pitfall of that strategy that you could end up with people who don't necessarily align to your, your values, and then the culture starts to change in ways that you didn't predict and you don't want so that's sort of the first piece.

Guest - Dan Langevin: The second is to have a really good onboarding strategy. It's, we've, we've spent a lot of time and effort in developing a, you know, a series of steps to incorporate somebody into the team, get them productive, quickly, get them acclimated to the way that we work to our software development life cycle, as quickly as possible, and also to onboard them in the business and the domain. So have them spend time with the leaders of all of the other departments to understand what those departments do, how they fit into the business overall and just, you know, get them kinda bought in to the company as a whole, like, they're not joining the engineering team, they're joining the aircraft and this is what barricade is all about. So those are some things that have worked well for us so far and that we plan to double down on

Host - Pat Sweet: That's great. I, I, I hear an awful lot in, in the answers that you're giving that you have systems in place and, and there's a very, this very structured approach to how you how you find people, how you evaluate them, how you bring them on is this something that comes naturally to you as, as someone with a technical background? Like you, you, you have this vision for how the, the people systems will play out, or is it something that you've you've learned over time is, is just the best way to to, to, to lead people within an organization?

Guest - Dan Langevin: It's both I mean, some of these are things that I've, I've learned or that others some are things that others have brought into the organization and best practices for they've seen other places. And one of the things that we, we do through any critical process, so we, we identified hiring and onboarding for engineering as, as critical processes for us, at least in this time period, given the level of growth that, that we're we're seeking to achieve is that we have the people who are involved in it and we treat it similar to the way that our software development life cycle works. We, we retro them every couple of weeks, especially going through what's working, what's not working. What can we tweak? What can we try? We try to gather data wherever we can. We use applicant tracking system to see where drop-off happens.

Guest - Dan Langevin: We have some qualitative observation of where that drop off happens. And similarly with onboarding, we will take the, we retro with the engineers who have gone through onboarding with the engineering managers who have had engineers onboard on their teams. And you know, what's working, what's not working and we try to have a really tight feedback loop and iterate on it quickly so that we can, we can make corrections. And the other thing I will say about that second piece is the fact that we do that helps with the onboarding, because it shows the people who are joining the organization, that one of the things that's important to us is to continually improve,

Host - Pat Sweet: Right? And that, and that's positive message. That's something you want prospective employees to see that this is a place of quality and, and of improving quality as well. I think that's a, I think that's great, Dan, as we, as we kind of come to a close here on the conversation, I want to bring it back to our initial our initial topics for today were, were, were accountability and curiosity, and, and I'd love to know more about you and what, what are, what are your goals? What are you curious about in this next phase of your career and, and for,

Guest - Dan Langevin: You know, as a, as a co-founder on always accountable to the business and pretty curious by nature you know, I'm an engineer by background. But my goals are really to continue to build on the things that have worked for us and gotten us to this point but create a culture and a team that are flexible enough to adapt to the challenges that are ahead of us, because the things that have worked for us to this point are not necessarily the things that will work for us, you know, going from a hundred people to 200 people or to 500 people you know, those those strategies need to change. So I'm excited to go through that process and to, to, you know, learn why, what works well for us and, you know, ultimately to build a really high performing team.

Host - Pat Sweet: Fantastic. Thank you so much for that, Dan, if people would like to know more about you or learn more about [inaudible] where the best places for them to go.

Guest - Dan Langevin: Sure. So we have Vericode, we have a blog that has a lot of really interesting con varied content. That's about health insurance, about InsureTech. There's an engineering section that has as a bunch of really interesting technical pieces, some of which I've contributed to. So that's, that's one place. You can check out my get hub. I've got a few projects that I've done personally that are, might be kind of, of interest. So it's probably the best places.

Host - Pat Sweet: Yeah, that's perfect. I'll put links to both of those on the show notes. Once again, Dan linchpin. I really appreciate your time. Thank you so much for joining me today.

Guest - Dan Langevin: Thank you.

Host - Pat Sweet: Thank you. Once again, Mr. Dan Lanvin as always a really interesting conversation, lots of insights. I was typing furiously. As I listened back to this episode, lots of, lots of really good advice, lots of gems. One of the things that stood out to me was this idea that a business needs predictability. And that means that the engineering team needs to be accountable for its commitments. And I suppose that goes for any team as an organization, you are operating as part of a greater whole. So w your team, once you make commitment, you say, yep, we're going to do a certain thing by a certain date. You have to understand that others are relying on you, and if you don't make your commitments, the whole system falls apart. So very, very important point that Dan was making there is in order to have predictability and organization needs to be able to rely on its constituent parts to do what they said they were going to do.

Host - Pat Sweet: And that includes the engineering team. No doubt. One of the other things Dan mentioned was that engineers need to be empowered. And the way to do that is to tell them what the company needs from them. And maybe more importantly, why that thing is needed. And that's when engineers get creative and engineers are creative people, we are creative problem. There's, there's a part of our brains that that's just how we work. When presented with a challenge. The problem is a lot of leaders, a lot of organizations don't do a good job of providing that insight to their engineers, and then helping them understand the, so what, when an engineer understands the what and the why some really some pretty magical things can happen. So I, I really, I really thought that was an important point that Dan made there close to the end of the interview.

Host - Pat Sweet: We got to talking about how culture is impacted by rapid growth and rapid growth can mean a project or a program within an existing organization that is growing quickly or needs to scale up quickly, or maybe it's a whole organization like a startup, either way, if you are hiring in an emergency situation, the chances are that that's going to cause culture problems within your company, because you can be less discerning. You need all hands on deck and then some, a week ago yesterday. So when you're hiring in a situation like that, you're bound to make missteps. And, and one of the things that the Dan highlighted is that the missteps are not going to be on the technical side. It's easy to tell if someone has the right education, the right experience, it's going to be on the cultural side because that's trickier to evaluate.

Host - Pat Sweet: And I really liked how Dan and [inaudible] have a system set up. They are looking specifically for cultural fit when they do their interviews, when they are scanning candidates for potential hires. So I thought that was really great. There's a lot there that I think we can all take and apply in our own situations, whether or not we work in software organizations, whether or not we work in insurance or any other industry. I think these are our universal truths. So thank you. Once again, Dan linchpin at the end of the interview, he mentioned a couple of places you can go to learn more, I'll have links to all of that in the show notes. So if you're curious, I do encourage you to go check it out. Next up, we have the engineering and leadership mailbag.

Host - Pat Sweet: Well, my friends, you know how this works, this is the part of the show where I read your messages and answer your questions. I promise to read everything you send me. And I promise to read my favorites right here on the podcast Duncan, oh, U of R of open book.works has been launching into an interesting little project. And he's sharing a lot of material that I helped work on. On behalf of the American society of engineering management. There was a series that a couple of colleagues and I worked on to, to distill the engineering management body of knowledge into bite-sized chunks basically a blog post per chapter of the inbox. And anyway, Duncan has been sharing this over time within his network. And he's tagged me on LinkedIn a couple of times. So I just wanted to give a shout out to Duncan and to his organization, which is looking to try to create business savvy engineers there.

Host - Pat Sweet: Their whole mantra is around this idea that when an engineer understands the business side of the organization, good things can happen. And it's interesting. I hadn't really planned this out this way, but a lot of what I talked to dad about related to the same fundamental truth, when the engineers understand what's going on and why they can do really pretty special stuff. So be sure to link to Duncan's organization in his LinkedIn profile in the show notes. So do you go check that out? Also in LinkedIn, I posted something about this idea I had, that I wanted to share about the importance of managers needing to let their teams solve their own problems as leaders in tech. It's so easy a to get into management because you are a subject matter expert. A lot of people get into management because they were so good.

Host - Pat Sweet: Technically they have all the answers, they've seen it all. They've done it all from the technical standpoint. And, and that's how they get themselves into trouble when they get into leadership and management is when someone comes to them from their team, asking for assistance, that manager who used to be the subject matter expert knows the answer, gives the answer and says, go away. I'm busy. And there's a real opportunity missed there. People grow by confronting challenges at the, at the edge of their capability, their current capability. And if you, as a manager or a leader, don't give them the opportunity to struggle. And I know that sounds really funny, but, but really it is an opportunity to, to grow and figure things out. Then they never will. They never will. And then they will be constantly reliant on you as the manager to solve their problems, which puts you in a bad spot and prevents the team from growing.

Host - Pat Sweet: So this generated quite a bit of conversation on LinkedIn. And I wanted to share some of the comments. Dave w said, a corroboree may be that when faced with your own problem, and you need help from your manager to state the facts and float an idea yourself for how to move forward. It may be wrong, quote unquote, but it's an opportunity to hear why another option. It may fit better in the broader picture. It also indicates you're open to stretch assignments yourself and Dave, I really appreciate this idea. I think this is brilliant. And this is something that I recommend to my own teams all the time is there will be times where you need help. There's no question about that. And that's not the message here. I'm not saying managers never helped your teams. It's just, you need to pick and choose your moments.

Host - Pat Sweet: And what I would say is when you, as an individual are going up to your own manager, always come with at least some sort of an idea, demonstrating some sort of thought what into the challenge, because then it's not okay, solve this problem for me. It's, here are some options I'm evaluating and here's the specific thing I'm hung up on in trying to decide which way to go. Those are two very different conversations, and that puts you at the edge of your capability. You've drawn that line and said, okay, I've made it up to here. And I just need that little nudge. I don't need you to solve the whole problem for me, but I do need a little nudge. And that I think is very, very helpful advice. So thank you for that, Dave Ryan P also said, love this concept and it could be used with anyone.

Host - Pat Sweet: You lead ask questions before jumping to conclusions or communicating what should be done. There is power in helping others to learn how to learn. And I love that turn of phrase, helping, helping others to learn how to learn. And this is a good way to frame a manager as coach, right? When you adopt that coaching mindset, if you think to the world of sports, the coach, can't step on the court and, and shoot a basket on behalf of the team, you can't do that. That's against the rules. The problem in the corporate world is that often that's exactly what happens and you're not teaching your teams to learn. And I think this is, this is really Ryan's cutting to the heart of the matter here. So I really appreciated that. And finally, our friend Neil Thompson of teach the gate.com a good friend of the show added his 2 cents.

Host - Pat Sweet: He said, plus, who has time to solve all the problems? And he's right, no one has time to solve all the problems. And this is w we do this to ourselves as managers, we overload ourselves. And then we walk around complaining about how much work we have. Well, we have entire teams who we could be working with that we are not flowing work down to that we are taking their problems and making them our problems. We, we really it's, it's a self-inflicted wound in many cases. So Neil has always cutting to the heart of matter. Finally there was one more comment left by Haley young Anderson on the on the previous episode, episode 40 on meetings. And she said, I really liked this episode, pat sweet, such great and specific tips. I definitely let slip the practice of having a parking lot for ideas or topics that take meeting off track.

Host - Pat Sweet: So it was a very helpful reminder. I even used it in one of my calls yesterday and added a new section for items that may require a separate discussion in my meeting minutes. Thanks for another great episode. So thank you very much, Hailey, that I really appreciate the feedback. And I love hearing when people were able to take ideas from the show and apply it at work the next day that's, that's awesome. And that's ultimately what I'm striving for. So really, really great feedback. And I will take this opportunity to mention that Haley and her husband, Jordan, co-host an awesome podcast themselves called career engineering. So both Haley and Jordan are engineers, but they went and got further education in organizational behavior at the London school of economics. If I'm remembering correctly really, really interesting blend of organizational stuff and technical stuff and, and very punchy, very direct, really actionable content. So I'll have a link to that in the show notes as well. Thank you very much, Hailey. I am telling you dear listeners right now, I will be having Hailey or Jordan or both at some point on the podcast. Very excited to work with them. So stay tuned for that.

Host - Pat Sweet: Thanks again, to all those who reached out. If you'd like to chat or leave a comment, please do find me on LinkedIn Twitter, or leave a comment in the episode, show notes.

Host - Pat Sweet: That's all the time we have for the show today. I will be back soon with our next episode. If you enjoyed the show, please hit the subscribe button and please leave an honest review to let me know what you thought of today's episode. Don't forget that upcoming webinar probably within the next 24 hours. So very short fuse on this inbox, detox, October 26th, you can sign up@engineeringandleadership.com slash inbox, detox webinar for more information and links to the resources mentioned today. Just go to the show notes@engineeringandleadership.com slash episode 41 until next time, this is pat sweet reminding you that if you're going to be anything, be excellent.

Host - Pat Sweet: You've been listening to the engineering and leadership podcast with pat sweet. If you'd like to learn more, go to engineering and leadership.com where you'll find more free articles, podcasts, and downloads to help engineers thrive. That's engineering and leadership.com.