In this episode, Christina discusses determining what to build and creating team-wide investment in its success. She considers the role of research and development from pie-in-the-sky projects to simpler, value-adding solutions. Christina offers her perspective on building narrative and encouraging engineers and developers to witness the value firsthand. (For example, “If your grandmother was in the store shopping, what is the experience you’d like her to have with the software?”)
Considering culture, Christina dives into a culture of accountability and being a champion of quality. She shares her thoughts on shifting left, the results she’s seen in earlier testing processes, and searching for the root cause of an issue. Alongside accountability, Christina identifies key areas of success like avoiding silos of communication and leaning on creativity in strategic planning. She offers her perspective on leading a team of passionate engineers and her approach to leading the group through transition (ex. one-on-one time with everyone). One key to her team’s success at Echo: carrying the load together. Speaking on leadership, Christina shares how to work across different strengths and mindsets, build trust, set clear expectations, embrace vulnerability, and ask for help.
- (01:30) – Echo
- (02:52) – Finding software
- (05:15) – Building the right things
- (08:52) – Narrative
- (10:36) – Witnessing the value
- (13:00) – Shifting left
- (15:13) – Recognizing the hurdles
- (16:15) – Little leadership reminders
- (17:38) – Leading engineers
- (19:57) – Building passionate teams
- (22:57) – Setting clear expectations
- (27:17) – Creative solutions and planning
- (32:30) – Asking for help
About Our Guest
Christina Garcia is a Senior Vice President of Engineering at Echo Global Logistics. Her technology and business expertise have led to career achievements in engineering, strategic technology implementation, and leadership, including positions at Capital One, SEQR, Sears Holdings Corporation, and OfficeMax. Christina earned a bachelor’s degree in computer software engineering and a master’s degree in e-commerce at DePaul University.
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: This is Shelli Nelson.
Patrick: Welcome to the Innovation and the Digital Enterprise Podcast, where we interview successful visionaries and leaders giving you an insight into how they drive and support innovation within their organizations. Today, we're excited to welcome Christina Garcia. She's a Senior Vice President of Engineering at Echo Global Logistics. Christina is a visionary leader with a rich blend of technical and business expertise. Her career spans significant achievements in engineering, strategic technology implementation, and team leadership in a high-transaction environment.
Christina's journey bridges the gap between in-depth technical solutions like blockchain for enhancing authenticity and strategic business outcomes aimed at elevating both individuals and the overall business. She is deeply engaged in the evolving landscape of cloud technology, digital payments, and the pressing challenges posed by advancements in deepfakes. We're excited to have Christina share her insights on navigating career transitions, the distinctions between being a developer and engineer, and a proactive approach to mentoring and participating in the panels and organizations that shape the future of technology. So, welcome to the show, Christina.
Christina: I'm so happy to be here. I'm so humbled. Thank you. What a great introduction.
Shelli: Christina, if you don't mind, can you share with our listeners a little bit more about your role at Echo?
Christina: Sure. So, I'm the Senior Vice President of Engineering. I'm responsible for our product development teams, Agilists, architects, as well as our quality assurance center of excellence. We're responsible for delivering the solutions and the cutting-edge technology, innovative logistics solutions that simplify the complexities of transportation management for our clients. We do real-time tracking and analytics to optimize freight management. We're dedicated to delivering reliability and efficiency across the supply chain.
As we navigate the ever-evolving landscape of global logistics, our mission remains steadfast, to provide seamless and sustainable logistics solutions that propel our business forward. I'm really excited to be here not only to talk about what we're doing here at Echo, but how it transcends across all of the technology landscape as we continue to navigate such an ever-evolving space.
Patrick: It's great stuff. Christina, you've been in tech your entire professional career, if I'm not mistaken. Is that correct?
Christina: Yes. I'm not going to say how many years then.
Patrick: Well, we're not going to know. That would be impolite.
Christina: Yes, all three of them.
Patrick: You're quite an achiever. You've gotten very far in 36 months. I am curious though, how did you get started in software?
Christina: It's a funny story. I know a lot of individuals today, they have the option of computer science and they know what it is and they go into school pursuing it. For me, I was the first born of two high school dropouts. So, it was you're going to be a doctor, you're going to be a lawyer. I'm the first to go to college, so I'm like, "All right, pre-med, here we go." Because it just seemed more fun. I love science, and then you take a gross human anatomy class. So, we go to visit this lab and they're like, "Oh, you're working a..." Wait, I'm touching dead people. I didn't know that when I chose my major, and I was like, "Oh, my God. I need a new major."
Luckily, I had a computer science 101 class as an elective, which my advisor had recommended that I take just given my mathematics and science lean for my pre-med degree. I fell in love with the black and white, the class. You were right, it was very mathematical, no touching dead people. I knew at the end of the day that my solutions were going to work. It was a dopamine hit of yay, it was great. So, hence I just kept pursuing that path and here I am a software engineer and now a technology leader. I still get the dopamine hit when I have a problem solved or when I see an engineer come up with an aha moment. I'm like, "Yes!" So wonderful. So, it really started from not wanting to touch dead people, honestly.
Shelli: That's awesome.
Patrick: I was curious, do you still touch code from time to time?
Christina: Yes. I mean, I dabble in it not for work, but at home, I like to stay abreast of a lot of technologies and I'll play around with it. So, as newer languages come up like Mojo, I'll play around with it and my son, who is nine years old, wants to be an engineer. So, together we do little coding projects and we're doing that. My daughter's had no desire to walk in my footsteps when my son is. So, I take every advantage to code with him and make it fun.
Patrick: Oh, that's awesome. That's really cool. One of the things we talked about when we discussed being on the podcast and I thought was really interesting was your perspective as technologists, building things is important, making sure they're built with quality, making sure that they're resilient, right? They're readable, all those good things about software, but I think your perspective on making sure that you're building the right things. So, do you mind sharing your perspective about the difference between the program or software engineer and how it's important to focus on building the right things?
Christina: I learned this along the way, so I'm not going to claim that I was the genius who came up with it in the middle of the night like Einstein did with his theories, but I've come across and I've seen there's these two mindsets, the developer mindset and the engineering mindset. The developer mindset is I can so I will or I'm told to and I'm just going to code and make it happen. The engineer mindset is really about, "What is the ultimate problem? What am I trying to solve? How do I do that ethically and how do I do that for the ultimate good, for our customers, for our users? How do we use these solutions to actually improve where we need to improve?"
Even with AI, we ask a lot of these questions. What is it solving? How is it making it better? How do we make sure it doesn't have an adverse effect? So going into a solution and really saying, "What is the problem? What am I ultimately trying to solve? Who am I solving it for and how do I do it in the right way?" So that it can grow and shape and live and evolve with the ever-changing needs of your customer base or your business or the processes, whether it be a financial process or even just a user experience.
Patrick: How did you come to that? I mean, like you mentioned, was there an evolution? Is there a pivotal moment when you realized that... From my perspective, I think I had that moment right after the .com bust of like, "Hey, they don't pay us to just write code." These three little letters became very important, ROI, right? They have to get value back. Right before that, it was like, "Hey, they pay me to write code because I'm awesome."
Christina: I'm awesome. Well, even ROI, there's the I can develop a solution to deliver the ROI or I can architect and engineer a solution that gets us beyond where we are today, right? Because ROI is very short-term focused versus is long-term focused. I think there was a project in my life and I'm not going to share much about it, but it seemed like a very tinkery project. It was we can, so we should, and therefore, we could build a business case around it. Almost if you build it, they will come thing. But they never came and I was just like, "Maybe we approached this wrong. Maybe we put the cart before the horse because we really just wanted to say that we could do this thing."
Some R&D is good like that, right? Some of that R&D and pie in the sky, you should be doing, but you also have to step back to make sure that the R&D that you're doing has some ultimate long-term goal for improving something, not just hey, it's so catchy and cool. We think it's going to make a ton of money like Google Glass or anything like that. Yeah, kitsch and cool, but what did it really solve? As you see, it's no longer on the market. So, really engineering for the viability of solutions for needs and really sitting with the problem and saying, "As a user with this problem, what do I ultimately need?"
Not hey, this is really cool and I think it's great. So, I have a business case that says it's going to sell a million things because it's just cool and people like to buy cool things. I don't know. That's just a perspective that I've seen and it tends to serve me and my teams well because the solutions we architect are simple, lovable, complete, and ultimately allow us to continue to add value over and over and beyond.
Patrick: Very interesting. Is that something you're trying to develop? I know sometimes when you engage with the product teams or at least from my experience, when you engage with product teams, understanding that long-term value, what is important now from a business perspective versus that even far horizon? Do you struggle with creating that clarity for the folks on your team?
Christina: It comes down to narrative and storytelling, and that goes back to influence as well, right? If you're able to truly understand what your product individuals are asking for now or your business individuals are asking for now, you could take them through a narrative of a story. Well, what does this look like in the future or what if this happens or what if it changes like that? You start to go through the what ifs and they're like, "Oh yeah, that makes sense and I could see that," or "Oh, this might happen in the future." In which case now you have additional narrative to bring to your engineers when you're talking about, when we're architecting this, these are potential outliers.
So, build in a way that allows you to adapt and pivot for X, Y, and Z in the future in case it comes up or it needs to come up. So, I don't like to sit with product and say, "Okay, I got your order and now I know what you want." I really want to understand from them, it goes back to understanding the problem. What is the problem? Who is my user in this situation? Give me that persona. Help me understand who they are and why they need this and what their real problem is. Because they're using our solutions to do something in their life, whether it is pay bills or get their groceries or for us, move transport.
So, how do I help them be more efficient and effective? Yes, they're asking for this one functionality now, but what are the additional change? Let's go down the chain of all the tasks that they have to be really successful in their own. How do I build the solutions to help them do that or architect at least to make sure that it's viable for us to quickly do it in the future?
Patrick: I've heard stories of different organizations, especially when you get into some of the hard tech, understanding and appreciating the solutions that you're building. Do you have your engineers or lead engineers actually go out and see how the solutions actually operate and problems that they solve?
Christina: So from prior orgs, it has been a thing for me to have my engineers sit on help desk calls, sit on support calls. At Echo, I'm still a year in. So, I'm working on getting them to sit with the business, watch them do work, sit on those performance calls. Actually, we recently started having our business partners come into our PI planning and talk about how they use their solutions. Again, there's a slide deck and here's all your objectives and your features, but having the businessperson come in and say, "This is how we use it, this is how it manifests itself, this is what our customers are telling us about the solution," that creates that little connection and that connection allows them, without me even asking, how do you make sure that we are servicing this beyond all that?
So that understanding and that personification of the value of what you're doing unlocks tremendous potential for architecting and developing things with higher quality because they know who's on the end of it. It's not just ones and zeros and little algorithms here and there, but it's value. When I was at OfficeMax and at Kroger, it was always like, "If your grandmother was in the store shopping, what is the experience you would want them to have with your software? How do you make that meaningful for them and help them do what they need to do as they need to do it in that moment without friction, without frustration?"
So I was trying to shrew back with the engineers or if this issue pops up or if you didn't have monitoring on it and they're catching it for you, how did they feel in that moment? What's the emotion? Almost like you're in a traffic jam and it's frustrating, right? Well, that's what they're feeling on these prod calls. Get it solved now and learn the lesson, so that you could fix it in the future and not follow the same pitfalls. Stuff's going to break, but you learn, you adjust, and you gracefully handle, or you self-heal in the future, because now you've learned from it. If we don't learn from it, that's when we ultimately fail for delivering value for our customers because we keep hitting that same issue over and over again.
Patrick: Interesting. Going with the constantly improving, what are some of the biggest challenges when you're working with maybe a new member of the team or as you said, you've been there for a year, one of our listeners was trying to imitate what you're doing? What would they anticipate being some of the biggest challenges that they'd need to prepare for and maybe start working on how to approach?
Christina: That's a great question. I mean, shifting left is a huge shift in how you code solutions. It's like starting with the thought of how are things going to break and then coding for those failures. It's really taking the engineers through the journey of why this is so valuable and what it ultimately saves, because no engineer wants to write the test cases just like they don't want to ... However, they also don't want to sit on the prod incident call.
Patrick: Yeah, definitely they don't want that.
Christina: The effort that you do right here saves a lot later on and it costs less of your time and energy. I think the other thing is, I mean, Simon Sinek said it, but start with why. Why is it important that we automate our tests? Why is it important that we think about how this could break before we're even writing a line of code? Why is it important to think about how you observe and monitor its performance in production so that you catch issues or prevent them before your customers do? It goes back to the narrative of how you architect. If you know exactly why it's so valuable, what you're doing, you start to then embody how you become better as a champion of quality and then you hold them accountable to it, right?
It's during prod incidents, make sure that they're accountable if their solutions are. It's not like we're calling out blame, but accountable to recognizing the root cause, coming back and say, "Okay, let's do an RCA. Let's identify from a retro perspective what happened. What could we do better?" And then communicate out to all of your peers in the org the lessons you learned so that someone else can avoid that in the future, because things do fail. We're human, we're imperfect, but as long as we're able to change the way we work to mitigate that and learn from those mistakes and bring that forward across everything and share those learnings, those lessons, the better. So, some of the hurdles is trying to go too fast because you help it and not having spent the time on the why, silos of communication.
When those failures happen, the team solves it, but they're not then taking the time to let the rest of the org know to learn and share from those lessons because they're valuable. Even if that MQ failure was specific to that one incident, the replications of it are the pattern of why it failed could be very applicable to other things. So, really take that to heart. I think the other things is just also being clear and holding accountability. What you allow to manifest in your org is seen as, okay, that's the bar as we talked about earlier. If your bar is no, we want quality and done means this and then holding people accountable at that, that becomes the de facto standard for great and good and done in your solutions and your strategy.
Shelli: Christina, I couldn't help but see the five sticky notes on your wall. So, would you mind if we ask what those are?
Christina: So I have little notes to remind myself about leadership and just remembering that it is my choice for how I respond to situations. Things are neither bad nor good. They're a fact, and it is my perspective in the moment. So, this allows me during a prod incident call to maintain calm and recognize it or to remember that everyone who just is acknowledged and seen is recognized. So, they're just my little lead by listening and just little reminders for myself of being present and true in moments of the day and remembering why I'm here. That is to be of service and the vehicle of service and success for all of my team.
Shelli: That's awesome.
Patrick: It's really awesome stuff to remember. It's hard. Leading is hard. It's lonely, and sometimes you definitely need to pull yourself out of the moment. As a person who struggles with that, how's it going? What's your batting average at?
Christina: Wow, some days are better than others. I think that-
Patrick: Always improving.
Christina: ... I have a very high bar for myself. So, if I feel that my team is struggling, that's me. That's my fault. I own that. I mean overall, honestly, I have never worked with such incredible engineers who really just care about doing things. I've worked with some great companies. I feel like with each role I take, I'm just surprised and surprised that the talent is just incredible everywhere. This group of individuals is incredible, and they've just been so passionate about growing and moving into modern technology. It's wonderful to see the excitement. We've completed just a really challenging bit of work that took over a year to navigate through. When you're building greenfield, a system that has been in place for decades, we'll say, there's a lot of nuance in that.
So, you go in thinking, "Oh, it's so easy to build something net new," but you're like, "No, I'm not really building a net new because the net new thing has to work with this thing." So you're in this hybrid state, but we completed this incredibly challenging project and I'm really proud of them. There were moments that it seemed really frustrating because there's this date and everyone's like, "Oh, my God, the date." It's stressful. It's always like that date is set by you. You control what you control. If new information comes in, we adapt, we adjust, we change scope, we change our plan, we make alternatives, we adjust the plan. So, I think the biggest thing for me right now is helping the engineers feel truly empowered to take control of what they can control.
We can set a date based on what we know and what is in our control. When new information comes up or a situation changes, we adjust. We have new information and we make better decisions. I think it was Maya Angelou that said that you make the best decision you have with the information. When you learn more, you do better. I think that's what I'm trying to teach my engineers because a lot of them feel like, "Oh, I feel so stressed that date's not moving." I'm like, "Well, if there's a reason to move it, if we've learned something new, then we do the right thing and we move it so that we don't end up working so hard and sacrificing quality." You don't want to sacrifice the quality.
What you want to do is say, "What is within my control and how do I navigate?" So the ultimate result is that I'm delivering quality and still getting it over the finish line. I don't know if I answered your question.
Shelli: I was going to say, I think our listeners will be really intrigued by the fact that you said you have such an amazing team, everybody's so passionate. So, just out of curiosity, did you inherit that team? Did you hire them? How do you build such strong, passionate teams?
Christina: A lot of it is inherited. I did do some hiring, but it is inherited. I think that the culture of the organization is first and foremost, if you have a great culture and an organization, then great people are just naturally there because they're driven to being in a culture. Echo's culture is like we carry the load together. We do hard stuff, but we do it together. I think that becomes part of the reason that this team is so great, because they're always willing to lend a hand and to learn from each other. No one is shy to say, "I got your back" or help you, which is absolutely incredible. There's no it's me, I was the reason and the superhero this got done. It was, "Hey, here's the team and kudos to this group over here who helped us and partners over in DevOps."
So it's absolutely incredible to see that, and that's the culture. I think the other thing is when I came into the org, I met with everyone. I think it's important as a leader to meet with everyone on the team and have a personal relationship. So, even if it's a 15-minute coffee, talk with them just to say, "Tell me your story. I want to know why you're here. I want to know what your goals are." That connection allows me to reach out to them and say, "How are you doing?", even on Slack or see them on a Teams call and say, "How's this looking? This issue seemed hairy. What did you find?"
Then when I send my week in review emails and I talk about things like accountability or our need to do better job of communicating or documentation and I do send emails every week just about what's going on in the org and what are the themes I saw about opportunities that we have, they'll read it, because now they know that what I'm saying, it's succinct and it's there, but it's there for a reason because it's tied to our strategy and our technology goals. So, a lot of it has to do with the leader putting in the effort to build a lot of the relationships and the communication channels. So, that they can feel like you got their back, and therefore, they'll go out and they'll tackle that next task.
When you say, "I know this is hard, but I believe you can do it," they trust you because you know them. You see them. You recognize that they're there and the hard work that they're doing.
Patrick: That's awesome. Shelli, I know your role, you're constantly looking for the next level of leaders in a number of different organizations. Listening to Christina talk about that communication, is that the stuff that you're looking for, the rapport building, the relationship building?
Shelli: Yeah. So, I think the first thing Christina mentioned was culture, right? That's definitely part of it. People want to work with other great people and great teams and also just the mission. If people aren't tied to the mission and they're not tied to the attributes that you hire for, it's not going to work. So, you absolutely want to set people up for success.
Patrick: Awesome. Something else, Christina, you brought up a while back was that you have a high bar for yourself. I think that's true of most leaders. That's why they get promoted and they get to the levels that they get to, but many struggle with they think that their bar is everybody's bar and that it creates a lot of friction for people who don't have such a high bar. Is that something you've had to address as you've progressed through your promotions and as you've advanced and you've grown in the three years that you've been out of college? I mean, it was compressed timeframe, so clearly to test water.
Christina: Yes, exactly. These past three months have just been incredibly learning. No. So, I did the CliftonStrengths. My number one is achiever and my number five is competition. So, my top five is pretty heavy. I am constantly competing with myself. But the blind spot of that is that you now think everybody operates that way and that they feel and think the same way as you. Going through learning about my own strengths and recognizing the downsides, but also recognizing that hey, there's 34 of these and not everyone looks like me, it takes all of them to make things happen, has allowed me to really lean into setting clear expectations with the individuals I have, recognizing that they might not have my bar, but setting those clear expectations and allowing them to use their strengths to meet those expectations. But it's on me to set those expectations.
I can't just assume that they're going to operate in my mindset and say, "As an achiever, I'm going to get this done in the next hour," because I don't know what else is on. So, I'm going to set the expectations and allow them to negotiate with me based on that because they may have other things that they're working on and allow them to use their strengths to achieve it. Where you fall, and then I learned this in the past six months, we'll say, of my three-year tenure as a corporate citizen is if you expect something of somebody without communicating, because at the end of the day, you are let down.
If they don't know what your expectations are, if they don't know what they're being held accountable to deliver or when, then you are hurt because you set the expectation without being clear with them. So, I don't like hurting myself. So, I'm going to do my diligence of communicating what I expect when, and then if an expectation then falls through, we now have an opportunity to say, there's a coaching opportunity here to drive the performance and meet the expectations, whether it is hey, renegotiate as something happens, so be proactive in your communication, or navigate your own task structure to get these things done in time.
Patrick: Awesome. I use this mental image of slowdown, right? I've done the StrengthsFinder. Shelli, have you done StrengthsFinder?
Shelli: I haven't.
Christina: Oh, you should. It's eye-opening honestly.
Patrick: It really is. It really gives you an idea of like, "Oh, so that's why I do that stupid stuff. Okay." I think a lot of leaders struggle with this, especially when you're an achiever or competitive and you're a pusher, right? You're pushing to get things done is that you get to a point of your own success where people are like, "Hey, you're creating a lot of friction." People think, "Oh, that's a bad part of me." I think that's a mistake. I think of the idea that you're going to label that capacity as bad, and I use this metaphor of it's like Cyclops from the X-Men comic books. When he's got the visor on and he can direct the energy to the right places, it's really powerful. If he takes the visor off, it's just blowing everything up.
The thing about all of our strengths is they are our strengths, but then when we're in a state of stress, they generally are weaknesses as well. So, understanding that when you're stressed out, I'm the same way. I'm going to push, right? That's my default mode of okay, things are stressful. Let's work even harder. Let's push even harder. It caused a lot of challenges for a lot of people, so specifically myself. To your point, I don't like to cause pain for myself, but always seem to be able to do it. You're just in there somewhere.
So, pivoting a little bit, you did touch on this before with the relationship building and the strategic outcomes. We can move the dates. We can move things around. Some dates can't be moved though, right? There's a certain point where there's business objectives. It's normally not the case that there are movable dates.
Christina: You're right. There's certain government-issued dates, there are mandates and MREs that cannot, but what can be adjusted in that is you have the opportunity to adjust the design. How many individuals are supporting the effort? So there are still things within your control to help.
Patrick: Awesome.
Christina: You're never at the mercy, right? There is always opportunities to creatively solve.
Patrick: That's right. Funny enough, I was doing some quarterly planning with an employee and we were doing a rock. One of the rocks was to get 100 of something done, and we did a little bit of a strategic discussion about what's going to be the barrier. We went through it and they said, "Listen, what's one of the things we can change here?" They're like, "Well, I don't know this." We could change the number from 100 to 65. They're like, "Yeah." They're like, "Well, would that make it easier for us to succeed?" It's like, yes. Do we get all the objectives accomplished? Yes.
So, it's like all we had to do was change the numbers. So, to your point, there is a lot of times when people do planning, it's a little bit more optimistic than important. Is that something that you think about when you come up with... Because you mentioned PI planning, and for those who don't know, that's a scaled agile framework concept where you're getting all of your development teams on one page about what are we getting done in the next three months, is I think traditionally how it's done. Is that how you guys do it?
Christina: Yeah, 12 weeks. Yeah.
Patrick: Yeah. So, is there something that you're doing when you're engaged with those groups to help them reset to realistic? Because I think whenever you get in those meetings, everybody's eyes are bigger than their stomach.
Christina: My directors do an incredible job with this, as well as our team leads, is looking at the work. Do you understand what done looks like here? If not, slice it smaller. If you can't slice it small enough where you know what done looks like, then your estimates on it are going to be lower confidence because you probably could be missing things that must be done in there and then you'll be scrambling toward the end of a sprint or something to say, "How do I fill all this in?" So I think first and foremost is really consistently having your Scrum masters and your teammates, challenge the teams to say, "Is this sliced small enough so that you understand what done is? So that you could actually estimate effectively on it."
Because when you're in that 12-week period, you should have enough work at a level that you should be able to estimate whether or not you can commit to doing that within, again, your own control situation outside of it, whether the environment goes down or somehow Amazon East goes down again like it did 10 years ago. You can't control that. But the things you can control, slice it small enough.
I think the other thing I like to do with the teams is as they're navigating certain critical objectives and you're close to where you need to be, because we also layer on this concept of date-driven agile for, because when you have to do change management with your business or your customers either on a mobile app or something for your customers, it's important that those dates are known far enough out in advance, so that you can line up the training and all of that for your user community. So, there is this concept of having some level of even six-month knowing what a date is on some work, even though you don't have clarity of it. But as things get closer, I'm like, "You have a magic wand. You could ask for one thing that will guarantee your success. What are you going to ask for?"
It really drives them to thinking about the thing that unlocks the potential and the momentum to help them with success. It could be I need an architect to come in and help me with this, I need another team to take this service, I need this tool. But it starts to help them to think creatively about it is not just here right now, but there are other ways to be successful in it. How do I do that? Do I raise my hand and ask for help? Do I pair programs and something? Do I have another team lean in? That's become really effective in ensuring that the goal is very clear and that they have a number of ways to meet the goal of the objective.
Patrick: That's awesome. I love that, because I think part of it is it'll help uncover the thing nobody wants to really talk about.
Christina: We just don't like asking for help for some reason, but you'll jump in and help anybody who asks you. But you, I'm not asking you for help.
Patrick: So true. It's so true professionally and personally, right?
Christina: I'm not asking for directions. What?
Patrick: Well, okay. That's a whole different thing.
Christina: I got a GPS in my phone now. I never have to do it.
Patrick: Wow. I just don't like going backwards. I just say, "I'll keep driving." The whole turning back-
Christina: I'm not turning around.
Patrick: I can't do it. I don't know what's wrong. There's so many other, but you bring up a great point. Has that realization of asking for help, has that been part of... You mentioned how mentorship and participating in some of these panels have influenced your professional journey and some of your decision-making. Is that part of what's helped you over the last, I'll stop with the joke after this, but the 36 months, right? Is that part of what's helped you accelerate your career is asking for help and recognizing that you need help?
Christina: Yes.
Patrick: And then actually having the courage because it does take courage to ask for help.
Christina: Yeah. I mean, there is a moment in my career where I truly embraced vulnerability, and part of that vulnerability is saying, "I'm human and I need help. I'm going to ask for a mentor," or "I'm going to ask for a coach," or "I'm going to ask somebody else to come in and stare at this design and tell me where I'm wrong." Because when you do that, you start to tap into a network and you build just trust in relationships, but you also unlock the thing that was blocking you to begin with, which is really important for your success. Continuing to allow that to block you doesn't help you grow. Digging in and being stubborn and I want to do it myself doesn't help you grow either.
The more people see you as a leader be vulnerable in that aspect, the more they're fine saying, "Oh, my God. I need someone to help me on this. Can you pair program with me? Because I'm not quite understanding that repo," or "I'm running into a bug and I've been on this for about three hours. I could really use someone else's help." As opposed to I'm just going to continue to swirl and potentially let my commitment slide.
But the more we as leaders say, "You know what? It is okay to need help because I don't have every answer. I can't even assume to have every answer and thinking that I do just makes me even more fallible than asking for help," it's a real big unlock for yourself and your own personal journey. It really starts to unlock some of that imposter syndrome stuff that I have to be the smartest person or I have to know everything. No, I don't. What I have to do is be able to solve the problems and that solve may be asking for help, but the more we do it, the more we make it okay for others to do it.
Patrick: Yeah. I like to tell all of my employees that I make mistakes on purpose. It wasn't a real mistake. I was just trying to be vulnerable. That's my strategy of I didn't goof that up on accident. I did it. It was intentional. That's my move. It's working out great.
Christina: I have no problem giving my mistakes. I tell my teams all the time, I'm like, "My first child needs a ton of therapy. My second and third, though, they're doing a lot better."
Patrick: That's the way it works. We could have a whole podcast. I got twins at the beginning, so we doubled up our mistakes. Hopefully, they never listened to this podcast. They know, they're aware. They're like, "Why don't I yell at the other ones as much as you..." Probably because it's stuff I did, right? So Christina, thank you so much for taking the time to join us on the podcast. Really love it. Tremendous success you've had. Good luck with everything you're doing over at Echo.
Christina: Thank you.
Patrick: It's a huge part of the Chicago ecosystem. It's one of those organizations that I think are perfectly situated for Chicago, our tech jobs where it's like we move stuff, we do things. It's three-dimensional. It actually has value. It's not just some silly video game on a phone.
Christina: Oh, thank you so much for having me. Listeners, we're always hiring, so I'd love to have an engineer hit us up, be part of our journey of transformation. It's exciting. We are growing and we're really trying to disrupt the logistics space. So, thank you.
Patrick: Awesome. Well, we also want to thank our listeners. We really appreciate everyone taking the time to join us.
Shelli: 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.
