Wouldn’t it be great if your boss had a user guide for achieving success under their leadership? Ann Yeung’s team at GEICO, where she serves as the Vice President of Engineering, Head of Enterprise Engineering, received one. In her “user guide,” Ann shares her expectations, values, and tools for successful collaboration that go well beyond pet peeves to establish communicative, empowered teams. 

In this episode, Ann discusses her transition to GEICO and the critical role of managing corporate functions during transformation. She shares her journey from individual contributor to leader and how she applies the lessons she’s learned along the way. Ann offers how her perspective has changed over time, (ex. how experience is important but unique application to any particular scenario is key) and outlines how her leadership values match her personal values: integrity, transparency, and direct communication. 

As a leader, Ann ensures that her approach includes two critical elements: understanding the problem from the lens of the business stakeholders and carving out time for reflection. Ann discusses welcoming feedback and challenging her teams with growth opportunities with intentional mentorship. She discusses how, as an engineer at heart, her love of data couples with empirical evidence to guide her decision making and the importance of responsible leadership. 

• (2:10) – Enterprise engineering at GEICO
• (4:22) – Playbook for success
• (8:46) – Transition to leadership
• (13:46) – “Ann Yeung User Guide”
• (20:47) – Building relationships and trust
• (23:34) – Opening the door to feedback
• (27:52) – Recovery 
• (30:09) – Decision-making
• (32:06) – Empowering your team

Ann Yeung is the Vice President of Engineering, Head of Enterprise Engineering at GEICO. Ann is a senior technology executive and business strategist with over twenty years of experience in various industries, including roles at Northwestern Mutual, Capital One, and US Foods. She is the Director of Women Who Code Chicago Network and serves on the Board of Directors for Chinese American Service League and STEM Forward. Ann earned a bachelor’s degree in computer science and mathematics from the University of Illinois Urbana-Champaign.

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.

Patrick:

Hello fellow innovators. This is Patrick Emmons.

Shelli:

And this is Shelli Nelson.

Patrick:

Welcome to the Innovation and Digital Enterprise Podcast, where we interview successful visionaries and leaders giving an insight in how they drive and support innovation within their organizations. Excited to have our guest on today, Ann Yeung. She's a senior technology executive and business strategist with over 20 years of experience in various industries. She's adept at implementing solutions aligned with technology and business growth strategies, enabling digital and mobile presence in scale. Ann's intensive technology career includes elevating software engineering culture, team motivation, change management, mentoring, leadership collaboration, facilitating business performance and results and distribution, tech services, financial services and insurance industries.

Ann:

Thank you, Patrick. Thanks for inviting me to the show.

Shelli:

Anne, if you don't mind, can you share with our listeners a little bit more about your role at Geico?

Ann:

Sure. I started at Geico last year in September as Vice President of Engineering, enterprise engineering. And you're thinking, "That's kind of vague. What is that?" Well, basically it's all things corporate functions and associate experiences. I tell my teams that our engineering teams are really the backbone of Geico. We have, like I mentioned earlier when I was talking to Patrick. In my past let's say seven years or so, my focus has mainly been on more customer facing technology and then also sales facing technology, sales especially in my last role at Northwestern Mutual for our wealth management and financial advisors. So when I moved to Geico and took on this new role, it's quite different because this is all internal facing corporate function technology.

And I found in my nine months in at Geico, I've come to a realization that when companies are going through a lot of transformation, the corporate functions are actually hit the hardest because there is a lot of people in process changes that need to happen and the underlying tech that needs to enable it goes through a big change and being the backbone of any company, these corporate functions going through a digital transformation are extremely important in order to enable the success of all their functions. So I feel like sometimes you don't feel like it's as sexy because corporate functions don't drive revenue because they're not revenue producing, but then if not done right, the efficiency of the company and how we can operate gets impacted, especially during digital transformation and change.

Patrick:

So you mentioned the business functions and going through digital transformation. What is the biggest challenge about that? I know people generally think about tech and I think most of our listeners on the podcast know that it's going to be most of the people issues in transformation. From your experience, what can inhibit success if you're not thinking about the people in that? When you get engaged in an organization and you're involved in these types of transformation, what's your playbook look like?

Ann:

Yeah, I mean, I wouldn't say I have a specific playbook for every thing that I jump into. I would say that it's more really the experience and drawing from that in terms of what's worked well and what's not. Because every organization is different and every organization in terms of maturity and change, you have to meet them where they are. You can't just come in with a playbook that you've used or that you've created from your previous role and think that, "Oh, it's going to work," because one is the organization is different, the people in it is different, the culture is different and maturity across different capabilities are different. So applying the playbook as is will not work and it's almost like, "Okay, well these are the experiences, these are things that I've encountered and if I'm seeing similar things, how might I apply some of the solutions that I have used before to move forward?"

I would say reflecting back on maybe when I first moved into leadership and I was sitting in a different seat and the company at that time, was going through a digital transformation, I would say my experience from that when I was in a different seat was that I actually came in thinking I had a playbook, and at that time, I was moving from an individual contributor. I was a very senior architect, so a domain expert in the space that I was architecting and building, and I moved into a director role and it was my first time moving into a leadership role and it was quite a big jump moving from individual contributor to director where I had to be a people leader of people leaders of people leaders. And I thought my technology strength as a technologist and engineer was going to fix everything. I was like, "I know how to build this."

Looking back, I feel that that was, not that it was wrong, I mean, it's good to be a really strong technical leader because that's table stakes. You have to know your technology, you have to know how to build systems because a lot of times you'll be building new systems or integrating systems. But what was more important in order to enable successful outcomes is understanding what is the problem that we're trying to solve and what's the most important problem? And from the perspective of your business stakeholder or your business leader, not from your perspective, because I feel like sometimes sitting in a seat that I sit in, I may see the problem differently. I'm putting on my engineering brain and I'm like, "Oh, this is how we're going to fix this problem." But to the business leader, they may articulate the problem a little bit differently and their definition of success and what that looks like may be a little bit differently than what you're thinking.

So I think when I look back on some of my experiences and what I've just observed as I moved through different roles in my career is that being very clear on the problem that is being solved for and having that clear alignment with your various stakeholders on the problems and success is key. Before jumping into building out what the target state looks like from a tech perspective and being able to have good alignment is actually the hardest part. And defining those problems and success is actually the hardest part. I feel like at this point in my career, I feel like a lot of times building the right tech, the right tool, the right software, that's actually the easiest part.

Patrick:

I agree, and I think I'd love to hear more about that because I think that in a conversation we've had before, that moment of the tech is table stakes. What happened? Is there more you could share? Did you have a mentor or was there just a moment where you realized, "I don't know what the business objectives are and I'm solving the problem as Ann Yeung, the engineer, not Ann Yeung as the business consultant"? Is there part of your background, whether it was doing some consulting or? Because that's where I think a lot of our listeners would get a lot of value is understanding how to make that transition from being that narrow to very broad and thinking a little bit more from a general kind of perspective.

Ann:

Yeah, I wouldn't say it was any one moment that I had an "aha" that was a pivot, but it was really through a lot of reflection on what's happened. For me, I think what has really helped me as I transitioned into different roles or different leadership roles and then getting bigger, broader scope is that I always make time to reflect on things, and it's almost like a blameless ritual that I do with myself. It's like, "Okay, let's just look at what happened and let's look at what you could have done that would be different and how would it have impacted different outcomes?" What did you do that was really, really well? And you would be like, "Hey, I have to continue doing this, because this went really well"? But it was really a lot of reflection along the way and being able to look myself in the mirror and have that really honest retro with myself.

But I did start my career earlier on when I was an individual contributor. I did spend years with IBM and their application services consulting, so maybe I picked up something along the way, even though I felt like I was pretty junior. I was mainly a hands-on engineer and developer. I joined a lot of different engagements and I seen how people navigate the room and there was learning that happened there too from that consulting mindset, active listening, asking the right questions. But for me, really making sure that I'm solving the problem from the lens of my stakeholder, and I teach this to my team too because a lot of times when I interact with my team or even have some skip levels or they present to me what they're going to do and the solution, and I ask them, I'm like, "Well, what do you think the solution is solving for?"

They would answer me. I'm like, "Okay, what do you think that's solving for?" I tend to ask the questions that they don't like. They're like, "Why is she asking me this?" But usually, three or four questions into the why of why you're doing this and why you're doing that, you get to the conclusion that you can either answer that fourth why or fifth why of like, "Okay, this is the business problem that I'm solving for," or "This is the outcome that we're going to get if we solve this" or you don't know, because if you get into deep enough into the third or fourth question with me and you're kind of like, "Well, actually I don't know," then you realize, "Man, I really don't know and I don't even know if my solution's really right," because you're not sure.

And I think that's my self-check when I try to solve something and I'm about to blast off an email or something to someone and be like, "Oh, this is what we're going to do for you," I'm like, "Wait a minute, okay, what is this going to do? What is that going to... I think like that. And then I get to the point, "Okay, this is what I'm trying to do," and then I actually start with that. "So and so, based on our discussion, this is the outcome that I think you're looking at and this is the problem that you're looking to solve. I want to make sure that that's really what we're doing before I go and say, 'Hey, tada, I have a great solution for you.'"

And I think that's been years of, I would say, evolution. I can't say that I was a fast learner, that I picked up on that right away, but it's really from experience of reflecting on what's happened and how do we get to better. And I feel like that's still a learning for me because I think the problems get more and more complex as my responsibilities grew and my span of control grew, and a lot of times the complexities, they're all dependent. There's a lot of interdependencies and dependencies to unravel.

Patrick:

Well, and the people involved are more complex, right?

Ann:

Yes.

Patrick:

Their motivations. I coach lacrosse, and one great thing about coaching 3rd and 4th graders, they are not complex. There's no nuance. You don't have to filter things out. They're there to have fun, score some goals, it's pretty easy stuff. But as we're older and we get more mature, we get a little bit better at being maybe not as straightforward as it would be helpful, so dealing with those situations. A couple of themes that I heard that really resonate, I think, with all leaders is one, that self-awareness, having that self-awareness. So a little bit of self-doubt of like, "Did I do it right? Could I do it better?" That curiosity even on yourself. That self-awareness and self-analysis, and then the curiosity of asking more questions. When you went through, and as I know we're all a work in progress, but does your team, have they gotten to an understanding of, "If I'm going to have a meeting with Ann, she's going to ask these questions," so they start anticipating them? Is that some of the outcomes that you're looking for?

Ann:

Yeah, so it's interesting that you asked this question and maybe because we talked about it before. Many years ago, I actually started producing an Ann Yeung user guide because as I was moving through and when I was in my first role as a leader, someone on my team actually suggested that to me. They were like, "It would be really great if you can create a user guide and share it with us. Your expectations, your values, what you like, how you like to have meetings and what we should be prepared for." And when he said that to me, I was like, "Wow, that's a lot of transparency and vulnerability for me to put that out there and be judged."

But then the more I thought about it, I'm like, "As I'm moving into different roles and organizations are changing because the transformation requires your work to change and you're having new leaders come on board, you have leaders shifting out, how do I make sure that my leadership team and everybody and my extended leadership team understands my expectation and my values and what are important and how I like to operate? And also what are some of the pet peeves that I have? How to really not start a meeting on a bad way? 'Don't do these things because these are some of my pet peeves.'"

So I captured it on a user guide and I think I'm on Version 4 or Version for that one. I don't even remember at this point, but I tend to redo or relook at that user guide as I move into a new role or take on new responsibility, or I myself have evolved as a leader. So then I can put that in there and have people on my team know and I just share it. I share it with my immediate directs team. They share it with our extended leadership team. If anything, it makes for interesting conversation and it's like, "Oh, I didn't know those sort of things that bother me," or, "Oh, I didn't know that you had the similar pet peeves." So it's been interesting. It's an evolving user guide.

Patrick:

All right, I need to know. Give me one. I need to know one pet peeve. What is the thing that... For me, I don't like when people are late to meetings. That sets me off. I think it's very disrespectful to everybody else. So do you have one? Is there one that...

Ann:

Yeah, I do and one of my pet peeves is that when I come into meetings, I know that sometimes people want to build up the case to lead to the like, "Okay, this is what we need." I don't like that. I'm like, "Start with what you need. Please just start with what you need because I'm here in this meeting, I'm not going to sit through 20 minutes of you leading me down the path, and then tell me towards the end," because then I'm not prepared. Because again, going back to the decision making, if I'm there, then I want to know what is my role in a meeting and what do you need from me? Tell me upfront so then I can listen to everything else and not think about, "Why am I here." So that's one of the biggest pet peeves is I've reviewed material from my team and a lot of times I'm like, "Okay, I need to know why you need me. What is the thing? Give me a really short summary ahead of time."

Patrick:

I say, "Give me the headline. Give me the headline. Are we on fire? Do we need... Just headlines. And it's amazing. I think most executives, they appreciate the brevity of, "I don't need all the evidence. Let's start with is it on fire or not?" So I use that phrase,

Ann:

Yeah, but engineers don't think that way.

Patrick:

I know. They don't.

Ann:

What I found is that engineers are like, "Oh, I want to lay out all the facts, the logistic sequencing of everything before I get to my conclusion of what I'm about to tell you."

Patrick:

And to me, that's part of when you start to see who has potential leadership capability out of the engineering crew. Have you ever looked into the different personality traits like the DiSC profile?

Ann:

Yes.

Patrick:

Right? So leaders are... There's the D, the I, the S and the C and engineers generally fall into the careful and their biggest concern is to be wrong. So they're submitting evidence to support their case where you got to get to more of a, "Just tell me what it is."

Ann:

Yeah, and I mean, I, myself, was like that before. I used to write up long papers and long PowerPoints and long emails, and I was thinking back, I'm like, "Man, my VP must have really hated reading those long emails." So it's like at some point in my career, I think I hit that self-awareness too, where it's like, "Okay, look, you can't continue these really long emails." And I would say that some point, one of my bosses actually said to me, "Ann, I don't need the long lead up. I don't need all the data points. Just tell me what your decision is and I'm good."

Patrick:

Right.

Shelli:

I'm just curious, what's the most interesting outcome or response from you putting out that user guide?

Ann:

I actually had someone reach out to me, and I wouldn't say it was interesting, but they felt it was very refreshing to know what my values are, my expectations are, how I like meetings to be, what is my communication style, what are my expectations if they were to meet with me one-on-one? They just felt like that was very refreshing and very transparent. And I also said in my user guide that I'm usually a very direct person. There was really not a lot of complexity. I like to keep it that way where I usually say what I mean, and that's what I mean, and it's all coming from a good place. I was like, "If I give you feedback regardless if it's good or if it's critical, it's always coming from a good place. I'm giving you this feedback because I think it's going to really help me, it's going to help you and that's why I'm giving you this feedback."

So I think a lot of times I think just when I interact with my teams, I don't interact in a very hierarchical level either. I talk to anybody on my team, skip, skip skips levels. And I think sometimes when you're an executive leader and you don't get a lot of exposure to some of your more entry level or ICs, they don't know how to interact. And I think just having that out there gives them a place to start from and they're not just navigating from the dark and just having that transparency, I think, is very key.

Patrick:

I think the transparency, the clarity of like, "Hey, here's how to be successful," and the humility that's required, I think it builds a lot of trust because I think we've all been in large organizations, worked with them, when somebody comes in, generally everybody's trying to figure out how to work with the new boss and what are the expectations and what is the cadence? So I think it's awesome. Do people sometimes come to you and share with them, "Hey, I really appreciate this is how you do it." Do some of your directs give you feedback on, "Hey, this is how I," or do you do some of that investigation while you're meeting with them? How do they like to be communicated with? What are their decision making processes?

Ann:

Yeah, definitely. I would say that as I meet with people, I'm trying to figure that out too because I think that's part of, going back to our previous conversation on how do you build relationships and trust? It's a mutual thing. I don't expect everybody to tailor themselves to me. So I'm trying to also figure out how they like to be communicated to and what are their expectations, what's trying to motivate them. So for me, I'm trying to figure that out. Now, I have to say, no one's been brave enough to send me a user guide yet.

Patrick:

User guides go down, they go down the tree, they don't come up.

Ann:

No one's one day decided, "You know what, Ann? This is my user guide-

Patrick:

Yeah, "By the way."

Ann:

... and this is my expectation of you." I'm like, "I would actually love to see that," because I feel like as a leader sometimes, especially as a senior leader, really good feedback and especially critical feedback, it's hard to come by. Because I think when you're at a certain level, there's almost an expectation that, okay, you're either going to do this perfectly or not. There's not going to be a lot of learning or feedback that I'm going to be giving you, so you're not going to be getting a lot of critical feedback. And usually if you do, you're already in a problematic place. So to me, I just think you don't get a lot of feedback from the top, and then you're in a position where people are afraid to give you any feedback, so you don't get any feedback from your team.

And then the peer feedback, I feel like sometimes is really good. If you have a group of peers that you have that relationship with that they would be willing to give you feedback because they see you in action. And I think feedback comes best when people see you in action, because it's hard when they don't see you and how are they going to give you any feedback? Based off of what? So I think that's definitely one of the things, and I always say that I appreciate in my career is that there have been a lot of people that was willing to step up and give me feedback, and I have been able to take that feedback and really just mature myself as a leader.

Patrick:

I got to believe somehow you're opening the door to the feedback. You're making it a safe place for them to... Is there something that you do consciously trying to create that environment where feedback can be at all levels? We're here to get better. Your own personal focus on constant improvement and that curiosity. Is there something that you do with your directs that you hope to have them emulate to create that culture of curiosity and openness of questioning?

Ann:

Yeah, I mean, I think it goes back to my values, my values as a human. And I think those are the same for leadership values. And people always ask, "Oh, what are your leadership values?" And I'm like, "They're the same values that I have as a human because those are not two separate things." But for me, I always like to open with that is that for me, I value integrity. So for me, it's always operating within that integrity of my values. And I value transparency. So for my team, I think knowing that I value transparency leads them to being more transparent with me. And I value just really direct communication, because that's important as a team is that we are able to be transparent and communicate directly. So it's not a person talking five minutes into it and I'm like, "Wait a minute, I still don't get what you're trying to say. You're not telling me what you're meaning to say." Having that really direct conversation, I think, is always important to me, and I do that with my team, and I think they emulate that.

The other thing is that continuous learning and improvement, because I don't believe we always get it right the first time. I think that there's always going to be, you get it partially, but then the improvement and the ability to iterate and learn from what went wrong and apply it and the recovery is almost more important than trying to get it right the first time. And I am always like that, and I'm not afraid to make mistakes either. I tell my team, "Okay, this is the decision. This is what I'm going to do. Now, is it going to be right? Maybe. I don't know until we do it, but I think based on what I know, this is what we're going to do." And being able to as a leader have that vulnerability to say that, "Hey, I'm going to make this call. May not be the right thing."

And I always jokingly say, "It may get me fired, but this is my decision and this is what I'm going to do. And if it doesn't work out or if we need to pivot or iterate, we'll do that." And I think that sets the stage for people to see that, okay, it's okay that we don't always have to be perfect in trying to do what we're trying to do. Because a lot of times when you're driving transformation, you can't be perfect. There's going to be things that will go wrong. And I tell the team, it's like, "I'm going to be evaluating you on not the things that you got right, but the things that you got wrong and how you recovered. I think that's going to be even more important than what you got right." So I push that with my team as part of my core values as a person, and I think grounded on those things, I think people understand how to operate within my team.

Patrick:

You use the word recovery twice. First time, I paid attention, second time, I think that's a tremendous perspective that I think a lot of people don't realize. To your point of we're going through change, we're doing new things, the likelihood of getting that right, even mostly right, is pretty low. The only real choice is stasis or being partially right. And then that recovery component of you're focused on constant learning and improvement. For many people, I think recovery would seem like a bad word, but it's absolutely the critical word of, "We don't bat 1,000. If we're batting 1,000, we're probably setting the goals too low, we're going too slow." But I'd also argue both those, setting goals too low and going too slow, we're going to lead to even worse failures, right?

Ann:

Right.

Patrick:

And the inability to recover. Tell me more about your perspective on recovery because I think that's really an interesting perspective.

Ann:

Yeah, I would say maybe it comes from being many years as either a senior tech individual contributor or a senior tech leader, is that I've found that a lot of times we find ourselves in situation or mistakes that when you unpack, you do the root cause and you do the retro, you realize it wasn't the one thing that caused it. It's actually many times the biggest incidents or problems are multiple things that went wrong. It was almost like everything that could have went wrong, went wrong, and this is what happened.

So for me, I think a lot of times it's important to understand what led to the problem, but in the moment you have to recover from the problem ASAP. And I think that's where, when I think about things that go wrong, I'm like, "Yeah, it already went wrong, so there's no point in blaming or dwelling on that. Yeah, it's important we do a postmortem and understand how it got there, but in the moment, we need to recover as soon as possible." The recovery is almost like an all hands on deck. What are we going to do to recover? And I think sometimes when mistakes happen in the moment, people dwell so much on, "Oh, my God, this happened and this went wrong and that went wrong." I'm like, "Oh, instead of wasting the time on that, let's figure out the solution and fix this ASAP. Then we can talk about what we can do differently next time so we don't make the same mistake again."

But I think that's been why I focus on the recovery with my team a lot is that okay, this is not the moment to point fingers or blame, this is a moment to understand our problem and figure out a solution. And a lot of the solutioning is through some trial and errors too, so if I'm going to continue dwelling on all the mistakes that we're going to make, we'll never get to a solution.

Shelli:

That's a very healthy approach.

Patrick:

One of the things you mentioned also around the trust and developing your relationships and having really successful meetings, the decision-making process, when you're executing more of that decentralized leadership, you're trying to empower people. You mentioned you're getting into meetings and there's a bit of a philosophy for people between data-driven decisions and more ambiguity. What's your perspective?

Ann:

For me, going back to the leadership tests or different assessments, I'm an engineer at heart, so I do like my data points. So I've come to when I'm going to make a decision, I always think about the urgency of a decision. It's like, "If I don't make this decision now, what's the urgency? What's going to go wrong if I don't do it now?" Because what I want to know is do I have time to gather the data points that I'm going to need to make this decision in the way that I would be most comfortable making it in?

But if the answer is no, you actually don't have the time and you may not have all your data points, then the decision's coming from a place of experience. It's almost like, "Hey, I've had enough experience up to now that I know gut-wise that this is the right thing to do." And burying all things in terms of the reasons why we can't do it, and there will be many, is what is the right reason? And when I have to go explain my decision and why I need to do this, do I feel that that aligns with my values and what we're trying to do as a company, the mission and what we're doing as a company too. So I think those are very important things for me as I think about the important decisions that I have to make without always having all the data points.

Patrick:

That's awesome. When you think about empowering your team and delegating some of these decisions, how do you go about doing that? Because that takes a lot of trust on your part. It's a precarious situation of, are they competent? And I know that word triggers people sometimes, but I think it's a relevant question of are they competent in making this decision? Is this their authority? How do you go through that process to make sure that when you are handing the keys off to other people to make some of these decisions, what does that look like for you?

Ann:

Yeah, I think about it in actually, a few different dimensions. I don't just delegate the work to try to get it off my plate. I think a lot of times when I have work on my plate, I think first and foremost, "Do I have to be the one that do this?" Because there are some things that come on my plate that's like, "Mm, actually, I have to be the one to do it. No one else can. And this is something that I have to do." And if I'm like, "No, this is not something that I have to do," then I think about the people on my team and it's not always my directs. Sometimes it's that skip level that is like, "Oh, this would be... I think about, "Is this going to be a great opportunity for someone where they're actually learning and growing?"

Because I think as a leader, when you delegate work, you don't just think about, "Okay, who's going to have the highest chance of success of getting this work done?" Because then you're going to always go to your most seasoned person, your most experienced person, and then other people not on the team, are not going to get the opportunity to grow and stretch. So to me, I think about, "Okay, who are the people that can get this done? There's that group, okay, who's going to really grow from getting this opportunity to do something like this? And they're going to really learn?" And then I delegate to the person that's really going to grow. I mean, there's going to be the chance that they will fail because usually if they're going to grow from this, and that means they haven't done something like this before.

But then I think about, "Okay, well, how do I make sure that I set them up for success? What are the guardrails that I need to put in place to help mitigate some of the risk that they could be set up for success?" Because when you delegate something, I think it's not just getting it off your plate or getting something done, but as a leader, it's your responsibility to make sure that you're setting that person up for success. And I think sometimes as leaders, we don't think about that as much. I think sometimes it's just we're like, "We'll give it to them and we'll see." And I would say in my career, I've seen that happen where someone's given me something and they didn't really set me up for success. And I realize that. And then I'm trying to figure out how to set myself up for success.

And when I think about that in retrospective, I'm like, "It would've been great if my leader actually said, 'Hey, Ann, this is going to be a stretch opportunity for you. I know you can do it. These are the things that you should watch out for and you should get help from so-and-so to help you with these things to watch out for.'" Because as a leader, I think you know when you give someone an assignment, you've got to know what are some of the high risk areas and gotchas and just getting a heads up, I think when you get that assignment, really helps set someone up for success.

Patrick:

The sink or swim challenges of, let's see if they rise to the occasion. And my experience is more times than not, people cannot rise to the occasion, not because they don't want to, but you actually sink to your lowest level of preparedness. And I don't think that's judgmental. I think it's important as leaders, we think about that of, "I know I want this person to have this practice, but they're ill-prepared," right?

Ann:

Yes.

Patrick:

I think it's a good testament or it's an environment to find out whether that person's going to ask a question, because I think to your point, you're open for business and there's leaders that I think sometimes they will delegate those things and then you say, "Hey, can I meet with you to discuss what victory looks like?" And it's like, "No, I don't have time for that."

Ann:

Yeah, I would say that's just not cool. I feel like that's almost a lack of accountability on the leader's point, especially if you are giving important work to someone on your team and you're not setting them up for success. Who do you think that accountability comes back to? It's not that person. You, as the leader, own all things. You're accountable for it all. So if that person's not successful, you're not successful. And I think that's just a responsible leadership.

Patrick:

Yeah, it definitely seems like a less preferable lifestyle of you're just making potholes. This is going to be a bumpy road. Well, Ann, I really appreciate you coming on the show today. Really appreciate your perspective. I'm inspired with the idea of having your own user manual. I think I could put one together for my kids. I think they could use that. I think that might help them understand how to operate Dad, because that's been a pretty long struggle of , "What is that guy asking for?" I'm not sure it would be that successful with a 19-year-old, but give it a shot. But I really want to say thank you again for being on the show today. I really appreciate it.

Shelli:

Yeah, Thank you, Ann.

Ann:

Yeah, thank you. Thank you both. It was a lot of fun. It was an engaging conversation and a lot of fun. Thank you so much for inviting me.

Patrick:

Our pleasure. We also want to thank our listeners. We really appreciate everyone taking the time to join 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.