Make Mistakes Matter: Turning Setbacks into Growth with Michael Ehlers

Patrick Emmons: Hello, fellow innovators. This is Patrick Emmons. Shelli Nelson: And this is Shelli Nelson. Patrick Emmons: Welcome to the Innovation and Digital Enterprise Podcast, where we interview successful visionaries and leaders and give you insight into how they drive and support innovation within their organizations. Hello, everyone. I'm excited to introduce Mike Ehlers, who recently assumed the role of Chief Technology Officer at PlanSource. PlanSource is a leading benefits administration tech provider, and Mike is leading the charge to evolve its technology portfolio while engaging AI-powered experiences. In fact, Mike said he's excited to join the team at PlanSource, working to transform the benefits administration industry. So you know he's all about driving digital transformation in this space. Mike brings a wealth of experience: over 30 years in computer engineering and about 20 years in the benefits and HR tech industry. He's held leadership roles at companies like Voya Financial, Benefitfocus, Paylocity, Hewitt - AKA Alight - and even Xerox's HR outsourcing arm. So he's seen just about every angle of tech in the HR and benefits world. Throughout his career, Mike built a track record of delivering innovative, scalable solutions that enhance user experiences and cut costs. For example, at Benefitfocus, he oversaw the development of a SaaS-based benefits platform, and at Paylocity, he led product and tech initiatives, like launching a site reliability engineering function - all of which speak to his focus on robust, modern platforms. What really stands out is Mike's leadership philosophy. He prides himself on impact, integrity, transparency, and teamwork, fostering a culture of innovation and excellence on his teams. If you follow his posts on LinkedIn, you'll notice he's passionate about how technology, especially AI, can simplify complex HR processes and empower people. He even wrote recently about using generative AI to automate repetitive HR tasks and create better employee experiences. We're going to hear some great insights from him today. Mike, it's great to have you on the show. We look forward to learning from your leadership journey and hearing about your plans to drive innovation at PlanSource. Michael Ehlers: Hey, thanks for having me. You make me sound awfully impressive, so thank you. Patrick Emmons: That's my job. I get paid extra for that. If I didn't make it exciting, nobody would want to be on. Shelli Nelson: Mike, and if you don't mind starting out, can you share a little bit more with our listeners about your new role? Michael Ehlers: Yeah. So, I was fortunate enough to get the role as Chief Technology Officer at PlanSource. PlanSource is a software-as-a-service in the benefits administration space. And so what that really means is, if you work for a larger company, your company is most likely offering benefits to you. And typically, they would work with someone like us to provide a way for you to enroll in your benefits, make sure you're taking advantage of what's being offered to you, and then staff a call center if you have any questions to call in. Companies have been around since the early 2000s, and again, we're pretty excited. We think we're going to dominate the space. Patrick Emmons: It is a very interesting space. And your background - places like Hewitt here in Chicago are, I mean, they're just well known. My entire career, right? I think maybe that's a generation thing for like you and I, of like, it was a great destination for people coming out of college. They had a great culture. Free lunches, right? All1 of those great benefits. One of the things we touched on earlier in a conversation - and I thought this was really an interesting concept - failure as a forcing function. You said some of your toughest stretches ended up being your biggest growth moments. Do you want to dive into what some of those moments were that helped really either elevate or accelerate your career? Michael Ehlers: Yeah. So first, Hewitt - wonderful company - was a great place to kind of cut my teeth when I was just entering this industry. And to give you a sense, I joined there as a software engineer. And the funny story is that I was coming off of a startup company that had failed. My development was being done in C++. And here's this company, Hewitt Associates, looking for Java developers. So I actually taught myself Java over the course of a weekend in order to kind of bluff my way through the interview and actually landed the job. And it was one of those kind of career-defining moments because I pretty much have spent the next 25 years in and around this space, and it's been wonderful. At Hewitt, one of the tasks I took on there was they had a digital experience called YBR - Your Benefit Resource. And we had a version out there, they called it YBR 4, and I was asked to lead a lot of the architecture and development for the new version, YBR 5. We kind of got into that project, and again, we ended up doing it like a whole new system kind of alongside the other one. While the end result was I think incredibly successful - you know, last I heard that they had finally retired the last of my code like 15 years after I wrote it, which is pretty good longevity for someone who wrote code - the project was an abysmal failure in many ways. We were a year behind schedule, we were a million dollars over budget, and overall, I don't think anyone was really happy until the final result came out. I kind of learned an awful lot kind of going through that. I mean, number one, one thing I learned - and I will never, I will never forget - is, man, I do not like having to rewrite systems. I would much rather kind of upgrade and modernize in place instead of starting over. There are so many good reasons for that. Number one, it's always more complex than you think. You have to end up splitting your capacity to kind of support the old one and work on the new one. Your stakeholders are not happy because they're not getting features on the old one fast enough, so they want the new one, but the new one isn't ready yet. And it's kind of like shooting at a moving target because the old one is going to continue to be invested in, at least from a security and a compliance perspective, not less new features, because you gotta keep selling, right? And so I would never do that again. The other thing I would say is it just taught you a lot about how to work together as a team through adversity, right? Just making sure you're being very transparent about the challenges you're facing and where you're going. Some of the roughest patches we faced was when we were telling people things were going fine and they actually weren't going fine, and then you end up getting yourself into more trouble. And so those are probably the two biggest lessons I walked away from. I mean, number one, I don't ever want to rewrite a system from scratch again. And then number two - an old leader of mine had a saying which was wonderful, it was: "Bad news doesn't get better with age." And I've taken that to heart. There's always a good way to deliver bad news, but ultimately, it never does any good to kind of hold on to it and wait on it. Patrick Emmons: A good friend of mine, Jim Vessal, who Shelli knows him very well too, he uses that same phrase, but he says, "Bad news is not like fine wine. It does not age well." Michael Ehlers: That's a good way to put it. Patrick Emmons: Yeah. But I think... So, obviously, you know, we all face challenges, right? Somebody leaves, there's a change of regime, customers stop buying things, there's the economy - all those. What are some of the behaviors that you've learned that like, when to take... I get, maybe I'm triggered on the word "failure" because I always see it as a learning opportunity. But maybe that's a good question then is, like, how do you convert that successfully? Because there are certain people that would take a failure and it could do some really good scar damage to them. Is there something that you do, you mentioned telling people the truth is a critical element. What are some of the other things that you do when those moments happen that you're like, "Hey, we can make this a positive." Michael Ehlers: Yeah. I think almost anything you go through, there's something to be learned from it, right? And so, a great example is - and I think I told you this was the best mistake I ever made - I ended up joining Xerox Services from Hewitt. So by the time I left Hewitt, I had been there 12 years. It was time for a change. And I really thought the change that I wanted was a big title. And so I ended up joining Xerox Services. They had acquired a company called ACS in benefits administration, and I joined as their VP of Front End Development. And I had what I thought I wanted. I had a really big organization, I had a really big title. And I knew within a couple of months there that it was just not a good fit. It was a company that was not growing. It was a company that there was a lot of chaos kind of going on. It had gone through a bunch of acquisitions and just the culture was difficult for the culture to come together. And you know, I really resisted the urge to kind of go back to Hewitt because I had been there, I had done that. And the next 10 months, I probably grew more in those 10 months than I think I've grown at any time since until now. And the reason is, is there were a number of things that were not engineering related that I had to learn, right? I had to learn how to foster a culture. I had to learn how to basically engage talent that had gotten disengaged. I had to learn to manage to an incredibly tight shrinking budget. And those are skills that frankly, you don't learn at a growing company. Those are skills that you learn when the times get tough. But the reality is that at some point in time, you're going to be in situations where the time is tough. And while it was a really tough year that I was there, the fact that I walked away learning transparent communication through some really difficult times, and learning how to understand like what it takes to engage an individual because that's a very individual conversation, and frankly, learning how to really manage to a tight budget - those are skills I have taken on to every single position since. Like, I don't do Java development too much anymore, but there's not a week that goes by where I'm not having a transparent conversation or I'm not having a career conversation with one of my colleagues or trying to figure out how we're going to deal with some budgetary situation. I mean, those have been critical skills that have helped me get the roles I've had since. Shelli Nelson: I think that's really interesting that you stuck it out, right? And it makes me curious, did that change how you've mentored people over the years? Michael Ehlers: Yeah, it's a wonderful question. And there's a number of people, both at my current company but also pretty much every company I've had from Paylocity, Benefitfocus, back to Hewitt that I still have relationships with and still provide mentoring for. And I think it all starts with listening, right? I mean, you have to understand like what they're trying to get out of that, what problems they're facing, what are they struggling with, what's frustrating them. And what I often find is through listening, you can then figure out like where to take the conversation and you can figure out how your life lessons can help them understand maybe what to kind of do going forward. A good example is I was talking to a junior engineer this past week, and they got into this trap of worrying about what I call "what-about-ism," where they were seeing someone, one of their peers, that they thought was getting preferential treatment, right? They said, "Well, they get to leave early and they get to do X and they get to do Y." And the conversation went, "Yeah, but you actually don't know what conversations are happening behind the scenes. And whatever is happening there, you're kind of losing focus on what you want to do. So where do you want to take your career? And let's talk about the things that you need to develop to get there." Because I think the one thing I've learned is a career is not a straight line, right? Very seldom is it a straight line for people. A lot of times you have to get like this diverse set of experiences in order to get the role that you have. I mean, as a CTO, yes, I have to be... I have to understand engineering, but I also have to understand how to talk to clients when they're not happy at times. And I have to understand how to talk to executives, and I have to learn how to manage a budget, and I have to learn how to do security and infrastructure. And you don't get all of that from one position. And so it's that diversity of roles that you get that lead you to where you want to get to. Patrick Emmons: You know, when you made that comment about your career progression is not a straight line, I'm like... It is if it's a flat line! Right? Like if you don't want to grow, you can make it real flat. It'll be real straight. But it's not going to be a lot of fun. You're not going to really learn anything, so... Michael Ehlers: Yeah. It's totally true. And sometimes you need to take a step backwards. I mean, a great example was when I was leaving Xerox - I had mentioned I was the Head of Front End Development there - I was offered a role at Paylocity. At that point in time, Paylocity was pre-IPO, probably a hundred million in revenue. And the selling point that the CTO there gave me was, "Well, you can come here, but you're not going to be a VP and you're not going to have 120 people reporting to you. It's probably going to be pretty hands-on. You sure you want to do that?" And I got a sense of the culture there and what they were trying to do, and I was blown away. I went from a VP of Front End Development, I was a... I was basically an Engineering Manager. And I was an Engineering Manager with no team because I had to go hire the team. And it was probably still the best career decision I ever made because eight years later, I helped this company from IPO go from a hundred million in revenue to close to a billion dollars in revenue. And I grew my career tremendously through that and learned an awful lot. But I only did that because I was willing to take that big step back. Patrick Emmons: Curious... I have this concept of role players, right? You should always be recruiting role players. Like people who will... unless you're Michael Jordan, right, everybody's a role player at the next stage of their career, right? There's guys who get into the NHL not because they're not great, talented offensive players, but they're going to fight. And that's how they're going to get to the next level. Right? Dennis Rodman is a perfect example of like, hey, when he was shooting, he could shoot, he could score, he could do all those things. But what got him to the next level was his willingness to be a role player, fill the gap. Is that... does that fit with what you're saying? That idea of like, "Hey, I want to be on a great team. I want to get my career... I'm not going to worry about the title or the ego or things like that." Michael Ehlers: Yeah, 100%. Right. So an old leader of mine, Andrew Friend, who was the CEO at Benefitfocus, he had a saying - and he got it from someplace else - "Culture eats strategy for breakfast," right? And so everything kind of starts with culture. But even more than that, everything starts with talent. You can talk about AI, you can talk about having the best technical strategy, you can talk about the cloud, but you need the right talent to enable all of those things to happen. And if you have all those things, good things are going to happen. And so, when it comes to hiring, I hire athletes. Period. Full stop. I mean, I look for the best athletes. And what I mean by that is I don't spend a lot of time assessing specific technical skills. I assume they'll learn those things because the technology is ever-evolving. There's really three things that I assess on. One is I'm looking for people that have a lot of grit. Two, I'm looking for people that are highly curious. And three, I'm looking for good team players. Because the reality is I might hire someone as a front-end engineer, but I might end up needing over time someone in DevOps. And I want someone that really wants to dig in, solve problems, learn stuff, and is willing to do whatever the team needs to be successful. And I think if you have people like that, they're going to figure the right things out and your company is going to be successful because of it. Patrick Emmons: Well, you brought up culture, and so part of the reason why you chose to move to PlanSource is because the culture really resonated with you. You tell us a little bit more about that? Michael Ehlers: Yeah. There's a few things that I look for at almost every company that I go to. One is, is do you have an executive team that is really on the same page with where they want to take the company? Because nothing stunts your growth more than people not knowing where they want to go. The second thing is, is I'm a huge, huge, huge believer in transparency. You know, transparency from the CEO on how you're doing, all the way down to the lowest level of person. I think you want adults that can be told the truth about where things are at and where we need to go. And I think the only way you're going to do that is with curiosity. And that's being real clear with like individual feedback, that's being real clear with how the company is doing and what we need to be focusing on. But that transparency is what I'm looking for. And then I look for a place that, where especially in this benefits administration space, where people are incredibly passionate about serving a customer. Because again, I think the closer you get your folks to that customer, the more empathy you have, the more you understand the problems they need to solve. And then lastly, I want a place where you can have fun. I mean, we all spend a large portion of our lives at work, and you want to do it with people you enjoy. But ultimately, is the leadership team aligned? Do you have a highly transparent culture? Are you passionate about serving your customers? And dammit, let's have a little bit of fun. Patrick Emmons: I like to tell the kids I coach, "Let's have some fun. If fun means winning." Right? Like, if you find winning fun, this will be a great team. I'm just kind of kidding. Michael Ehlers: I'm with you. I think you have the right... I mean, we're going to dominate, so the things that I mentioned are going to let us dominate this industry. Patrick Emmons: I love it. I love it. There's a kid I grew up with and they dominate was like his phrase whenever we went to the YMCA. He's like, "We're going to dominate." I was like, "I don't know about that, Sean. I'm looking over at those other guys, I don't think we're going to dominate. We might be good, so..." Well, how do you... right, you mentioned grit and the culture and the people. You know, pull back the curtain... let us see, what do you do? How do you figure that out? How do you assess that? Is there a part of the interview process? Is there something you coach your interviewers on? You know, what is it? How do you gauge those things? Like the grit, the willingness to do whatever it takes, that kind of stuff. Michael Ehlers: Yeah. I mean, there are certainly behavioral questions you can kind of ask. So like on the grit one, I always like to ask like, "Hey, what's a really difficult problem you had to solve and walk me through how you solved it?" And the thing you look for is what level of excruciating detail can they get into? That's what you kind of look for. Do they kind of gloss over it and do they kind of give you a like a real canned answer which is like, "Hey, we had a production incident and then we made a code change and then we resolved it." I mean, then you can tell that they weren't super into it. What you want is that person's like, "Man, like we were having like a problem, the application wasn't scaling..." and this is a true story... "and, man, the company couldn't afford to stand up a stressed test environment. And so we ended up coming in third shift and doing like load testing off hours. And what we found was when our sessions were being written out to the database, that was taking too long and so we had to do some stuff." That's actually a true story when I was at Hewitt. Like we were having problems scaling out YBR 5x and our back end was an IBM zOS mainframe and we couldn't afford more capacity for a stress test environment. And so a few of us actually worked third shift to performance test it over a course of like six weeks. And so you want people that really, they show they were passionate and they really can go into excruciating detail about the problems they solved. And curiosity, I mean, I think what you're looking for is when you look at someone's, start with their resume and ask them questions, is it, "Hey, were they passionate about a specific technical skill they were focused on? Like, 'Hey, I'm really good at React and I really want to focus on React.'" Or do they talk about how they maybe like jumped... "Hey, I tried this technology over here," or "Hey, the company really needed me to solve a database problem so I had to teach myself SQL." You just again, you're just kind of looking to see is it someone that kind of runs to the problem... The way I always look at it is, do you want the person that's running from the fire or the person who is running to the fire? And you try to find the person who is running to the fire. And then the last thing around teamwork, again, you try to ask probing questions about how they work as a team, and you try to see are they using "I" words a lot or using "we" words a lot? And you want to know what the person did, so you are looking for some "I" words, but you also want to see, especially in times when they're talking about something successful, are they using a "we" word? And if they're talking about a failure, are they using an "I" word? Those are the things I start to look for. Patrick Emmons: And so on the fire question, right? To go back to that real quick... people who run from the fire, people who run to the fire. And then there's the ones that like to start the fires so that they can run to the fire. How do you figure out which one of those are the psychos that you really like... they're not, they're not solution focused, they're problem focused is what I call it. They like to solve the problems, but not permanently, right? They get to continue to have their heroics of like, "Oh, I saved the day again from the disaster I created." Have you seen that? Have you... you know what I'm talking about with those types of folks? Michael Ehlers: Yeah. I've seen that a bit. I think the thing that I see more are the people that like to lob their grenades or after the fact say, "Yeah, I knew that was going to be a fire," but their vision and hindsight is awesome. On the people who like to be the superheroes, you know, the things I typically do is I am super passionate, I'm probably more passionate about this than anything else, is the idea of a really good post-mortem. Like a blameless post-mortem where after a problem, like you get people into a room and they're super hard on the problem, and a set of action items that come out of that are what we then go execute on. And I think what you look for is people who, as they talk through a problem, you kind of ask like at the end like, "Hey, so like what did you learn and what did you do from that?" And people that, like you mentioned, that are very tactical, they're those firefighters, they really enjoy being in the chaos... typically their answers get very superficial about like what they did after the fact. And the people, and what you're looking for is the person that says, "Yeah, I basically brought down production and I am never letting that happen again. And here's how I'm making sure it doesn't happen again," and they can go into a lot of detail on that part of it. That's what you're looking for. You're looking for the person that can acknowledge they kind of made a mistake and they really talk about like what they've done to ensure that mistake never happens again. Patrick Emmons: The eyes. Right? You want "I should do this," "I dropped the ball," "I'll get better." Michael Ehlers: Yep. Shelli Nelson: One of the things on one of our trips with Project Relo - and retros are such a common occurrence in software engineering - but like one of the things Christian and some of those guys focused on were "After Action." Patrick Emmons: I was just thinking the same thing. Yes. Shelli Nelson: Yeah. So is that something like, is there stuff that you're seeing where like on your teams anybody's doing that kind of thing on the After Actions? Michael Ehlers: Totally for sure. So I look at it as that for every incident we have, you know, there's an immediate thing which is, when I think of After Action, how did we handle the incident? Did our monitors catch the incident? Did our runbooks [stay] up to date on how to handle the incident? Did we communicate like effectively during the incident and frequent enough during the incident? And then we go ahead and say, like, what are the things that we're going to do to kind of get better? I mean, do we need to enhance our monitoring to catch the thing? Do we need to enhance our communication playbooks so we communicate more effectively? Did we miss a page in our runbook so we were trying to figure things out on the fly? That's like the immediate thing. The next thing again is, is like again, how the prevention, like what is the thing we're going to do to prevent this incident? And again, you know, some of the things that we're doing there is we are mandating for every incident we do a post-mortem. And tying it back to AI, I actually created an agent like just this last week with some of the Microsoft tooling that actually now walks people through a "five whys" conversation and helps produce a great like post-mortem document from that. But one thing that I find is a lot of organizations, and mine included, post-mortems... because everybody wants to get back to their day job, right? The engineer doesn't want to like focus on the post-mortem, they want to get back to focusing on whatever stories they had on their board before they left. And so how do you make it sure that they understand it's a priority? And so one of the things that we did is we actually had - this at Benefitfocus first - we actually started having like monthly awards for the best post-mortem. And we actually would celebrate failure. So we would actually say, "Hey, listen, we had an incident, but look at this great post-mortem that we happened, that we wrote." And then we'd have like awards for people who wrote the best post-mortem, just as a way to like kind of gamify and encourage people to really spend time on this that it was really important to us as a leadership team. Patrick Emmons: That's very cool. That's very cool. I have a question because one of the biggest challenges I see with the post-mortems, the retros, the After Actions is a lot of great stuff is surfaced, there's a lot of great conversation, great accountability. Also, I think that's where teams are really starting to form when somebody has the humility to take ownership and everybody goes, "Oh, you're different, you're a different group of people," when that kind of humility comes up. Tactically, there's so much value that's generated from that... that dies in that room, right? Like how does that... you know, if you get to the Kaizen kind of approach of like how do we take that back and actually permanently incorporate that. Is there something you're doing that you coach your teams on to do that? Michael Ehlers: Yeah, so we put a system in place to make sure that doesn't happen. And so, so the output from a post-mortem is kind of two things. The first thing is that post-mortem document, and we produce an internal one which has a lot of technical details, and then we produce a client-facing one that can be shared with our partners and our clients, right? And my dream big there is I actually want to get to a place where we actually have a PlanSource engineering blog and we'll post our post-mortems there because we want to share with the world like what we've learned from our incidents. The second thing is, is there's always a set of action items. And for those, what we do is we actually put right into our, into our ticket tracking system, in our case Jira, and we tag them as basically "after action items." And we actually have SLAs around closure. And I actually have a Program Manager that manages our post-mortem program, and I get a report on a weekly basis on any action items that are outside of SLA. Typically we want all action items, or any high priority action items, closed within a couple of weeks after the incident. And I just make sure everyone knows it's my priority. I report to the organization on how we're doing on those, but ultimately I have someone whose job is to make sure that those things don't die in that room. Patrick Emmons: So for all our listeners out there, I want to make real clear: if you are focused on getting your team to a higher level of performance and you don't want to do a ton of work to do that, do what he just said! Right? Like, it's a self-improving system of getting that feedback to the people in a non-confrontational way. And I'm sure that's part of how you create that culture of constant learning because you're normalizing it. Nobody's perfect. We're all flawed individuals. The processes... right? Like Deming would say, right? Like 83, 85% of the time it's the process, not the people, right? And like if you're not working on improving the process, the people can't succeed. Michael Ehlers: 100%, right. It's very process oriented in that we don't say this person failed, it's more here's kind of where the system broke down and here's how we're going to enhance the system. But here's what I say on post-mortem: if you as a leader show the organization it's a priority of you, it's going to be a priority for them. And so it's easy as a leader to join that room during kind of the incident to help put out the fire. But if you show them it's a priority for you after that fact to kind of make sure that all the things you learned get institutionalized, it's going to be important to the organization. And I don't think there's anything more important than kind of building that problem management culture. Again, it's something that I'm incredibly passionate about. Shelli Nelson: Awesome. Well, and I was going to ask you, Mike, this seems like a big cultural shift, right? If it's not already part of the culture. So for our listeners who maybe work for smaller organizations, maybe they don't have the technology, the resources, right, to track all this. How do you think someone can start small and again, try to get toward that cultural shift where everybody's using it? Michael Ehlers: Yeah. I don't think it's a big investment. Like I said, in our... and we're a smaller company again, so you know, our... the total size of PlanSource as far as number of employees is about 440 people. So it's not a huge company. And if you think of what we've done is, is it's really all we have dedicated to this is about a quarter of an FTE to kind of manage that program. So it's not a huge investment. It's putting the system in place, and then it's letting automation kind of support it. So again, we identify an action item, you open a ticket, you kind of tag it with a label that says it's an after action item. And then you basically create a report which says, if it's run on a weekly basis, to say, "Hey, which of these items are either coming up to due or are past due?" And if it's past due, you go to the leader of that area and say, "Hey, listen, this item was found in this incident. I mean, we were hard down a couple weeks ago. This was identified. Like, this isn't closed, what's going on?" You do that once or twice, those leaders now know like what's expected of them and it doesn't happen again. And so I don't think it's a big investment. I also think you can... a very similar thing can happen, almost every organization is doing some form of a Scrum type ceremonies. Well, at the end of the Scrum, there is the retrospective. And a very similar thing happens. I think that retrospectives... they start... very early on they take it seriously, and towards the end it kind of becomes like a check the box thing where they kind of do the retrospective, but like to Patrick's point, the items that come out kind of die on the vine. You can do a very similar strategy. And I think Spotify coined this where you take your action items, you put them kind of in a shared place and you tag some things which are like internal, so these are things that's under the team's control, and then there's things that are tagged as external, which are things not in the team's control that they need help with, such as like a... the stability of a test environment. And then again, the same thing is you have a Program Manager track those to completion. And I think, I think just in human nature, if people see that these things get put out there and nothing happens, they're not going to think it's a priority and they're going to gloss over it. If people see that when they put something there it's taken seriously, they're going to take it seriously. Patrick Emmons: Yeah, Shelli, I'd say the biggest investment that's required is leadership's openness and transparency. Willingness to be open... I don't want to use the word self-criticism, but it's kind of that of like, hey, I'm more worried about getting... somebody else, I forget who it said it, but I think this is kind of a good phrase to put in here is like, "I want to get it right, not be right." And when we're focused on being right, we defend the status, and when we want to get it right, we have a more open mindset to like, "Hey, I'm imperfect." And that... and you do see that. Unfortunately, Mike, you know, there's quite a few people who are at higher levels that they'd rather sweep it under the rug. Right? We're not going to talk about our blemishes, we're not going to talk about our imperfections. We're going to tell the story upwards: we're perfect, we are without fail, we are flawless. And that is the root of all evil. Right? And it is stasis that will lead you... continue to get worse because to your point of it, it's the big lie, right? The big lie is we don't have anything to work on. And then that big lie requires everybody to lie to each other. And then lying instead of transparency becomes your culture. Michael Ehlers: Yeah, that's good. An old leader of mine, Ted Gaty, who was our CTO at Paylocity, used to have a saying which was... Patrick Emmons: If stuff's not breaking, he wouldn't say stuff, he would say a different word. Michael Ehlers: What word would that be? Patrick Emmons: If it ain't breaking, we're not moving fast enough. And so we wouldn't measure things based upon like not breaking something. We would measure things on not having the same thing break twice. That's kind of how you measured success. And that's what we kind of carried forward. Like I want my teams to really move fast, right? I mean, and we want to create the right environment and give them the right set of guardrails so they could pin their ears back and go as fast as they want to go. But part of that also is that when you do hit a rock, when you hit a bump in the road, like you need to take stock in what happened and you need to learn from it so you don't hit the same thing again. Patrick Emmons: It's, you know, when you working for smaller, faster growing companies, when you realize it's great to get those mistakes out early because they hurt less. Right? Like if we can improve the process when we're only this small, what a blessing. Because when we scale and we get bigger, these are going to be gaping wounds that are going to take a lot longer to fix. So it's like, hey, embrace that now because the problem if you're growing is only going to be bigger. Right? So like embrace, you know, move fast, test your theories, bang around, make a mess. And then like, because especially when you're smaller or smaller, right, as you've been with other organizations like, you hit it when it's small, it's like, well that's a $50,000 mistake. In five years, that's going to be a $500,000 mistake. Right? So let's pay those things down today. Michael Ehlers: 100%. I'll also say that I think one of the keys to success for bigger companies is trying to keep some of that small company mentality. Right? Because how many times have we seen a company that got really big and because they were afraid of failure, they might now only deploy software to production like twice a year because they want to like put it through like man-years worth of regression testing. And that way, yes, they are avoiding risk, but man, they're moving at glacial pace. But bigger companies that can find a way to still innovate and fail cheaply or fail fast, like "Hey, I'm going to deploy this thing, but I'm only going to deploy to 10% of my client base so if it doesn't work, it's not a $500,000 error, it's only a $50,000 error." Those big companies that still get to act small, I think those are the ones that are more successful. Patrick Emmons: You mean like a mobile phone company that didn't want to make a digital handset... and then... You know the interesting part, so for the listeners, Mike and I both worked at Motorola earlier on in our careers. Just quick side story is like when I was there, you'd get the readouts about like who we're winning against, who we're not winning against. And when I was there, obviously Nokia was like the big enemy, right? And every month we'd get like an understanding of how we're dominating... dominating the market against Nokia. I left... I was there for Micro... the MicroTAC? MicroTAC. Yeah. And then for Razr. So Razr was just killing it. Nokia didn't really make good inroads. But the funny part of that story, and I think it's important to your point Mike is that like, there was a dark horse in this conversation that people never talked about. And the two... there's one that wasn't on there, that iPhone was not a thing, right? So that wasn't even in the discussion. Number three who everybody I talked to at Motorola was sure was never really going to be good at making cell phones was Samsung. So to your point of like, can you stay nimble, can you stay adaptive, can you respond to what the customer wants? Not what you want to sell, not what you're good at building, but what the customer really wants. Obviously Samsung and Apple took that away from Nokia and Motorola pretty... I mean, what a massive shift in a very small time from like 2005 to 2008. Michael Ehlers: I mean, it is a crazy read to go read Motorola's story. I mean, again, I was there in the mid-nineties and it was one of the shining like American companies. Everything from cellular phones to infrastructure-based wireless communication systems... Patrick Emmons: Semiconductors, servers, name it, right. Michael Ehlers: It was an incredible thing. And it's a company that lost its vision and fell behind and was never able to catch up. It's actually, it's a pretty interesting read. Patrick Emmons: Yeah. But to your point, it's like... and I think this is one of the other concepts that you bring up a lot, and being close to the customer, right? Motorola was very proud of their security. And so was BlackBerry. Like BlackBerry Server, like "we're the most secure platform." And that was part of like Motorola. The problem is the customer didn't care. Right? And so you've said before, like proximity to that customer beats, you know, the elegance of the solution. So I'd love to like expand on that for the listeners. Michael Ehlers: Yeah. I mean, the basic premise is the more valuable the innovation, it's based upon the level of empathy you have for your end user. So, you know, I always like tongue-in-cheek to talk about those Ivory Tower... so a lot of companies, they'll have those Ivory Tower technologists who they don't want to talk to the customer, they don't want to look into what the customer is doing, they want to stay abreast of what's happening as far as trends in technology. And then they'll do some really cool innovative thing and they'll show the world and it has zero applicability to the business, right? I just think that's the wrong way to do it. I think the right way to do it is, how do you get your engineers and your technologists as close to the customer as you can so they have empathy so they really understand that customer's pain points? Because if they understand that customer's pain point and have empathy for them, now they're in a position to innovate and solutions for them. And there are lots of ways to do this. One of the more elegant ways and inexpensive ways, and we did this at Benefitfocus was on a monthly basis like everyone in technology spent an hour just listening to customer calls. So at the call center, we would record calls, and then once a month everybody'd be invited just to kind of listen to what customers were calling in about. What pain points are they having? What are they frustrated by? And that was one way of doing it. Another way, when I was at Paylocity, we would send out all of our engineering directors to do ride-alongs with sales just to hear why we were winning and why we were losing. And the whole, but the whole premise is very simple. The whole premise is the best software is kind of built in tandem with your customers. And so the closer you can get to them, the more empathy you can build, the better position you are to create innovative solutions that meet their needs. Shelli Nelson: I love those ideas. Patrick Emmons: Yeah, one thought... somebody smarter than me said, "If your customer isn't part of your design team, you're really not doing it right." You know? Like we spend all this time trying to come up with the most amazing thing and not engaging the person who's the most important person. So. Shelli Nelson: Totally agree. Sorry, Shelli, I interrupted you. No, no, Mike. I just wanted to ask, is there a customer conversation you had that maybe even changed a roadmap decision? Michael Ehlers: Yeah. I mean, so this is a really small one. So I was early in my tenure at Paylocity. And they used to do this client conference... I can't remember what it's called now... but we had a client conference. And I was at this client conference. And remember Paylocity's clients were smaller to mid-sized businesses. I think the average employee size of the teams was about 50 employees. And I'm sitting there and I'm sitting there talking to clients and a very nice old lady came up to me and goes, "Why isn't your mobile app in Polish?" And I'm like, "What are you talking about?" Patrick Emmons: You said "mówimy po polsku?" Is that what you...? I'm sure I said it wrong. I just grew up on the Northwest side. Michael Ehlers: But I'm talking to her and she owned a pizza joint in Chicago. And all of her employees were Polish, didn't really speak English all that well. And they wanted to use the mobile application to basically request time off and things like that. And so she wanted it in Polish. And I don't remember... I'm pretty sure we ended up doing it in Polish, though I don't remember 100%. But that was very... that was very impactful because and the reason it was impactful was if you were looking at like pure metrics of what to do with your software for a product that's used across the country, like Polish wouldn't be in like the top five languages you'd probably do, right? You would do Spanish, you might do French, you obviously would do English. I'm not sure you would go much deeper than that, especially for software only sold in the United States. But it really struck me that in this case, for her, doing it in Polish would have been incredibly impactful. Another really good example was, you know, as a payroll company we were rolling out Multi-Factor Authentication. So this is the idea of a username and password isn't enough, you also want to get a like a phone call or a text message with a one-time code you can use. And we're rolling this out and I get a call from someone who owned an auto body shop who basically was irate because they couldn't use our system anymore. And what it came down to was, you know, they used our software to like punch in and punch out from their computers or phones. And by forcing Multi-Factor Authentication, their users could no longer log in because we didn't allow them to have personal cell phones at their computers. Their phone systems, they couldn't get calls on because there were, what do they call them, lines you had to, like numbers you had to dial to hit a particular line. And so they could no longer log in. And so again, looking at it from a pure numbers perspective, you never would have seen that. You would never think, you know, in circa call it 2020, 2018, that people wouldn't have access to a cell phone, right? You would just wouldn't think that. And all of a sudden, I was talking to whole companies where their users would like, they could not use their cell phone throughout the day when they were using our software. Shelli Nelson: Those are great examples. Thank you. Michael Ehlers: Yeah, for sure. Patrick Emmons: Awesome. Well, thank you, Mike. Thanks for taking the time to share your wisdom and your experience with our audience. Michael Ehlers: I enjoyed it. Thanks for having me. Patrick Emmons: So we also want to thank our listeners. We appreciate everyone joining us today. Shelli Nelson: 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 Emmons: This episode was sponsored by Improving and produced by Dante32.