In this episode, Patrick and Shelli welcome Michael Pozzi, a tech leader with an expansive career across engineering, computer science, and finance. Currently, Michael is Senior Vice President of Technology Infrastructure at Ryan Specialty.
We discuss Michael's leadership style, a philosophy characterized by humility and a team-centric approach. He shares his experiences of leading through uncertain times at the Chicago Mercantile Exchange, and highlights the ways he builds teams to foster empathy and collaboration. We chat about the evolving landscape of technology infrastructure, data volume, AI automation, and the dynamics of remote teams. Michael advocates for recognizing and nurturing talent within an organization, fostering an environment where employees can thrive and grow in alignment with their org’s mission.
- (00:00) Welcome Michael Pozzi
- (00:25) Michael’s Career Journey
- (02:26) Role at Ryan Specialty
- (03:07) Early Career and Pivot to Consulting
- (05:01) Joining the Chicago Mercantile Exchange
- (08:50) Transition to Infrastructure and Operations
- (12:51) Leadership and Team Dynamics
- (21:47) Recognizing the Need for Fresh Perspectives
- (24:05) The Importance of Empathy in Team Dynamics
- (29:06) Career Growth and Organizational Support
- (34:48) Encouraging Internal Mobility and Learning
- (40:10) Final Thoughts
About Our Guest
Michael Pozzi is Senior Vice President of Technology Infrastructure at Ryan Specialty. Previously, over nearly 20 years, he held a series of director level positions at the CME Group, like Managing Director of Infrastructure & Operations, Executive Director of Systems Engineering, and Executive Director of Software Engineering. Before that he worked at Hewitt Associates and Accenture. He earned a Bachelors degree in Mechanical Engineering from Duke and Masters in Computer Science from DePaul.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, 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. Today we have Michael Pozzi, a technology leader who has built a remarkable career at the intersection of finance and infrastructure. Michael is the Senior Vice President of Technology Infrastructure at Ryan Specialty where he oversees the backbone of a global specialty insurance firm's IT operations. His background is anything but typical. He started out in mechanical engineering and computer science, and he spent years honing his craft at the Chicago Mercantile Exchange in high-stakes financial markets. Along the way, he's helped keep critical trading systems running 24/7 and even led the integration of major platforms during pivotal moments in the industry. In other words, Michael has been at the forefront of tech infrastructure and some of the most regulated data-driven environments around.
What really sets Michael apart is his leadership style and philosophy. He's known as a humble leader who always credits and celebrates the talent on his team. Ask anyone who's worked for him, they'll tell you he's the first to shine the spotlight on others. In fact, a former colleague noted Michael's uncanny ability to grasp complex scenarios in minimal time, a skill that served him well as he navigated massive career pivots. One such pivot came at CME where he stepped up to lead through major uncertainty and change. Michael isn't afraid to step into the void when a challenge has no obvious owner. He leans in and takes charge even when that path forward isn't clear. Today we'll dive into how he makes tough decisions under uncertainty, how he balances risk and innovation in regulated industries, and what he sees on the horizon for the future of infrastructure. Think data volume explosions, AI automation, distributed teams, and more.
Get ready for a conversation that's equal parts insightful and inspiring with a little bit of humor and storytelling along the way, we might even touch on movie Christmas Story. Michael Pozzi's journey shows that even in the world of giant exchanges and insurance giants, innovation and humility can go hand in hand.
Shelli: Welcome to the show, Michael.
Michael: Thank you very much. Very excited to be here today.
Shelli: Awesome. If you don't mind, can you share a little bit more with our listeners about your role at Ryan Specialty?
Michael: Yes. As Patrick noted at Ryan Specialty, I'm responsible for our corporate infrastructure and operation. Our 24 by 7 operational support teams, our core infrastructure, our move to the Azure Cloud, and then really core responsibilities like IT service management, change management. A good way to think about it is the day-to-day execution and really being in a position where you're keeping the entire org on their feet. You want to be the utility that nobody else has to about because like flipping a switch and your lights come on, we're there to be steady support you every day so you can focus on growing the business and moving the business forward.
Patrick: Your career journey has taken you in a lot of different directions from studying mechanical engineering, like we mentioned in the introduction and computer science and into infrastructure and some very significant financial organizations. Can you walk us through that journey?
Michael: Sure. It's been interesting. It's been fun because it's really been a kind of a growth period over time, driven by where you see an opportunity where you jump into it. As you noted, my degree was in mechanical engineering, graduated before the turn of the century, which is scary to say, from Duke University with a degree in mechanical engineering and physics. And I learned pretty quickly that while I liked mechanical engineering in practice, well not in practice, I liked mechanical engineering in concepts, so studying material strength, studying forces, I did not like it in application. I was looking around, I was like, "I don't want to work for Caterpillar, I don't want to work for a car manufacturer. I don't want to build heavy machinery. It's either go academia or it's pivot and make a change."
And I'd done an internship with Accenture and I really liked the opportunity of consulting, especially coming right out of school because of that chance to be on a variety of different areas where you go into a project, you're on a project for a period of time, then you move to a new project, you move to a new project, so you're constantly learning and growing. The big mistake I probably made in doing that was that I landed with Accenture right out of school, did the usual two week bootcamp that they have and a project that was for a software solution called PeopleSoft popped up. They ran me through a one-week training cycle on PeopleSoft. And next thing I know is I'm an intro consultant out in the field helping with a PeopleSoft HR implementation.
And the reason I say the mistake of that was you go to school for four years, you get a degree, you think you're kind of setting a path and a focus. And in reality it was the randomness of scheduling that the next 10 years of my career were all driven by PeopleSoft and the recognition of that up to and including that's how I joined CME. I actually came to CME originally to help with their, I was a senior analyst in their PeopleSoft HR space and then kind of grew in that role to eventually run their PeopleSoft practice. But all of it was a kind of direct cascade out of a decision that a scheduler at Accenture had made my first two weeks on the job and was starting to come to a point where I was like, well, I mean it's fine. I like the people I worked with. The materials important. Your publicly traded company, you need to have a functional HR world. You need to have a strong financial backbone in order to be able to support while you're there.
But it was really starting to become frustrating because anytime you ran into any issues, you were looking at it and saying, how much of this did I choose? How much of this challenge did I choose to take on? And how much was this just kind put in front of me? And so I made a decision when I was at CME that I wanted to step away from focusing on core responsibilities of what a company has to live up to like HR and finance and more why the company exists. And so I threw my hat in the ring and ended up taking over the Globex is the name of the trading platform or trading environment really at CME and I took over their cross-functional QA space because that was why we existed as a company.
It was much more interesting to me to be involved in the core day-to-day of like why CME exists, how CME services the world, how CME makes money as opposed to how we make sure our employees are happy and how we make sure our reporting to the street on earnings is correct. So I was only in that role for about a year and a half or two years, but was learning a ton about Globex was really stepping into a deeper QA role on security testing, on performance testing, which ends up being a big real competency for CME when you think about high-frequency trading and their need to be able to really live up to the demands of the marketplace in that zone. And then we went through a reorganization and so I left the office on a Monday running cross-functional QA. I came back into the office on a Tuesday to be informed. I was now running our market reg software development teams.
And so that ended up being kind of the next two or three years of my career. I was there just shy of three years in the market reg space. And that was a much more interesting area, not totally dispersed from trading, but kind of on the back end as you think about the data flow in a global exchange of the data moving through Globex, moving into clearing, and then ultimately the regulatory responsibilities to report to the CFTC. And with CME being a self-regulated organization to monitor and make sure the marketplaces are fair, equal access for everybody. Critical role within the organization. And we spent a couple of years where you're starting to get into at this time, because this was about 10 years ago now you're starting to get into machine learning, large data set analysis.
We were an AWS shop at the time, so putting data up there, going through identifying if people are abusing the market, spoofing, where you're trying to pretend like you're going to buy and then you really quick switch to sell to see if you can move the market and get a fraction of a penny in your favor as a result of that change. And I did that for about three years, but I was starting to see that same kind challenge I had with PeopleSoft come up in that I had chosen to go for that cross-functional QA role. And then I had been told I was now going to run market reg. And again, I liked the team, I liked the people I worked with. I found the material to be interesting and intellectually stimulating, especially when you think about large data challenges. But it wasn't necessarily a challenge I had chosen for myself.
And one of the things that I've kind of experienced for myself as well as when I've unfortunately kind of run into a situation with folks that report to me is there's a big difference mentally between the challenges you choose versus the challenges that somebody forces upon you. And I was really finding that as those frustrations mount up, you're starting to hear a little bit in the back of your head, is this what I want to be doing? Is this where I want to be focused? And at the same time that was happening, we were going through a little bit of a growth pain at CME with, I think a lot of companies went through particularly about this time about 10 years ago, of just constant friction between the development teams and the infrastructure teams or the operations teams, I'll say more broadly.
And we were starting to make jokes about the fact that for my development team running a development team with market reg, we were trying to get new releases, new capabilities into production in spite of the infrastructure and the operations teams and the infrastructure and operations teams were protecting production from the development teams because the number one source of any issues or outage you're going to have in the environment is probably the code somebody just pushed in a day or two ago and they didn't catch it in testing, it wasn't well thought out, unintended consequences, etc. But at the end of the day, that becomes a self-defeating paradigm within the technology teams because you're then just fighting each other and the business is on the outside looking in being like, you're all one team to us, why can't you get along and why can't you figure out how to make this work?
And so I was talking to the head of operations at that time and we were talking about if we really wanted to make a change, we were doing a global leadership meeting and mentioned that we should rotate leadership. We should take some folks from development, move them into operations, take some folks from operations, move them into development if nothing else, to build empathy to get a little bit better perspective of the positioning and what are the challenges that development's facing on a daily basis? What are the challenges that operations are facing? And then you can bring a little different perspective to how do we solve those together?
And I will admit, I initially tossed that idea out with the idea that somebody for rotation could be somebody else, but then I realized in hindsight the mistake that when you put a suggestion out there like that and nobody else says anything, it's like the old joke of everybody's in a line and everybody else steps back and you're the last person that's there forward. It's like, well, if you're going to make a suggestion like that, you kind of have to be willing to back it up. I talked with the head of operations, he had been doing operations for six, seven years at that point, and operations is a tough gig you're on for all the P1s, you're dealing with all the frustrations. Most of the time you talk about operations, it's because something's going wrong and people really want you to fix what's going wrong right now as quickly as you can.
And he just needed a change of scenery. And so we agreed to swap roles. He took over the market reg development side. I jumped in on the operations, the infrastructure side, but again now it was a choice on my side. I had decided, hey, this was a challenge. I recognize the org needs it and I found for myself as well as I think for even the back of concept of career growth, putting yourself in whatever position is necessary that best supports the mission of the organization or where the organization has a clear need has always served me well. And that was where then I was able to run operations for about four years, and then when the head of infrastructure and operations retired, I was tapped to take over the broader I&O responsibilities for CME for the last two years that I was there. Again, it was a direct output of we saw the need, you mentioned stepping into the void. I hadn't run operations to that point. I'd been fully on an engineering and development background, but recognize that a lot of the concepts and the ideas remain the same.
Do you make good decisions? Do you communicate well with others? Do you synthesize information? Knowing that when you're doing an initial builder design, you never have all the details, you never have all of the requirements. When you're dealing with an issue, you work with the best you can with the information you have and realize that as much as it feels like it's a leap of faith, in reality 80 to 90% of your day-to-day is the same. It's just the decisions now about storage, servers, databases, network transports as opposed to decomposing stories on a Jira board, QA cycles, requirements gathering with the users. I did that for a couple of years. Like I said, I ran for about the last year and a half, two years at CME, was running their I&O shop and then decided it's time for me to kind of take a little bit different path and took a little time off before jumping over to similar role at Ryan Specialty. That was kind of the synopsis of how you end up with a degree in mechanical engineering in somehow someway end up running infrastructure and operations for the world's largest exchange.
Patrick: I'm curious about that position swap. I hear you. Good leadership, good communication, making long-term decisions, discipline. I always focus on fundamentals. There's fundamentals, you just got to get the fundamentals right and 90% of the problem solved. What was the biggest learning that you got out of that? Because as a guy who's a software guy, I have no problem with you taking over infrastructure. I think I'd be more nervous about infrastructure taking over software engineering, but that could be just my own baloney of a great book Team of Teams from General McChrystal talks about every other team sucks, and that mentality is something woven into us as humans of like, we're good, they're the ones who are problems. What was the biggest challenge that you had to overcome and then what was the biggest lesson learned, if you don't mind sharing?
Michael: Sure. I think the biggest challenge, and actually the switch originally from PeopleSoft into the Globex cross-functional testing teams was a smaller scale opportunity to go through that. But the biggest initial challenge on that kind of change or that kind of growth is adapting your mindset, and I think this hits a lot of people in technology, but adapting your mindset from the idea that you got to where you are, you progress because you were the best person in the room. If you grew up through a development team, the first person that became the senior developer was the strongest developer. The lead developer was the strongest of the seniors. The tech specialist was the strongest of the leads. You were directly evaluated on your individual capabilities and your individual contribution once you switched to another team, certainly going to the cross-functional QA from PeopleSoft, even more so going from development across to infrastructure, you were the least capable person in the room.
I was not a system administrator, I was not a DBA. And you had to embrace that and know that and you had to have the confidence to be comfortable with the fact that you were no longer in a position where, well, because I'm the best developer, I can just tell you this is how you're going to do it and I can know that I'm right and I can also know that you probably also agree that I'm right. The hierarchy is a crutch that people lean on and it's really easy to get caught up in that because that's how we recognize and promote talent a lot of the times. And when you switch roles, you're sitting around the table on your first day with everybody, they're all looking at you sideways probably because the person you replaced actually grew up counting on that hierarchy.
Maybe they were the best at sysadmin, maybe they had really established themselves as an exceptional DBA and that's how they grew to the role and they're looking at you and being like, "I don't even know that you understand anything of what we do." And it was acknowledging that it was the initial period with everybody where you were going through and having individual one-to-one conversations of like, "Look, I'm not an expert in this material. I'm going to need your support. I'm going to need your education." And it was showing that you would be balanced and taking the feedback from everybody and helping as a team to guide to the best decision. Now, that doesn't mean that you led 100% through consensus. Nobody can. But what it meant was that while you still retained the responsibility and the accountability for the decisions that get made, your job mainly was to put the team in the best position for them to be able to be successful and have impact.
My goal in that role was... Like I couldn't survive if I was trying to become the best sysadmin. My goal in that role was to put all of my sysadmins into a place where they were effective, safe, and protected. Because a lot of times you mentioned every other team sucks. Well, that usually means whoever I'm working for that team, how do I, it's a scapegoat, but effectively make sure that everybody knows that if we succeed, it's my success, if we fail, it's his failure type of a position. And so it was recognizing the need for almost more of a coach mindset as opposed to I'm the best person in this room. It's a top out that I've seen for a lot of people. I've seen a lot of people really struggle to take that step back from micromanaging people to take that step back from I got to this role because I was the best thus we as a collective unit must be the best so the only way I can guarantee that is I'm going to do everybody's job and mine.
That was probably the biggest challenge. And struggling a little bit with imposter syndrome as you're working with other people outside, not like it was privately that we had done a switch. The entire rest of the organization also knew that I was new to the role. And so you get people who would, well, here's a decision that I didn't agree with from six months ago that my predecessor made. Maybe I can work Mike around to my perspective or my opinion. Maybe I can re-present my side of a story in order to get the result that I want. There's a little bit of a period of time where it's open season and I think the team knows that. The team sees that. And so when you have the discretion, I will say to not immediately cave in, especially if it's a higher level in the org coming back and saying, "Well, your predecessor wouldn't let me do this. He didn't know what he was doing. I expect you to do this for me."
And you take that away. You go talk to the team and you get the context of why this is actually a shockingly bad idea and you go back and you hold your ground and present that to the leader who is pushing you. That's where you build credibility. That's where the team comes in eventually and knows, okay, well I know I can't go to you for, we're having this problem with the Linux kernel. What do we do? Because that's not your skillset, that's not your acumen. But I know you have my back and I know if I come to you with a challenge, you listen and help me figure it out. If I come to you with a need, you'll figure out the best path. The answer isn't always yes, but the best path possible together to figure it out. And that people, I think overuse the term servant leadership, but that mentality of, I'm really here to work for the team. The team isn't here to work for me.
And nothing really shocks you into recognizing that more than the fact that you know, can't do their jobs. I could not do their jobs if I wanted to. It's not even appropriate for me to say they work for me because I'm not qualified enough to tell them this is how you're going to do everything. What I can do is work for them to make sure that they have the space they need to be as efficient and as effective and oftentimes as happy as possible in their role. That was the other big kind of recognition is when you grew up inside of a team, that had its own challenges because eventually peers became direct reports, and so there was a little dynamic that you had to navigate on that front. But generally these are the guys you grab coffee with. These are the guys you grab lunch with. These are the guys you grab to drink with. You already had some camaraderie. It was easy to make jokes. It was easy to be a kind of close-knit family.
When you switch teams initially, they're all strangers or they were on the opposite side of your team sucks, no, your team sucks divide. It was also kind of appreciative of the universal power of not taking yourself too seriously, having a little bit of an opportunity to bring some humor into tough situations. The idea that you've won the meeting if you get people to laugh always at your own expense, never at somebody else's expense, just recognizing how universal those tools are. At the end of the day, we're all here because we agree in what we're trying to accomplish as a team and as a company, but we're also here because it's how we support our families. It's how we support our livelihood. The lighter you make those moments, the easier you make that burden by protecting your team, give them a couple of reasons to laugh. Letting them know you have their back again, doesn't mean you always agree with them, but letting them know that you have their back, that you genuinely care about them as people, that's universal.
And so that's kind of what I meant when I said earlier that the specifics change. But when you move a role like that, I really do think the 80/20 rule applies and that 80% of what you learned is universal is going to apply in the new role and you can't let the 20% that is different scare you from taking that on.
Shelli: Michael, first of all, that's incredibly impressive and as you've been talking, I've just been thinking, do you think this type of exercise or program could work in any organization or do you think it was a perfect storm of the culture that you were in, the trust that had been built, the people that were in place, what do you think was the most important element to make that work?
Michael: At a high level, I do think it could work in any organization, but I do think there are some things that I would, looking back, highlight that helped to make it successful. The reason we did it again was because of the cultural benefit it would bring, that kind of empathy between development and ops. I wouldn't recommend it if we were going into a shop that one of the existing teams was just foundationally flawed. There's that difference between it was a high performing infrastructure and operations team due to leadership that was in place at the time. It was a high performing development team. And so you could trade and let the leaders steep in and understand, hey, how do we take this to the next level, especially with cross team collaboration, getting more into that DevOps mentality and mindset so that you were progressing the team.
If it had been, we don't have an ITSM change management practice. We're building up a level one help desk from the ground up. This is the first time we're thinking about a globally dispersed. You're taking on the challenges of just the day-to-day, like how do you build the foundational building blocks then I wouldn't do the switch. That's where I think you want somebody coming through who's done it before they build out the foundation and then you make a switch that somebody comes in now with fresh eyes, with a fresh perspective, and with either a customer or a supplier experience base to really help evolve it and grow it.
I think the maturity of the program at CME was part of the reason for the opportunity. And I think it was also why maybe it was staring us to the face a little bit because there was a recognition that we'd already really built and achieved very high performing teams, but you had started to bump against that ceiling that the current leadership, myself included on the development side was already like I've applied my ideas and now the changes I see I see outside of my group, it doesn't mean those were the only changes that needed to happen, but you had almost been too close to it for too long to come up with fresh viewpoints, fresh perspective. That would be kind of the key driver that I would see that would make this successful.
Patrick: What I'm hearing, just both teams not fundamentally flawed. It's more like a friend of mine refers to these as the handoffs. Wherever that transition is of seeing it from the other person's, like when you're getting handed the baton, you think you're doing a great job handing it, that doesn't mean the person receiving it is receiving it. I do think that's a big area when we get into organizations or when things go from the sales side to the operations and then to your point on the subcomponents of operations. When it goes from marketing to sales to that initial engagement with a client to we're building the product, we're deploying the product, we're getting feedback on the product, those are the areas that really the hard part to get right for most, I think for anything involving humans.
And even talking about, of course, I'll bring it back to lacrosse when we do practicing, we are practicing those transitions. Everybody knows their fundamental stuff, but then we're going to do practicing on, hey, when we're moving the ball from defense to offense, offense has to be able to receive it. Defense has to be able to deliver it the way it needs to be delivered. And that's exactly the concepts that I try to... The fifth and sixth graders really get it when I speak this, it just snaps, instantly like, "Oh, what do you think, coach? I mean, should we use Six Sigma?" "Yes, 100% we should go with that."
Michael: Yes. Green belts across the board.
Patrick: Totally.
Michael: Yeah. And that's why I can't emphasize and encourage enough that concept of empathy and even extending the analogy you're using there with lacrosse. Offense, knowing how to distribute, defense, knowing how to protect and distribute, but also equally knowing for those transitions, offense, knowing where defense wants them to be. They've got experience from the defender and they see if they're getting swarmed. And I'm not going to pretend that I ever played lacrosse, but even other sports concepts of, okay, now because, I'm basketball, you're getting trapped in the backcourt. I need to come back to it... It's not just that I'm ready to catch the ball. I see his situation's changed. I've been in that situation myself, so how do I change in order to help him be successful? And that's why that switch became so important was because in reality, and I always liked kind of joking about this when we do performance reviews.
You'd get into performance reviews and somebody would come through the door and they'd just be angry, bent out of shape about so-and-so, and they can't be rated highly, they can't be promoted. And it all came down to one occurrence that lasted maybe 30 minutes five months ago, but it had left a bad taste in that person's mouth. And the mistake that people always make on that, and again, why I go back to empathy being so important is you saw a less than a 1% slice of that person's collective life for that year. But you've inferred from that you know everything there is to know about them. You know their job, you know the challenges they're facing on a daily basis. You understand why you would be able to do that better. And until you've really sat in that seat and until even something as simple as, I'll call help desk simple, oftentimes it's not at all.
Until you've been in that seat and you've tried to process a hundred help tickets as simple as they may be across 100 different people who are sometimes available, not available, pinging you when you're already on with somebody else now angry that you're not available to help because you're one of 20 people serving 8,000 individuals until you've been in that seat, you don't understand the context switching, time cost, pressures and frustrations. You're just the other person who's been on the other side of the line, justifiably frustrated that you've been waiting for 15 minutes for somebody to get back to you because you need help. And so the two sides need to have a better appreciation of, hey, that 15 minutes is really impactful.
As a help desk agent, I need you to understand that this person is begging for help. I need you to put yourself in their situation so that when you say, I'm going to have to get back to you, or I don't think it's an issue, or actually the one that kills me is, you open the wrong ticket so if you could open the right ticket and then reach out to a different team, they may be able to help you. You clearly don't understand that this person's come to you asking for help and you've basically told them pound sand. But the flip side is if you're one of 100 people who are trying to get help, if you don't understand that context of the other 99, it's very easy to get frustrated with the person who may be overwhelmed on the other side.
And so just a little bit of empathy goes a long way towards reducing that friction. And a lot of those interactions, if you think about them, you spend more time on the friction and the frustration and the escalations and the meetings to talk about why somebody isn't doing what they should do, then whatever actual activity really costs. And so now you're creating extra drag, extra impact, extra frustration, and those are the things that eventually start to create people being like, "Why do I want to work at this place? Why do I want to be here?" And if you lose that, that's when you lose the team.
Patrick: I love it. Quick extreme story. I'll try to keep it brief, not my strength. I was walking to work one morning and had just snowed. I'm coming down, we were over at Desplains and Fulton and walking past, there's the state building there and I'm coming down the street, just got coffee having a good morning, and the snowplow was coming down. I forget what street it was, but the only escape I had was to try and make it to the bus barrier. And I didn't. And I ran as hard as I could. This snowplow was not slowing down. Not only did I get whitewashed with snow and all the filth in the street, he honked the horn as he went past me so he knew what he was doing. He ruined my coffee, he ruined my day and I'm steaming.
And I get to the office and I hit, was it 411 is information for the city. And the lady who answers, she's like, "Hello, City of Chicago." And I launch into it. It was probably the most amazing thing I've ever, not most amazing, it was really tremendously impactful and very educational because as soon as I got into it, she said, "That sounds terrible." And instantly, instantly things like, "Yes, it was terrible." Wait, hold on.
Michael: I called for a fight. Where's my fight?
Patrick: I don't know if you understand, the goal here is you're going to disregard me. But to your point, I'm like, it is that empathy of... The other part is I think having anybody who's worked as a server, very generous with tips, very considerate because walked a mile in no shoes and the people who haven't. I guess I get into that question of stepping into the void and which is part of your personality. You've touched a lot of bases, you've stepped into a lot of scenarios, some by your own choice, that transition from the PeopleSoft to the QA, that is a huge transition of like, hey, we're taking a very structured environment of how we did development and deployment. You live inside of PeopleSoft and it's very well regimented to you are responsible to make sure that the quality of some of our most valuable client facing assets are working.
Luckily it has massive impact on financial situations throughout the world. A lot of visibility. No pressure. But what I love though is in that reorg, they must have seen something in you, there must've been a lot of confidence of we're not using this guy to maximum capabilities.
Michael: Yes. I mean, I would agree and I appreciate the statement. It's hard to agree without kind of feeling a little bit like I'm self flattering myself, but as a part of the reorg, you're putting pieces into different spots where you're like, "Hey, we've got to get a little cleaner, get a little smaller as an organization. How do we not expose holes and where do we have leaders maybe that are a level down that can then be placed up to take on a bigger role and a bigger challenge, but then also recognizing the ability to learn and the idea that you've taken..." And I think a big part of why I got moved across into that was twofold. One, being in the cross-functional QA was more visible, and that's a part of, I haven't really done a lot of these things in order to automatically drive career advancement. I've really done them because I wanted to drive interest in today.
I wasn't ever a person that would go home and study financial markets on the side. I knew that if I wanted to progress, I needed to work every day that was interesting and challenging. And soon as I started to get to a point where I felt like I was no longer learning in the role, that was inevitably going to stymie me. And so I needed that kind of almost stress acceleration of like, am I ready for this? Can I live up to it? Can I handle this to drive that extra pressure of really locking in and studying and understanding the material of the position I was in? And so I think one, moving into that QA position really kind of accelerated that and showed the ability to jump from, like you said, people saw being a fundamentally different role into that and learning it quickly within a period of time so that there was confidence that I could make a similar leap going into market reg. But it also helped that it improved my visibility.
I used to joke, we would have big change control meetings where you would go through, see me at a very heavy weekend change control cycle, as you can imagine, especially 15 years ago because of the fact that you couldn't do anything that would interrupt markets during the week. It was just a logical way to separate out that risk. And so any change that happened in the production environment would have to go through this, it was really a tribunal. We'd have three managing directors at the time who would review it and make sure they were comfortable with it. It was an opportunity also to catch those unintended cross team impacts that might happen until the PeopleSoft change came up. And you could see everybody's eyes glass over. If we had a lot of changes happening that weekend, they'd be like, "Yeah, so next 12 are PeopleSoft. Yeah, those are fine." And they would move on.
And it was because while we were necessary, we were not foundational to the team. And so I think the other thing that was that change was I moved out of a necessary role into a foundational role so that when another change came through, I had had more exposure to leadership. And so for somebody who's looking to progress within an organization, I would always encourage the closer you can be to why that organization exists, the more value you can bring to why that organization exists, the better off you'll be. Again, this isn't discounting the criticality of HR, the criticality of finance, any of those functions audit like a healthy organization needs those, but that's going to give you flexibility probably to switch organizations because they're also universal across a bunch of different places.
If you want to maximize your impact and your value, add an org. Understand why that org came into existence, understand how that org makes money, and then make sure that you are valuable to the functioning of, and that was a big part of, I think, what kind of facilitated and enabled that kind of career growth transition in my career.
Patrick: That's awesome.
Shelli: That's an excellent point. Yeah. And Michael, just curious, who did you have to turn to for help during all of this?
Michael: Well, I was very fortunate on a couple of the, I'd actually say in almost all of my roles, I was very fortunate in that I pretty much always had leadership that was open to the growths and the challenges. When I was on the PeopleSoft team, the head of all of the business reg systems, that was kind of what it was called at the time before one of our reorgs that we went through was a gentleman named Brian Toba. And I was very open with him about, "Okay, I feel like I've topped out in PeopleSoft. I'm more interested in getting through to other areas of the organization to get closer to why we exist as a company." And I've always felt, and I've always tried to encourage from my teams that if you can't be honest with your manager about your career path, even if it includes stepping out of their role or out of their team, then you probably do not have a good manager. You certainly do not have a good relationship with your manager on that.
And fully supportive, he would be keeping his ears open for opportunities that would pop up that I may not know about. I got the cross-functional QA. It was not actually the first position I had applied for within the org. And that manager inevitably is in discussions that you as the employee are not in, they have line of sight to activities that are going on that you may not know about. And so they're able to be in a position to bring your name up for these challenges, these opportunities before you're even aware the opportunity exists, which is why it's so important to be able to have that open dialogue.
And why ever since then, in any of my teams, I've always tried to repeat, I would say it at CME, I've certainly said it at Ryan, the idea that it is much more important to me for members of my team to remain with the company and not remain with my org. If you see an opportunity, let me know what you're interested in and we can do two things. We can one, find a way to dip a toe in it. When I had development teams, the most common answer I'd get for people is like, "I really want to be an architect." Everybody wanted to be an architect. I don't necessarily know why, but everybody wanted to be an architect.
Patrick: I get to make fun pictures.
Michael: And I think the idea of it was as a developer, you're working from a clean green field, you don't have anybody's debt to inherit. Your brilliance can shine through now because the blank page will only have Mike Pozzi is genius, spread across it, right?
Patrick: Genius. Check out my genius.
Michael: Yeah, exactly. Yeah. And then so I'd be like, "Great, every team ever always needs more hands, always needs more help." And so like, "Hey, we're going to have you four hours a week, eight hours a week spend some time, I'll figure out what to do with your stuff, but let's spend some time so you can work with the architecture team." And for two things, one, you get to try it out, and two, you're a known quantity so when they have a position come open, they can basically pencil your name in even before the position's out there. If the first time you think about, hey, I want to be an architect, is when you see that job listing, you're not prepared unless you're already an architect. And then more times than not, when a person would come back from that job fair style event on the other side, they're be like, "Yeah, I don't want to be an architect."
But at least now they figured it out without actually jumping in. They're like, "Yeah, I like the designs and I like coming up with the ideas. But what I realized is that's about 10% of the job and 90% is convincing people, documentation, changing things because somebody forced you to change it, having to re-explain yourself to somebody who doesn't know the material or the context why we really cannot make the servers run just purely on oxygen and we would have no electricity bill type of examples." And so they would see the frustrations in the other role instead of seeing the romanticized version, they'd have a chance to really experience it and then understand, hey, do I want to take on that job for what it brings and the negatives that every role has, or was I enamored by the pros that I would see from afar? And then once I got closer and realized it's not for me.
And so PeopleSoft leader, like I mentioned, Brian was super supportive of me changing roles. And then when I was in the market reg, like the entire IT management team at CME at the time, I reported to Sesh Sundaram at the time, and then I was going to a position under Mike Doyle and they were both fully supportive. And I think it was that same concept of not that I was threatening to leave the company because I absolutely wasn't. But it's that same thing of it's better to keep good talent in the building. And if you don't give a space for good talent to grow and explore and maybe make some mistakes and come back and move around, but really be able to expand in terms of their impact and their role, eventually they will realize that and say, "Okay, well the only way I can start to do what I want to do is to leave the building."
And I want to say historically, they've now fixed this, but 10 or 15 years ago, CME used to get this completely wrong with, they'd support people to get MBAs, particularly from technology, and the person would come back with the MBA and be like, "Okay, great. I want to get into the business." And the business teams would be like, "Yeah, you need five years of experience." And so you were training people and you were giving them these advanced degrees, and the tuition reimbursement program was amazing.
Patrick: That's great.
Michael: That's actually how I got my master's in computer science. But you weren't then aligning and setting yourself up so that then when this person went through all this personal effort in order to expand themselves, in order to get this better degree, that there was opportunity for them to then use and apply that. Like I said, I believe they have since fixed this, but I saw a couple people leave the company because they're like, "Well, I went through getting the MBA, I want to use the MBA, and you're telling me the only way I can do that is with somebody else." It's an extreme opposite example of if you do not give people the chance to flex their muscle and grow within the role and the confines that you've established, they will eventually leave. And that's how you get good people leaving your organization.
Shelli: Yeah.
Patrick: And I think your point's very valid. It's not even that they know what they want to do, they just want to try different things.
Michael: Yes.
Patrick: And I think that's part of it is especially growth minded people because what I hear through your story is I want to do interesting things. I think... Learning, I don't care what I'm doing as long as I'm learning something new. Stepping into a sales role was very interesting to me of I've been an engineer all of my life, and now I'm going to try sales and try marketing. I'm like, "Hey, let's see what this really feels and looks like." And I think that's how you get a complete picture of you can have empathy for salespeople that you never had before.
Guy stopped me on the street yesterday. He's like, "Hey, I want to talk to you about roofs and whatnot. I listened." I sat there and listened out of respect for the fact that this guy's going to get told no 4,000 times today. And when he got to the end of it, I said, "I'm not interested, but can we talk about your pitch? You got to do a better interrupt when you start the conversation. It's kind of milk toasty and not." We had a nice little conversation about it, and he is like, "So are you interested?" I'm like, "Absolutely not." [inaudible 00:40:00]
Michael: But still nice of you to give them time and tips.
Patrick: And just say like, "Hey, I appreciate what you're doing, man." It's a thankless job. It's a really hard job that I think a lot of people disregard. But Michael, thank you so much for taking the time today. We really appreciate you joining us and sharing your experience and your background and your wisdom. You're a tremendous leader. I've known that from the first day I met you. It's really been awesome. Thank you for joining us.
Shelli: Yeah, thank you, Michael.
Michael: Absolutely. Thank you for the kind words. Thank you very much for having me. It was a fun conversation, so really enjoyed it.
Patrick: Awesome. We also want to thank 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.
