The One Where We Geek Out on Asking Why with Helen Shen

About our guest:

Helen Shen is a lifelong learner who believes in balancing strategic and tactical IT solutions to maximum value delivery and time to market without jeopardizing long term growth and scalability. She is a technology leader with finance domain knowledge in retail banking, capital markets, and wealth management. She's been responsible of major IT development initiatives over $1M, and has successfully modernized applications from monolithic architectures to API architecture, and has worked on migrating on-premise assets to the cloud.

Find our guest on:

• LinkedIn

Find us on:

• All of our social channels are on bento.me/geekingout
• All of Adriana's social channels are on bento.me/adrianamvillela

Transcript:

ADRIANA: Hey y'all, welcome to Geeking Out. The podcast about all geeky aspects of software delivery. DevOps, Observability, reliability and everything in between. I'm your host Adriana Villela, coming to you from Toronto, Canada. And geeking out with me today I have Helen Shen. Welcome, Helen.

HELEN: Hi everyone. Hi everyone.

ADRIANA: Hey, it's so nice to have you on the show. Now, first things first, where are you calling from?

HELEN: I'm calling from a small town outside of Ottawa. It's called Carlton Place.

ADRIANA: Awesome. Yay. Another Canadian. Cool. Well, we're gonna get started with some lightning round questions before we get into the meaty bits. So are you ready? All right, let's do this. Okay, first question: are you left handed or right handed?

HELEN: Right handed.

ADRIANA: All right. iPhone or Android?

HELEN: iPhone.

ADRIANA: Mac, Linux or windows?

HELEN: Mac, Linux and windows.

ADRIANA: Ooh, all of them. Awesome. I love it. What's your favorite programming language?

HELEN: Java.

ADRIANA: Awesome. Dev or ops?

HELEN: DevOps.

ADRIANA: Awesome.

ADRIANA: I've had a few people who have

ADRIANA: answered DevOps as well, so I love it, I love it. No wrong answers either way. Okay. JSON or YAML?

HELEN: JSON.

ADRIANA: Ooh, I think, I think you might be one of the few on camp JSON so far. I should, I need to do a poll.

HELEN: At some point I started embracing YAML. Well, but that space got me.

ADRIANA: Oh yeah, yeah, I know. I've definitely gotten burned too many times by the, by the indentation on YAML.

HELEN: At the beginning stage, the learning of troubleshooting, whole night with my espresso and then figure out it's a space.

ADRIANA: Yeah, I know, right? Yeah. It's like why do you hate me so much? I feel ya. Okay, two more questions left. Do you prefer to consume content through video or text?

HELEN: Text.

ADRIANA: Alright. And finally, what is your superpower?

HELEN: My superpower is make everyone else to have superpower.

ADRIANA: Ooh, I like that. That's very meta. Amazing. Amazing. Well, thanks so much for doing the lightning round questions. Now it's time to get into the meaty bits. So I'm very excited for this conversation because, you know, we had our pre chat a couple weeks ago and I feel like the ideas just started flowing on this and so I'm very, I'm very stoked for our topic of discussion. So I think when we were chatting initially, one of the things that you brought up was the importance of asking why.

ADRIANA: So can you elaborate on that a little bit?

HELEN: Yes, yes. So I have been through career in different organizations doing different type of technology, different tech stacks, different solutions. And one thing I found that make me going through the success of the project, the deliverables, the customer satisfaction, everything is because of that question. Why? Why are we doing this? Because using DevOps as an example, why are we doing this? Not only because it's cool, even though it is cool. And not every organization may be ready for DevOps, but why? I remember at my junior stage that I took automation for granted. And when I got into projects that embrace agility and automation, I was pumped, I was motivated, I was ready to go. And I didn't understand at that time the word, "fit for purpose". I didn't quite get it.

I heard it, I acknowledged it, but I didn't...I can't say that I fully understood the context of it. Then through different experiences, different projects, and also different growth in myself, then I started to use that word and I can see the same reaction from my team members or more junior team members. Then I start to realize, okay, they have been through what I've been through and what I can offer is that, sharing that "why?" Why do we need fit for purpose? Why is there need for such process? Why is it so difficult? There is a reason why it's so difficult, and is there a reason that it had to be like this, or there is a chance for improvement? So even though we're talking about ways to enhance experience, customer experience, user experience, developer experience, we really truly have to understand why. What's our problem definition? What are we trying to solve? Then the journey will become much easier.

ADRIANA: Yeah, I totally agree. Now for our audience, can you define what you mean by, "fit for purpose"?

HELEN: Yes. So using a technology project as an example, I don't know if some of you might experience that you are participating in multiple projects, and one project is embracing agile, one project is embracing waterfall. And even though by the book in Agile you should be a consistent part, 100%, you might not get into that. You might have to participate multiple projects in different ways. Some are all manual, some are half automated, some are fully automated. And while you are especially for a single contributor in the project, sometimes it's very hard to switch that context and fit for purpose. Yeah, and what I mean by "fit for purpose" is to actually understand from the customer perspective, management perspective of what is your goal trying to solve and why it has to be this way. And sometimes the answer could be that this because the architecture, because the environment organization is very big and complex and to ensure the quality and audit requirement is the best. Waterfall approach...maybe? On the other hand, though, it could be we don't have the resource, the company didn't have that culture comfort level yet, right?

And even so, there are different reasons. And the fit or purpose is how the whole team, not just you or what's the best, what's the coolest is for the whole team plus the customers to make that whole decision or the outcome of our process, our decisions to go in which way and each project might be different. The reason is that you do need to hold different mindsets and different approach. However, understanding that why and the fit for process, sorry, fit for purpose mindset, then you actually make your context switching much easier. Because we do know we talk, we often see that context switching waste time. However, it's unavoidable by knowing that why it helps you switch that contacts and navigate much easier and efficiently. Actually, I'm not saying we should stop from improving ourselves, but I think what are we trying to improve? What's the best approach to improve? What's the best DevOps approach, etcetera. It really depends on the context of your project and then find that fit.

ADRIANA: Yeah, I couldn't agree more with that because I found in so many instances in my life, like as a developer, sometimes you're told to do things, right? And it's so easy to be in your little developer bubble, especially when you're a more junior person, where it's like, whatever, I do care, I just want to get my stuff done. And so, like, you know, we can be perfectly content with, with just doing what we're told. But I think it does us a disservice to not ask why. Because why is it that I'm doing the thing? Like, you know, I was chatting with my husband and he was talking about how he came up with like this big architecture for the stuff that he's working on. And he says it's so frustrating sometimes dealing with some of the folks that he works with because they don't understand the bigger picture of what they're trying to build. They're just working on this little piece. And so because they don't understand the full context, then it's harder to ask meaningful questions, right?

And also, if you don't understand why you're building something, I think it's a lot harder to like, you know, you just sort of accept the architecture for granted...like, you take it for granted and then that ends up becoming a problem because, what if, like, the original direction wasn't correct, right. But you don't understand it. You're not going to question it. When you understand it, you can think about it. Oh, yeah. Well, this doesn't make sense. Why are we doing it this way?

HELEN: You have a good point. However, I noticed that in my journey there are rarely, rarely. It might be like one off case, but rarely. People don't care about one. It's just that they may, they may be in their world focusing so much that they might forget. And I think, I think this is the leadership call that I would say that as a good leader, I think they should embrace this mindset by making this opportunity more visible and approachable to the team members. Because a lot of time, I think developer doesn't even realize that. And I think usually I would expect that especially leaders, definitely, even the senior managers ,would open that door to show, especially for developers when they're focusing, we respect their time, we respect their focus, we respect their expertise. However, this is the contribution you're making. This is the impact you're made most of the time. When that opportunity and the vision, the values are presented to them, it's a different story.

ADRIANA: Right. So are you saying then like it's kind of up to also like the, these folks in leadership positions to kind of incentivize to force to ask the why? And I think that's so, such a great habit to get into because we should always be questioning things like we need to be curious. Curiosity is what makes us learn.

HELEN: Right, exactly. And that's how we challenge the status quo in a productive way, in my opinion.

ADRIANA: Yeah, absolutely. And I think also, like it's, it's so important too, because like, sometimes, you know, when you're, when you work in a large organization and certain decisions are taken. Right. And it's, it's so easy to get mad, right? Like people, like, what are they doing? I hate them. But, you know, I think if we took the time to, to question it, to not just wonder why, but ask why of our leadership, I think it would be, I think it would be helpful as well because I think it can, I think it can calm any nerves, right. And I think part of it is we have to get into this habit though, of asking why of our leadership because I think sometimes in certain situations it can be very intimidating. Like you're in a town hall and, you know, there are always like brazen people who will ask questions at town halls, but then there's also like the tons of people who are just sitting there in the corner. Like, I have questions but I don't want to ask. And I think like, empowering folks to ask why and making it a safe place to ask why, I think is really important too, right?

HELEN: Yes, totally, totally. I remember that it took me quite a few years to feel comfortable asking questions in tech. So I can totally relate to that. But I do want to say that sometimes it could be an opportunity that we don't know why or even when it's not safe to ask why because of certain culture. It does feel a bit awkward. It's bad. But what I like to remind myself is everything's an opportunity.

ADRIANA: Yes.

HELEN: So as long as I'm here to contribute, I know this is the current climate and okay, people don't like to be asked why, but I do want to know because I have that thirst and that helps me to perform better, that helps my team to perform better, especially being in a management role. I think this is crucial. And sometimes you do run into a situation that's not so pretty. However, I take it as an opportunity that maybe they're not comfortable yet. And then there's so many opportunities and ways that we can navigate ourselves. And at the end of the day, I find this is not only the gain for the organization, it's also gained for self in terms of your career as well. Because then you grow professionally on how to solve these problems. And again, there's no right and wrong answer. Just like the lightning questions you asked at the beginning, but then you get more comfortable to it and that's your growth.

ADRIANA: Yeah, yeah, absolutely. It's all about being curious.

HELEN: Yes, yes, yes.

ADRIANA: Awesome. I absolutely love it. And you know, like, you know, you've mentioned that you currently work as a manager now. How do you find, having been an individual contributor in the past, having been wearing the developer, the developer hat, how is it wearing the developer hat versus wearing the manager hat? Was it a big clash for you? Was it natural progression for you?

HELEN: How was it? I miss being a developer, I'll be honest on that. However, I acknowledge my superpower that I mentioned is that because of my personality or the way that one thing I find is the compassion and empathy is a big thing. Because I understand my thought as a developer and understand my team members thoughts and if you truly care for them and actually enable them and, you know, emphasizing, why are we doing this? Why change management? Need to go through 20 layers of approval? But navigating that together as a team member makes me a better manager. And I realized that I can scale myself from a single contributor to enable more single contributors. I find that very, very satisfying. I feel good doing that. And one thing I really, really love asking my team is that sometimes as a single contributor, you really focus on, especially technology, difficult problems. And it's very natural, and I did the same to forget about the goal. Like the why, what problem are we trying to solve? What? Like, sometimes there's a balance approach.

ADRIANA: Yeah.

HELEN: You're trying to solve this problem and then it's way out of the budget, right? And it might take way out of the extra time, etcetera. So how do we find that balance point? And one approach, I really find it effective and it really makes my team member, especially developer, interested in thinking about this, is that I encourage them to say, when you got into this situation, don't think like a developer. Pretend that you're Helen. Pretend that you're a manager. What would you do? And I find that approach is really helping them and it helps me too, because understanding now why, and sometimes I don't understand why I'm looking for that. Why then I put myself in my manager's shoes, even the senior leadership, what's important to them.

ADRIANA: Yeah.

HELEN: The code, quality is important, but how do you write that if statement may be important to a tech lead, but not a CTO, and that's...it sounds as bad you saying it, but going through this process, you start to understand why the CTO doesn't focus on this. However, it's equally important to write a beautiful if statement without confusing your peers and then later on introduce a bug, right? So, yeah, it's all related. And just connecting that dot and always think yourself a level up and wear those hats. Pretend yourself to be your next, like, your manager or next level, and things could get a little bit clearer and easier.

ADRIANA: I really like that so much because I think it's so easy, you know, when we're, it's so easy for us as developers to, like, complain about management. Ah, these stupid management decisions. What were they thinking? And it's, you know, it's funny, the first time I was in a management position and I vowed like, oh, I'm never going to make the same, you know, stupid mistakes that were made with me by my crappy managers. Never, never, never.

And, you know, I, I'd like to think I was, like, relatively successful, but the thing you have to learn as a manager, which I'm sure you've, you've seen yourself, is you can't please everyone. You're going to make some decisions that are going to be unpopular. And I mean, so be it. Like, yeah, but I think as a manager, it's your duty to explain why. But, like, they don't have to love it. But I...but I also think that your team has to support it, because when your team doesn't support your decisions as a manager, then things plunge into chaos, right? Because then you find yourself in a position where, like, people are talking behind each other's backs and then you've got, like, little factions developing, and all it takes is, like, one bad seed to sort of, like, ruin the harmony of your team. So I definitely agree with you that it's so, so important to get people to, like, basically get into each other's shoes to have that understanding and to understand the why.

HELEN: Yes. And you raise a really good point, because it is, I agree, almost impossible to please everyone. At the same time, though, I believe it is possible to support everyone. That's different.

ADRIANA: Yes. Yeah, I completely agree.

HELEN: Yes. Yes. So as the leadership, in the leadership role, I actually believe that we...it's our responsibility to support every team member even though we may not able to please it because of the constraints we're in. And we can explain that background, usually explaining that reason, the why the thought process helps. And even though we may not be able to achieve the goal of 100% people agreeing, we can definitely support, because that's how we move forward as a team together.

ADRIANA: Yeah, I totally agree with you when you say that. I have a scenario that comes to mind in one of my more recent management roles where basically I pivoted the direction of my team. And on the most part, the team was super chill about it. They're like, gung ho. But I had this one person who was definitely not into, you know, the pivot, and he was extremely unhappy. And, you know, I tried my best to explain, like, the direction that we were going in, but it was, you know, it wasn't the type of work that he was doing. So the way in which I supported him wasn't necessarily like, I'm never going to be able to convince him that the work that we were doing was going to be the work that he wanted to do. So the best way I could support him was to help him...him find a role internally that would better match his skillset. And I think, you know, being able to...being able to support your team members doesn't always necessarily have to involve convincing them that you're right. It's just making sure that, you know, you're both in a good place that makes you happy.

HELEN: Right, right. And that's a...that's a...that's a very interesting point because I remember going to one on one with my team members, and the way I navigate this kind of situation is that I am hired by the organization as a manager to achieve certain goal for the company. And in order to make that happen, to make that goal successful, there are two parts. There's company and there's you. So both need to align.

ADRIANA: Yes.

HELEN: And if I cannot align your career goal with the company, that won't work out.

ADRIANA: Yeah.

HELEN: And it has to be both ways. And company need to align with you, you need to align with company, so both come together. If by any reason that alignment cannot be reached. And this is, this is my thing as a manager. I say the same to all my teams, no matter where I work. If you believe that alignment can be achieved by other place, and that's the best for you, and I'll support that. Even though that may be a loss for the company, it's a short term loss for our company, because then we don't waste time, unnecessary realignment and, you know, delaying certain things. I think we have to accept the fact that there is a middle ground, there is a balance, and technology is such a small world.

I don't believe in holding the team member stuck in one team. Makes sense, right? By supporting, by creating a supporting network, sometimes it could be internally within the team, sometimes it could be within the organization, sometimes it could be even beyond organization. So at different levels. And that's, that's what my firm value of belief is. Like, there's no point if both sides cannot align. It's important what company wants to achieve, but it's also important, the contributor, especially the bottom line contributor, that who actually doing the work.

Our job is to enable them. And if that have certain constraints, we try to eliminate as much as possible. And if that's not possible, then we support them at the next level. So that's, that's what I think it's important. And people often think that we want to make sure people don't quit. I do not want people to quit. I would love to work with them. However, we just have to be honest to ourselves. In my, in my modest opinion, that what's the best for the developers, the sole contributors, and what's the best for the company together.

ADRIANA: Yeah, I completely agree with you. Because if you're holding someone back like that, forcing them to be where they don't want to be, it's like, you know, you're, you're dating somebody who doesn't want to be with you and you're just forcing them to be with you because you love them and they don't love you back. And I mean, it does no one any good at the end of the day?

HELEN: Yeah, just gonna be...but doesn't mean you can't be friends, right.

ADRIANA: So, yeah, and I think, like, and tech is really cool because like, you know, especially in Toronto, like, and I mean, I know you're no longer in Toronto, but even like in Canada, eastern Canada, let's say, like, it's a small world, especially now that like, we've embraced more of this remote mentality, remote work mentality. It's a small world and I think like doing a solid for a co-worker, like, it goes a long way. People don't forget, like, I think there's like good karma in tech if, if you, yeah, you know, if you help, if you help somebody out, they will help you out at some point in the future. I fully believe in that.

HELEN: And I'm only their managers when I'm at work. Outside of work, I don't have to wear that hat. So I would rather be a good human being that I believe in myself. No matter where you are in the organization, whether you're a CEO, CTO, a developer, an intern, right? So at the end of the day, I'm only their manager for 8 hours.

ADRIANA: Yep. For sure. For sure, yep. Awesome. I love it. Switching gears a bit now, I know, like, you've gone back and forth between working both at a startup and a large enterprise. Yes. You know, some people only work startups, some people only work large enterprises. And you've gone back and forth between the two. Can you share with folks what that has been like and kind of what's, what do you think were the biggest shocks in both worlds?

HELEN: Hmm. I love learning, so switching gives me a total different views of things to do. The, I wouldn't say like, I know in advance that what I'm going to experience and what's the shock that it may have but actually feeling it is different. The risk appetite is very different depending on the size of the company. And when you're in a large organization where the process is very well developed, you take advantage of it. You basically embrace the safety. But at the same time, though, sometimes you could wonder why things move so slowly.

HELEN: Yes, and in a startup, whereas there is literally, the process is no process, you embrace it, you move on, you can go production the next day whenever you're ready. You still do all your best practice automation test integration. Then you just go, it feels awesome. However, there is a catch of the risk appetite. Sometimes it could be go beyond your threshold.

ADRIANA: Yep, yep.

HELEN: So that is the, that is the shocks that I would say, that caught me, even though I know about this, but feeling it is totally different. And you are the person in a senior leadership team being accountable.

ADRIANA: Yep.

HELEN: You have to support your team for that decision and then make that informed decision what risk to take and what risk not to take. And that is an amazing experience for me. And it does...it does push me a little bit, like, outside of my comfort zone. However, again, like, I think every experience has its own learning. There's, like my manager always says, don't chase for perfection, chase for progression. And I really take that to heart. And every situation, every mistake I make makes me a better person, make me a better, more professional, make me a better manager.

ADRIANA: Yeah, absolutely. And I think that's so important to recognize because, you know, there are times in our careers where we think back to, like, our past mistakes and we're like, oh, so cringey. Oh, my God, I'm so embarrassed. I can't believe I did that. But, like, it helps shape who we are. Like, we wouldn't be where we are with our careers without that. So I really love that. I think that's, those are, like, really great words to live by.

I definitely agree with you on the, like, the shock of a startup because I remember I was, I think my second job out of school was, like, for a smaller organization. And I remember, like, we were developers touching prod. I mean, I had access to, like, you know, the prod data, and then I, I kind of decided, okay, I've had it with this sort of, like, you know, wild, wild west environment. So I wanted to go back to large enterprise because I needed more order. And of course, I went to, like, one of the most, like, one of the places with the most order, which was a bank, and with all of the regulations. And so my biggest shock was going from a place where, like, I, as a developer, had access to the prod database to going to an organization where there was, like, a separate team for, like, the QA and UAT databases and a separate team for the prod databases. And I'm like, what? And you have to, like, open tickets to be able to, like, communicate changes. And that was so jarring. I mean, you understand why, but it's still a complete, complete shock.

HELEN: Yes. Writing a delivery letter on every single deployment that we have to.

ADRIANA: Oh, my God. Yeah, yeah, yeah. The lovely document from hell. All the things that you have to do in order to deploy your code to prod and pray that you didn't mess up the instructions or else.

HELEN: Yes. However, this is a very interesting point, because when I work on DevOps pipelines right now, that's my delivery letter.

ADRIANA: Yeah, absolutely. But it's codified, which is beautiful.

HELEN: Exactly, exactly. And then by making that connection, I think it helps everybody on the team to be more, you know, compassionate about what's going on. Like, I remember I was cursing about delivery letter when there was still one, right? And especially when you have to redeploy that minor changes and you're afraid of every single typo that will slow you down.

ADRIANA: Oh my God.

HELEN: Yes, yes. As a developer, I did curse it. So I totally understand and can relate to it. But as a manager, by supporting it now, I would say I can understand the DevOps pipeline is with, that is basically codified, that delivery letter. However, you do understand that, why am I want to automate this for human error for whatever reason, make that connection and help, even help the company transition to that mindset, if you can make that connection. Otherwise, why? Why do I want to spend so much money doing this, right? And that's why I think, especially when I find something irritating or annoying, I try to embrace this mindset and then it will make sense. You will find a light a bit sooner.

ADRIANA: Yeah, absolutely. And I think that's such a compelling argument. Like, whenever you've got folks who are like resisting this change to DevOps processes, right, all you need to do is say, well, do you remember the delivery letters that we had to do manually? This is why we have this process in place and I think it becomes a very compelling narrative. And yet another example why, explaining why asking why is so important.

HELEN: Yeah. And we run into a situation that sometimes, again, depending on the teams and the process, we need to have a DevOps engineer to click that button. Why? It's a continuous improvement process. Because even though I don't know if some of the technology team members can them relate, we have a pipeline, but I need a DevOps engineer to click that button. Like, oh, why? What if my DevOps engineer is not available, why do we need him to click that button? That button is just right there.

ADRIANA: Yeah, totally.

HELEN: Yeah. Sometimes it's an interim product like that, and, and it could related to the process approval, funding infrastructure constraint. And I understand. I was the person as a developer back then when I was being blocked by my DevOps engineer. But I understood because he's my great working partner. He has a life too. He needs a day off. He was busy. I totally understood. However, it's very easy to resent to the management. Like, why are you doing it this way? Right?

ADRIANA: Yeah, totally. Totally.

HELEN: Yes. And I like how my manager said, do things with empathy instead of a sword. So using that mindset, if you go to your manager and say that instead of blaming that button, that you can't click, frame it as a way that I want to understand, "why did you?" Why did the company or management decide to design things in this way? Maybe you'll get a different answer and maybe you'll understand what challenges they are facing and put yourself in their shoes, and then your suggestion might be very valuable to push them forward.

ADRIANA: Yeah, absolutely. And that's the important thing. Like, you know, understand why, but don't just take it at face value, because then...then you can use it to further probe and say, okay, well, I get that this is the process, but can we make it better? Because we need you to understand that this is not sustainable. This is a bottleneck for my work, and I think...

HELEN: Right.

ADRIANA: And so the empathy comes into play once again, which, you know, we need that. We need more of that in our industry.

HELEN: Yes, yes. And I love being in the management role to put that empathy, compassion into the daily work, because sometimes technology problem can really make us stay focused. But at the same time, though, you know, to put ourselves in a box and forget about that. So I like being in this role to remind my team members that everything goes a long way with your technical expertise with the empathy, right?

ADRIANA: Yeah, absolutely. Now, we are coming up on time, but before we wrap up, I do want to touch on one thing that I think is super important, that I think we need to talk about more, which is work life balance. And especially, like, you and I are both moms, and we are working moms in tech. So the question. My question to you is, you know, how...how do you manage as a working mom in tech? I mean, I know it's not like roses and ponies, like, all the time, you know, sunshine and rainbows. Like, we know that it's hard. So, like, what are your thoughts around that?

HELEN: It is hard. Bottom line, it is hard. But I look at it as a journey as well, and recognize that some days I can't do it, some days I could. And I think it's the expectation. Do you put your team member, as a manager, those unexpected expectations, writing codes with no bug? Probably not. Then why do we do that to ourselves?

ADRIANA: Yep, yep. Yeah. Oh, my God. That's so true. That's so true. I love that analogy so much. Yes.

HELEN: So it's natural for a mom like us wanted to do it all, and I can always stop at the same time. Though some days, I really sucked that I would say that I couldn't do this. Like, I can't deliver what I promised my team to...I fail my team sometimes. I was like, oh, I have to leave my kid watching tv for an hour. I can't do this. I'm not a good mom. It's very easy to get into that situation.

ADRIANA: Yeah, totally.

HELEN: But what...Yeah, but we really have to pull ourselves out from this situation. What I tried, the approach I use is, like, okay, if I have empathy for my team, do I have empathy for myself? Yeah. Like, do I give them unnecessary expectations, like, mission impossible, and it's not even achievable, then why do I do that to myself? And also knowing that you can't pour from an empty cup.

ADRIANA: Right.

HELEN: If I don't take care of myself, how do I take care of my team? How do I take care of my family? So that's the approach I use. I wouldn't say that I mastered this. And balance...if you...if you look at a balance beam, you're always, like, adjusting. So I haven't reached that balance. I'm still adjusting, but this is the approach I use.

ADRIANA: Yeah. Yeah. I love it. I love it. Yeah. And it's so true. I mean, balance isn't necessarily equilibrium. There are going to be wobbles, and that's okay. Yeah. And there are gonna be good days and bad days. I totally agree. I mean, I feel some days that I just. I suck. I can't do, like, any of the things properly. Like, you know, failing my daughter, sometimes failing at life, like, in general. And I totally agree with you.

Like, just making sure that you take care of yourself is so important. And, you know, I. I'm one to admit, like, I give advice on work life balance, and I am terrible at following my own advice. And I more recently, like, I have had to, like, take my own advice on work life balance because I found myself in a situation where I was burnt out so badly. Like, it was affecting my sleep, affecting, like, my eating, like, I was getting, like, anxiety and digestion. And so I had to, like, take a step back, and this was my body saying, you got to take care of yourself. So I had to, like, make, like, changes to. To my life to, like, achieve some balance. And we need to listen to our bodies.

HELEN: Yes, yes. And I know, Adriana, you actually climb.

ADRIANA: Yes.

HELEN: With your family. I think that's a...you don't like...I personally don't climb, but I do think it's a great opportunity to give it a try just because you realize that balance, like how a master elite athlete, how they climb, is still like this. Why are we so hard on ourselves? I find it that even though I can climb, but I...when I accompany, for example, my daughter for her climbing, then I feel like there's so much to learn. And I find...I find myself being more graceful acknowledging that. And I think that's one activity I would definitely encouraging people to give it a try. You don't be master. I can't even climb the easiest, but because I suck at it, it helped me understand that balance that, you know, reaching the balance is also a progression.

ADRIANA: Yeah, yeah, totally, totally. And, you know, like, even if it's not your jam, like, you tried something that's outside of your comfort zone, and it doesn't have to be climbing. Whatever, right? That's the important thing. Just try something outside your comfort zone. Your brain will thank you because it's so different from what you do. So I think, yeah, I think that's amazing advice. Before we sign off, do you have any parting words of wisdom for our audience?

HELEN: I truly believe everyone has a purpose. I think just belief in yourself. Continuous questioning about why, find a purpose, and everybody will be their shining star.

ADRIANA: Awesome. I love that so much. Well, thank you so much, Helen, for geeking out with me today. Y'all don't forget to subscribe and be sure to check out the show notes for any additional resources and to connect with us and our guests on social media. Until next time...

HELEN: Peace out and geek out.

ADRIANA: Geeking Out is hosted and produced by me, Adriana Villela. I also compose and perform the theme music on my trusty clarinet. Geeking Out is also produced by my daughter, Hannah Maxwell, who, incidentally, designed all of the cool graphics. Be sure to follow us on all the socials by going to bento.me/geekingout.